Working with field security

Field security allows you to define how users can access fields associated with a screen. For example, you can make a field invisible to some users, allow others to view the contents of the field but not change them, and grant other users both read and write access. In addition, you can make it mandatory for a user to enter a value in a field before submitting the form.

You can supplement field security with JavaScript by adding code in the scripting boxes available on the Screens tab when customizing an entity. For more information on field-level scripting, see Using generic JavaScript in field level scripting.

Field security changes apply immediately, and to all logged on users. There's no need to reset IIS, to carry out a metadata refresh, or require users to log off and back on.

• If you use field-level security to restrict rights, you must check whether possible conflicts can arise. For example, ensure that a user isn't required to enter a value into a field for which they don't have read access.
• If checkboxes in the Read and Write Access columns are cleared, this means a default denial of access rights to connected security types. For example, if all checkboxes in the Everyone row are cleared, all profiles, teams, or users are denied read and write access to that field. However, a user can access the field or change its contents if a security type that applies to that user is added to the list and the relevant Allow checkboxes are selected.
• If one user is denied read access to a field, security considerations mean that the contents of this field are excluded from keyword searches performed by all users. For more information, refer to System behavior fields.