---
sourceDocument: Yokohama Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/application-development

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Policies and rules properties in Table Builder

# Policies and rules properties in Table Builder {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 8 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Policies and rules properties in Table Builder

In ServiceNow's Table Builder, you can configure fundamental field policies and rules that dictate form behavior, access, and automation.
These configurations help tailor forms and data access based on roles, conditions, and input, enhancing user experience and data security.
Show full answer Show less  

## UI Policies

UI Policies control form appearance and behavior dynamically, based on user roles and input conditions. Key configurable properties include:

* **Short description:** Summarizes the policy purpose.
* **Table and Domain:** Specifies the target table and domain.
* **Order:** Defines the sequence for policy execution; higher numbers run later.
* **Active status:** Only active policies apply.
* **View applicability:** Policies can apply to all or specific form views.
* **On load option:** Determines if policy runs on form load or only on field changes.
* **Reverse if false:** Reverses actions when conditions become false.
* **Inheritance:** Controls if child tables inherit policies from parent tables, with child policies running before parent ones regardless of order.

Conditions triggering UI policies use a condition builder, and actions can set fields as mandatory, visible, read-only, or clear values as needed.

## Access Control Rules

Access control rules manage user permissions to forms and data based on roles, conditions, and scripts. Important fields include:

* **Name:** Specifies user(s) by username or allows all users with ''.
* **Description:** Explains what the rule controls.
* **Type and Operation:** Defines the object type (e.g., records, scripts) and allowed actions (e.g., read, delete).
* **Active status:** Enables or disables the rule.
* **Roles and Conditions:** Limits access to users with specified roles and conditions.
* **Admin overrides:** Optionally enforces evaluation for admin users.
* **Advanced scripting:** Allows associating scripts to customize access logic.

## Client Scripts

Client Scripts control form field behavior through scripts that run at specific events such as onLoad, onChange, or onSubmit. Key properties include:

* **Name and Description:** Identify and explain the script.
* **Table and UI Type:** Specify where and on which application type (desktop/mobile) the script applies.
* **Active status:** Determines if the script is operational.
* **Trigger type and field:** Define when the script runs and on which field.
* **View and inheritance:** Limit script execution to certain views and specify if it applies to extended tables.

## Business Rules

Business Rules automate server-side actions such as modifying field values or controlling database transactions. Essential fields are:

* **Name and Table:** Identify the rule and target table.
* **Active status:** Enables or disables the rule.
* **Execution timing:** Specifies when the rule runs (display, before, async, or after DB operations).
* **Filter and role conditions:** Define when the rule should execute based on field values and user roles.
* **Actions and field values:** Define the operations (insert, update, delete) and fields affected.
* **Messages and abort option:** Control user notifications and whether to abort database transactions.
* **Order:** Determines execution precedence when multiple rules apply.

## Workspace View Rules

Workspace view rules customize how users see workspaces based on roles and conditions. Configuration options include:

* **Name and Table:** Identify the rule and target form or table.
* **View:** Specifies which form view to render; defaults apply if unspecified.
* **Roles and Conditions:** Limit rule application based on user roles and conditions.
* **UI behavior options:** Control section navigation visibility, section collapsing, and default tab order.

By utilizing these policy and rule properties in Table Builder, ServiceNow customers can efficiently customize form behavior, enforce security, and automate processes tailored to their organizational needs.  
You can configure the basic field policies and rules for any field
that you work with in Table Builder.

## UI Policies {#ui-policy-fields__section_yr2_ywv_fsb}

The UI Policies section enables you to configure how forms appear based on roles and user
input.

