| \n\nField\n\n | \n\nDescription\n\n |
|---|---|
| \n\nShort description\n\n | \n\nShort summary of the UI policy.\n\n |
| \n\nTable\n\n | \n\nData table that the policy applies to.\n\n |
| \n\nDomain\n\n | \n\nDomain that the choice resides in.\n\n |
| \n\nOrder\n\n | \n\nSequence for processing, from the lowest number to the highest number. If two policies conflict, the UI policy with the higher number runs.\n\n For inherited UI policies, the extended \\(child\\) table's UI policies run first. Then, the base table UI policies run, both from the lowest to the highest specified value.\n\n |
| \n\nActive\n\n | \n\nStatus of the UI policy. Only active UI policies are applied.\n\n |
| \n\nApply to all views/Apply to view \\[Advanced settings\\]\n\n | \n\nOption for specifying whether the UI policy applies to all form views or specific views. For more information on form views, see [View management](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-user-interface/view-management-overview.md).\n\n |
| \n\nOn load \\[Advanced settings\\]\n\n | \n\nOption for specifying that the UI policy behavior should be performed OnLoad as well as when the form changes.\n\n Check or clear the UI policy **On load** check box to control whether it runs every time a form is loaded and conditions are satisfied. In the following example, an administrator does not want an incident to enter the **Awaiting user info** state unless the user provides an explanation to the customer. The administrator creates a UI policy with the following settings:\n\n- In the When these conditions are met section, adds the condition **\\[State\\] \\[is\\] \\[Awaiting user info\\]** and clears the **On load** check box. The UI policy applies only when the state is changed to **Awaiting user info**.\n- In the UI Policy Actions list, creates a record that makes the **Additional comments** field required when the condition is met.\n\n |
| \n\nReverse if false \\[Advanced settings\\]\n\n | \n\nOption for specifying that the UI policy action should be reversed when the conditions of its UI policy evaluate to false. When the conditions are true, actions are taken and when they change back to false, the actions are reversed \\(undone\\).\n\n |
| \n\nInherit \\[Advanced settings\\]\n\n | \n\nOption for specifying whether extended tables inherit this UI policy.\n\n When a child table has an inherited UI policy from its parent table, the UI policy on the child table always runs first, regardless of the **Order** of the UI policies. In the following example:\n\n- A child table has a UI policy with the**Order** value **500** that shows the **Urgency** field when its conditions are met.\n- Its parent table has a UI policy with the same conditions that hides the **Urgency** field. The parent table UI policy has the **Order** value **100**.\n- Although the parent table **Order** field has a lower value, the child UI policy runs first and then the parent UI policy runs. When the conditions are met, the **Urgency** field is hidden.\n\n |
| \n\nField\n\n | \n\nDescription\n\n |
|---|---|
| \n\nCondition set\n\n | \n\nConditions that, if fulfilled, cause the UI policy to be applied. Conditions are built with the condition builder by using logic statements. To set conditions using a script, use a client script instead.\n\n Conditions are only rechecked if a user manually changes a field on a form. If the change is made by a UI action, context menu action, or through the list editor, it is not evaluated.\n\n |
| \n\nField\n\n | \n\nDescription\n\n |
|---|---|
| \n\nField name\n\n | \n\nField on the selected table to which the UI policy performs an action if conditions are met.\n\n**Note:** If the specified field is not on the form, the UI policy performs the action on the variable with the same name.\n\n |
| \n\nMandatory\n\n | \n\nList for specifying how the UI policy affects the required state of the field. The choices are the following:\n\n- **Leave alone**\n- **True**\n- **False**\n\n |
| \n\nVisible\n\n | \n\nList for specifying how the UI policy affects the visible state of the field, that is, whether it appears. The choices are the following:\n\n- **Leave alone**\n- **True**\n- **False**\n\n |
| \n\nRead only\n\n | \n\nList for specifying how the UI policy affects the read-only state of the field. The choices are the following:\n\n- **Leave alone**\n- **True**\n- **False**\n\n |
| \n\nClear the field value\n\n | \n\nOption to clear the specified field if the conditions are met.\n\n |
| \n\nField\n\n | \n\nDescription\n\n |
|---|---|
| \n\nName\n\n | \n\nNames each user who has permission to access the form or data. - Enter the names as firstname.lastname in lower case letters, separated by a period \\(for example, `john.smith`\\). Each name must have a corresponding user record in **hi.servicenow.com**.\n- Enter multiple names and separate them by commas if multiple users have permission to access the form or data.\n- Enter an asterisk \\(**\\***\\) as the name to enable all users to access the form or data.\n\n |
| \n\nDescription\n\n | \n\nOverview of what the access control rule restricts or enables.\n\n |
| \n\nType\n\n | \n\nType of object the access controls, including the following:- Client-callable script includes\n- Processor\n- Record\n- UI page\n- UX route\n\n For more information on object types, see [ACL matching requirements for objects](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/access-control-rules.md).\n\n |
| \n\nOperation\n\n | \n\nType of action the system can take on the specified object, such as delete or execute. Some objects, such as records, support multiple operations, while other objects, such as a REST\\_Endpoint, only support one operation. For more information on action types, see [ACL rule types](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/acl-rule-types.md).\n\n |
| \n\nActive\n\n | \n\nActive state of the rule:- **true**\n\nThe rule is active and available for use.\n\n- **false**\n\nThe rule is inactive and unavailable for use.\n\n\n |
| \n\nCondition\n\n | \n\nAny conditions that apply to the rule.\n\n |
| \n\nRoles\n\n | \n\nAny roles the rule applies to.\n\n |
| \n\nAdmin overrides\n\n | \n\nOption to force the rule's evaluation for admin overrides at the access level. For more information on admin overrides, see [Evaluate the admin override at the access level](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/t_EvalAdmOverrideAccLevel.md).\n\n |
| \n\nAdvanced\n\n | \n\nOption to associate a script with the rule.\n\n |
| \n\nField\n\n | \n\nDescription\n\n |
|---|---|
| \n\nName\n\n | \n\nName for the script.\n\n |
| \n\nDescription\n\n | \n\nOverview the script's functionality and purpose.\n\n |
| \n\nTable\n\n | \n\nTable or form that the script is available for.\n\n |
| \n\nActive\n\n | \n\nActive state of the script:- **true**\n\nThe script is active and available for use.\n\n- **false**\n\nThe rule is inactive and unavailable for use.\n\n\n |
| \n\nUI type\n\n | \n\nType of application the script is available for, such as desktop or mobile.\n\n |
| \n\nType\n\n | \n\nWhen the script runs on the table or form, including the following:- onCellEdit\n- onChange\n- onLoad\n- onSubmit\n\n |
| \n\nField name\n\n | \n\nField the script is run on.\n\n |
| \n\nView\n\n | \n\nViews on which the client script runs \\(not applicable to global scripts\\).\n\n |
| \n\nInherited\n\n | \n\nIndicates whether the client script applies to extended tables.\n\n |
| \n\nField\n\n | \n\nDescription\n\n |
|---|---|
| \n\nName\n\n | \n\nName for the business rule.\n\n |
| \n\nTable\n\n | \n\nTable or form that the business rule runs on.\n\n |
| \n\nActive\n\n | \n\nActive state of the business rule:- **true**\n\nThe business rule is active and available for use.\n\n- **false**\n\nThe business rule is inactive and unavailable for use.\n\n\n |
| \n\nWhen\n\n | \n\nWhen the business rule executes: **display**, **before**, **async**, or **after** the database operation is complete.\n\n |
| \n\nFilter conditions\n\n | \n\nConditions created using the condition builder to determine when the business rule should run based on the field values in the selected table.\n\n |
| \n\nRole conditions\n\n | \n\nRoles that users who are modifying records in the table or form must have for the business rule to run.\n\n |
| \n\nActions\n\n | \n\nActions taken by the business rule on the specified fields, such as **insert**, **update**, and **delete**.\n\n |
| \n\nSet field values\n\n | \n\nTable or form fields that the action executes on.\n\n |
| \n\nAdd message\n\n | \n\nWhether a message appears when this business rule is run:- **true**\n\nA message appears when the business rule is run.\n\n- **false**\n\nNo message appears when the business rule is run.\n\n\n |
| \n\nAbort action\n\n | \n\nWhether the business rule aborts the current database transaction:- **true**\n\nThe business rule aborts the current database transaction when run.\n\n- **false**\n\nThe business rule doesn't abort the current database transaction when run.\n\n\n For example, on a before insert business rule, if the conditions are met, do not insert the record into the database.\n\n |
| \n\nOrder\n\n | \n\nIndicates the sequence in which this business rule should run. If there are multiple rules on a particular activity, the rules run in the specified order specified, from lowest to highest.\n\n |