Difference between revisions of "Common:Fields"

From AgileApps Support Wiki
imported>Aeric
m (Text replace - 'permission rights' to 'permission')
imported>Aeric
Line 4: Line 4:
:*Fields are defined by giving them a label and specifying a [[Field Display Types|Field Display Type]]
:*Fields are defined by giving them a label and specifying a [[Field Display Types|Field Display Type]]
:*New fields can be added to the [[Form]] canvas
:*New fields can be added to the [[Form]] canvas
:*Fields can have [[#Role-Based Field-Level Permission Control|Role-Based Visibility]], meaning that the field data is visible only to users who have permission for that field
:*Fields can have [[[#Role-Based Field Visibility|Role-Based Visibility]], meaning that the field data is visible only to users who have permission for that field
:*Fields can have a [[Default Value]] defined, which pre-populates the field in the data entry form ([[Form]])
:*Fields can have a [[Default Value]] defined, which pre-populates the field in the data entry form ([[Form]])
:* Default values can be created with [[Formula Fields]]
:* Default values can be created with [[Formula Fields]]
Line 32: Line 32:
===Field Audit Log===
===Field Audit Log===
{{:Field Audit Log}}
{{:Field Audit Log}}
===Role-Based Field-Level Permission Control===
===Role-Based Field Visibility===
{{:Role Based Permission Control}}
{{:Role-Based Field Visibility}}


====Guidelines for Add/Update Field Value====
====Guidelines for Add/Update Field Value====

Revision as of 22:07, 16 October 2012


About Fields

  • Fields are defined by giving them a label and specifying a Field Display Type
  • New fields can be added to the Form canvas
  • Fields can have [[[#Role-Based Field Visibility|Role-Based Visibility]], meaning that the field data is visible only to users who have permission for that field
  • Fields can have a Default Value defined, which pre-populates the field in the data entry form (Form)
  • Default values can be created with Formula Fields
  • Fields created by Users are listed as Custom in the Type column

Lock-tiny.gif

Users that have the Customize Objects permission can edit Fields 

Working with Fields

Add a Field

Fields can be added to an Object from the Fields tab. The fields that are displayed to users in different roles, and the positioning of those fields, is defined in Forms.

Common:Add Field

Delete a Field

To remove a field from a Form:

  1. Click Designer > Objects > {object} > Forms > {form}
  2. Hover the mouse over the field to remove
  3. Click the Remove Field icon Delete.gif in the floating toolbar
    Draggablefieldicons.gif

The field is removed from the layout, but it remains available in the object and is moved to the Pick Existing section of the Elements Sidebar. Fields can be reused in this layout or any new layouts.

To delete a field entirely:

  1. Click the field name.
  2. Click [Delete].
    A confirmation dialog opens.
  3. Click [OK] to delete the field.

This is a permanent deletion, and cannot be restored.

Field Audit Log

When the Field Audit Log option is enabled, you list the fields to be audited. Changes to those fields are then added to each record's Activity History.

Lock-tiny.gif

Users that have the Customize Objects permission can set the Field Audit Log. 

Lock-tiny.gif

Users that have the Manage Audit Log permission can view the Audit Log 

When a field is modified, the following information is added to the activity history:

  • Field label
  • Original field value
  • New field value
  • Who changed it
  • When it happened
Considerations
  • Creation dates are not logged.
  • An entry is added to the activity history for each audited field that changes. (If three fields change, three entries are added.)
  • For the Cases object and several other System Objects, all fields are audited, by default.
  • For Custom Objects, field auditing is turned off, by default.

Enable the Field Audit Log

  1. Go to GearIcon.png > Objects > {object} > Field Audit Log Settings
  2. Click Enable Field Audit Log
    The list of object fields appears.
  3. Click Track All Fields, or leave that option unselected and click the checkbox next to each field to be audited.
    (Choose up to 20 fields per object.)
  4. Click [Save]
Learn more: Activity History

Role-Based Field Visibility

Role-Based Field Visibility

Guidelines for Add/Update Field Value

The Order of precedence of field properties (#1 takes precedence over #2, etc.):

  1. Always Required
  2. Field Visibility
  3. Display Attribute
Add/Update Field Value
  • For the API/UI calls, the Always Required property applies, even if the field is defined as hidden/read only via Form or Field Visibility settings
  • Fields defined as Hidden/Read-Only via Field Visibility settings can not be added/updated from the UI, and should not be added/updated from the API
  • Fields defined as Hidden/Read-Only via Display Attributes are considered only for UI calls (but not API calls)
  • Hidden Fields can be updated through the scripting
Log Access Violation
  • When fields defined as Hidden/Read-Only via Field Visibility settings are used in an API/UI request, the entry can be logged in the Audit Log, provided that the Enhanced Security Audit is enabled