Policies and rules properties in Table Builder

  • Release version: Xanadu
  • Updated August 1, 2024
  • 8 minutes to read
    • Summarize
    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

    This guide explains how ServiceNow customers can configure field-level policies and rules within Table Builder to control form behavior, access, and automation. It covers UI Policies, Access Control Rules, Client Scripts, Business Rules, and Workspace View Rules, outlining their key fields and practical application to tailor user experiences and secure data access.

    Show full answer Show less

    UI Policies

    UI Policies enable dynamic form behavior based on user roles and input conditions. Customers can:

    • Set policies on specific tables and domains, control activation, and specify order of execution to resolve conflicts.
    • Configure policies to apply on form load or only on field changes, and optionally reverse actions when conditions are false.
    • Manage inheritance of policies in extended (child) tables, where child policies always run before parent policies regardless of order.
    • Define conditions that trigger policies, and specify field actions such as setting fields mandatory, visible, read-only, or clearing values.

    Example: Require the "Additional comments" field when the incident state changes to "Awaiting user info."

    Access Control Rules

    Access Control Rules manage permissions for forms or data resources based on roles, conditions, and scripts. Key points include:

    • Assigning user names or roles that can access the resource, with support for all users via the asterisk () wildcard.
    • Defining the type of object controlled (records, scripts, UI pages, etc.) and the operations allowed (read, write, execute, etc.).
    • Activating or deactivating rules and optionally enabling admin override checks.
    • Including script-based conditions for complex access logic.

    Client Scripts

    Client Scripts provide additional control over form field behavior by running scripted logic during specific events like onLoad, onChange, or onSubmit. Customers can:

    • Name scripts, assign them to tables, and activate or deactivate them.
    • Specify the application UI type (desktop, mobile) and which views the scripts apply to.
    • Choose script types such as onCellEdit or onChange to customize form interactivity based on user input.

    Business Rules

    Business Rules automate backend logic to modify data or enforce rules during database operations. Customers can:

    • Name and assign rules to tables, specifying when they run (before, after, async, display).
    • Define conditions and required user roles for rule execution.
    • Set actions like insert, update, or delete on fields, and control transactional behavior including aborting database operations.
    • Order multiple rules to control execution sequence.

    Workspace View Rules

    These rules control how users see and interact with workspace views:

    • Define rules by name, table, and view, optionally restricting by roles and conditions.
    • Control UI features such as hiding section navigation, disabling section collapsing, and setting default tab order for forms.

    Practical Benefits

    By configuring these policies and rules, ServiceNow customers can:

    • Create dynamic, responsive forms tailored to user roles and input.
    • Enforce security and data access policies precisely.
    • Automate backend processing to maintain data integrity and streamline workflows.
    • Customize workspace experiences to improve usability and efficiency.

    You can configure the basic field policies and rules for any field that you work with in Table Builder.

    UI Policies

    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.

    The following table shows the field descriptions for the Policy details section when adding or editing a UI policy.
    Table 1. Policy details
    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.
    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.
    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.
    The following table shows field descriptions for the When these conditions are met section when adding or editing a UI policy.
    Table 2. When these conditions are met
    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.
    The following table shows field descriptions for the Do the following section when adding or editing a UI policy.
    Table 3. Do the following
    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
    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
    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
    Clear the field value

    Option to clear the specified field if the conditions are met.

    Access control rules

    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.
    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, john.smith). 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.
    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
    For more information on object types, see ACL matching requirements for objects.
    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.
    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.
    Advanced Option to associate a script with the rule.

    Client Scripts

    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

    The following table shows field descriptions for the Client Scripts rules section.
    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
    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.

    Business Rules

    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.

    The following table shows field descriptions for the Business Rules rules section.
    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.

    Workspace view rules

    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.
    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.