Setting field-level permissions

You can set view and edit permissions on fields for any role. For both view and edit permissions, there are three options:

Yes — Users with that role are granted that permission.
No — Users with that role are not granted permission.
Conditional Formula — Users with that role are only granted permission if the associated conditional formula returns true.

You can only grant edit permission to a role if that role has view permission.

To set field-level permissions:

Navigate to the object definition page.
Select Fields from the ribbon.
Click Permissions next to the field for which you want to set permissions:
Select each role's View and Edit permissions, specifying Yes, No, or Conditional Formula as shown below:
If you selected Conditional Formula for a position, click Formula to edit the formula.
The following screen shows a conditional formula. In this example, the createdBy field (whose value is a user link), must equal the current user to grant edit permission on the Comments field.

Note the following when implementing field-level permissions:

For performance reasons, keep conditional formulas short.
To grant edit permission on a field, you must also grant view permission on that field. This applies to both non-conditional and conditional permissions.
Edit permission is granted for any activity that creates or updates records, including Edit pages, New pages, Quick Create pages, Mass Update pages, and inline editing.
For mass updates, Platform updates only those records for which the condition formula returns true.
If a field is required (Always require a value in this field in order to save a record is checked for the field), and edit permission is not allowed on that field for a user's role, the field permission takes precedence. Platform does not validate the field and the user can save the record with no value for that field.
Permissions to access fields from APIs are determined by permissions on the fields' object types, not by field-level permissions.
When you use conditional permission, note the following behavior: If the view conditional formula returns true and the edit conditional formula returns false for a field on a page, the page displays the field but does not allow the user to enter a value in the field. If the view conditional formula returns false, the field does not appear on the page.
When writing a formula for conditional edit permission, note that the current record context is not available during record creation. To write a formula that covers both create and update cases, either conditionalize the formula to execute different code for create and edit scenarios or use tokens such as Current User, Current Customer, Settings, and Helpers, which are always available.
You can conditionalize formulas to execute different code for record creation and record update by checking the current record id, {!id}. If it has a non-zero value, the formula is executing on an existing record and the current record context is available. If it evaluates to zero, the record is not yet created and the formula is executing for a new record.
The following example illustrates a pattern for conditionalizing a formula to execute different code for record creation and record update.
```
var recordId = {!id};
if(recordId > 0) {
  // Update Scenario
  if(!rbv_api.isFieldEmpty("Passenger1", recordId, "R7428"))
    return true;
} 
else {
  // New Record scenario
  return true;
}
```
The following example illustrates using tokens based on the Settings record, which is always available.
```
if("{!#SETTINGS.club_member#value}" != "")
{

  return true;
}
```
By default, fields with conditional edit or view permissions cannot be included in list view for non admin roles.

You can also set field permissions using the setPermissionsByRole REST method.