To understand the basic field properties, see [Create a UI policy in Table Builder](https://servicenow-prod.fluidtopics.net/IX6uRO1XDx8_aAC5g7xPZw#create-ui-policies "Configure UI policies in Table Builder to adjust how forms appear based on roles and user input.").  
The following table shows the field descriptions for the Policy details section when adding or editing a UI policy.{#ui-policy-fields__id_wdg_tvm_lsb__entry__2}

| Field | Description |
|-|-|
| Short description | Short summary of the UI policy. |
| Table | Data table that the policy applies to. |
| Domain | Domain that the choice resides in. |
| Order | Sequence for processing, from the lowest number to the highest number. If two policies conflict, the UI policy with the higher number runs. 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. |
| Active | Status of the UI policy. Only active UI policies are applied. |
| Apply to all views/Apply to view \[Advanced settings\] | Option for specifying whether the UI policy applies to all form views or specific views. For more information on form views, see [View management](https://www.servicenow.com/docs/access?context=view-management-overview&version=yokohama&pubname=yokohama-platform-user-interface&ft:locale=en-US). |
| On load \[Advanced settings\] | Option for specifying that the UI policy behavior should be performed OnLoad as well as when the form changes. 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: * 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. * In the UI Policy Actions list, creates a record that makes the Additional comments field required when the condition is met. {#ui-policy-fields__ul_q3y_bvm_lsb} |
| Reverse if false \[Advanced settings\] | Option 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). |
| Inherit \[Advanced settings\] | Option for specifying whether extended tables inherit this UI policy. 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: * A child table has a UI policy with theOrder value 500 that shows the Urgency field when its conditions are met. * 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. * 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. {#ui-policy-fields__ul_r3y_bvm_lsb} |
[Table 1. Policy details]

{#ui-policy-fields__id_wdg_tvm_lsb}  
The following table shows field descriptions for the When these conditions are met section when adding or editing a UI policy.{#ui-policy-fields__id_u1v_svm_lsb__entry__2}

| Field | Description |
|-|-|
| Condition set | Conditions 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. 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. |
[Table 2. When these conditions are met]

{#ui-policy-fields__id_u1v_svm_lsb}  
The following table shows field descriptions for the Do the following section when adding or editing a UI policy.{#ui-policy-fields__id_rw2_svm_lsb__entry__2}

| Field | Description |
|-|-|
| Field name | Field on the selected table to which the UI policy performs an action if conditions are met. Note: If the specified field is not on the form, the UI policy performs the action on the variable with the same name. |
| Mandatory | List for specifying how the UI policy affects the required state of the field. The choices are the following: * Leave alone * True * False {#ui-policy-fields__ul_szb_cvm_lsb} |
| Visible | List for specifying how the UI policy affects the visible state of the field, that is, whether it appears. The choices are the following: * Leave alone * True * False {#ui-policy-fields__ul_tzb_cvm_lsb} |
| Read only | List for specifying how the UI policy affects the read-only state of the field. The choices are the following: * Leave alone * True * False {#ui-policy-fields__ul_uzb_cvm_lsb} |
| Clear the field value | Option to clear the specified field if the conditions are met. |
[Table 3. Do the following]

{#ui-policy-fields__id_rw2_svm_lsb}

## Access control rules {#ui-policy-fields__section_y3x_syv_fsb}

The Access control rules section enables you to configure access to the specified resource
based on role, condition, and script criteria being met.  
The following table shows field descriptions for the Access control rules section.{#ui-policy-fields__table_bpj_t1g_hsb__entry__2}

| Field | Description |
|-|-|
| Name | Names 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, <kbd class="ph userinput">john.smith</kbd>). Each name must have a corresponding user record in hi.servicenow.com. * Enter multiple names and separate them by commas if multiple users have permission to access the form or data. * Enter an asterisk (\*) as the name to enable all users to access the form or data. {#ui-policy-fields__ul_skl_2lb_snb} |
| Description | Overview of what the access control rule restricts or enables. |
| Type | Type of object the access controls, including the following: * Client-callable script includes * Processor * Record * UI page * UX route {#ui-policy-fields__ul_okr_dgg_hsb} For more information on object types, see [ACL matching requirements for objects](https://www.servicenow.com/docs/access?context=access-control-rules&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US). |
| Operation | Type 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://www.servicenow.com/docs/access?context=acl-rule-types&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US). |
| Active | Active state of the rule: true :   The rule is active and available for use. false :   The rule is inactive and unavailable for use. |
| Condition | Any conditions that apply to the rule. |
| Roles | Any roles the rule applies to. |
| Admin overrides | Option 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://www.servicenow.com/docs/access?context=t_EvalAdmOverrideAccLevel&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US). |
| Advanced | Option to associate a script with the rule. |
[ ]

{#ui-policy-fields__table_bpj_t1g_hsb}

## Client Scripts {#ui-policy-fields__section_grb_5yv_fsb}

The Client Scripts rules section enables you to create scripts that control how form fields
appear based on defined criteria.

For a complete list of values for client script fields, see [Client script form](https://www.servicenow.com/docs/access?context=client-scripts&version=yokohama&pubname=yokohama-api-reference&ft:locale=en-US)  
The following table shows field descriptions for the Client Scripts rules section.{#ui-policy-fields__table_e4d_1ph_hsb__entry__2}

| Field | Description |
|-|-|
| Name | Name for the script. |
| Description | Overview the script's functionality and purpose. |
| Table | Table or form that the script is available for. |
| Active | Active state of the script: true :   The script is active and available for use. false :   The rule is inactive and unavailable for use. |
| UI type | Type of application the script is available for, such as desktop or mobile. |
| Type | When the script runs on the table or form, including the following: * onCellEdit * onChange * onLoad * onSubmit {#ui-policy-fields__ul_vnq_zqn_hsb} |
| Field name | Field the script is run on. |
| View | Views on which the client script runs (not applicable to global scripts). |
| Inherited | Indicates whether the client script applies to extended tables. |
[ ]

{#ui-policy-fields__table_e4d_1ph_hsb}

## Business Rules {#ui-policy-fields__section_kbv_5yv_fsb}

The Business Rules section enables you to create business rules to accomplish tasks like
automatically changing values in form fields when certain conditions are met.

For a complete list of values for business rules, see [Create a business rule](https://www.servicenow.com/docs/access?context=c_BusinessRules&version=yokohama&pubname=yokohama-api-reference&section=t_CreatingABusinessRule&ft:locale=en-US).  
The following table shows field descriptions for the Business Rules rules section.{#ui-policy-fields__table_a24_wtn_hsb__entry__2}

| Field | Description |
|-|-|
| Name | Name for the business rule. |
| Table | Table or form that the business rule runs on. |
| Active | Active state of the business rule: true :   The business rule is active and available for use. false :   The business rule is inactive and unavailable for use. |
| When | When the business rule executes: display, before, async, or after the database operation is complete. |
| Filter conditions | Conditions created using the condition builder to determine when the business rule should run based on the field values in the selected table. |
| Role conditions | Roles that users who are modifying records in the table or form must have for the business rule to run. |
| Actions | Actions taken by the business rule on the specified fields, such as insert, update, and delete. |
| Set field values | Table or form fields that the action executes on. |
| Add message | Whether a message appears when this business rule is run: true :   A message appears when the business rule is run. false :   No message appears when the business rule is run. |
| Abort action | Whether the business rule aborts the current database transaction: true :   The business rule aborts the current database transaction when run. false :   The business rule doesn't abort the current database transaction when run. For example, on a before insert business rule, if the conditions are met, do not insert the record into the database. |
| Order | Indicates 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. |
[ ]

{#ui-policy-fields__table_a24_wtn_hsb}

## Workspace view rules {#ui-policy-fields__section_bnk_vyv_fsb}

The Workspace view section enables you to define rules to control how users view workspaces
based on criteria.  
The following table shows field descriptions for the Workspace view rules section.{#ui-policy-fields__table_mh3_p24_hsb__entry__2}

| Field | Description |
|-|-|
| Name | Name for the workspace view rule. |
| Table | Table or form that the workspace view rule is available for. |
| View | View that is used to render the form. The default view is used if this field is left empty or contains an invalid value. |
| Roles | Any roles the rule applies to. |
| Conditions | Any conditions that apply to the rule. |
| Hide section navigation | Option to enable or disable section navigation. |
| Disable section collapsing | Option to enable or disable section collapsing. |
| Default tab order | Order in which form tabs appear by default. |
[ ]

{#ui-policy-fields__table_mh3_p24_hsb}