Precedence between data lookup, assignment, and business rules

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 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 Precedence between data lookup, assignment, and business rules

    This content explains the precise order in which various scripts, rules, engines, and workflows execute around database operations such as insert, update, or delete in ServiceNow. Understanding this execution order is critical for configuring automation, data processing, and notifications effectively to ensure the desired system behavior.

    Show full answer Show less

    Execution Order Details

    Execution is divided into phases before, during, and after the database operation, with some processes running asynchronously.

    • Client-side scripts (running in the browser) always execute before the form is submitted to the server.
    • Before business rules run two sets of scripts with order values less than 1000 and greater or equal to 1000, separated by the engines and data lookup engine.
    • Engines that run before business rules include assignment rules, approval engine, escalation engine, data policy engine, field normalization, role synchronization, execution plan, update version, data lookup, and workflow engine (default workflows).
    • The database operation (insert, update, delete) occurs next.
    • After business rules execute scripts with order values less than 1000 immediately after the database operation.
    • After engines include label engine, listener engine, table notifications, role synchronization, text indexing, update sync, workflow engine (deferred workflows), trigger engine, and email notifications.
    • Notifications run based on the weight of the notification records and can be event-based or triggered on insert, update, or delete.
    • Finally, scripts configured to execute after business rules with order greater or equal to 1000 run.

    Async business rules execute similarly to after business rules but run asynchronously in the background after the user submits the form and after a scheduled job is created. This allows processing to occur without blocking the user interaction.

    Why This Matters

    For ServiceNow customers, understanding this sequence helps in:

    • Designing and troubleshooting business logic to ensure rules and scripts trigger in the intended order.
    • Configuring assignment rules and data lookup rules effectively, knowing when they apply relative to other processing.
    • Managing workflows and notifications so they happen at the correct stage during record changes.
    • Optimizing system performance by leveraging asynchronous business rules where appropriate.

    Related Resources

    To further implement or customize this behavior, customers should explore modules and tasks such as:

    • Assignment rules module
    • Data lookup rules
    • Workflow assignments
    • Creating assignment rules and assignment data lookup rules

    Scripts, assignment rules, business rules, workflows, escalations, and engines all take effect in relation to a database operation, such as insert or update. In many cases, the order of these events is important.

    Note:
    Client-based code that executes in the browser, using Ajax or running as JavaScript, will always execute before the form submission to the server.
    The order of execution is as follows:
    1. Before business rules: Scripts configured to execute before the database operation with an order less than 1000.
    2. Before engines. The following are not executed in any specific order:
      • Approval engine (for task and sys_approval_approver tables)
      • Assignment rules engine (for task tables)
      • Escalation engine
      • Data policy engine
      • Field normalization engine
      • Role engine - keeps role changes in sync with sys_user_has_role table (for sys_user, sys_user_group, sys_user_grmember, and sys_user_role tables)
      • Execution plan engine (for task tables)
      • Update version engine - creates version entry when sys_update_xml entry is written (for sys_update_xml table)
      • Data lookup engine inserts or updates
      • Workflow engine (for default workflows)
    3. Before business rules: Scripts configured to execute before the database operation with an order greater than or equal to 1000.
    4. The data base operation (insert, update, delete).
    5. After business rules: Scripts configured to execute after the database operation with an order less than 1000.
    6. After engines. The following are not executed in any specific order:
      • Label engine
      • Listener engine
      • Table notifications engine
      • Role engine - keeps role changes in sync with sys_user_has_role table (for sys_user, sys_user_group, sys_user_grmember and sys_user_role tables)
      • Text indexing engine
      • Update sync engine
      • Workflow engine (for deferred workflows)
      • Trigger engine (for all Workflow Studio flows)
    7. Email notifications. The following are executed based on the weight of the notification record:
      • Notifications sent on an insert, update, or delete
      • Event-based notifications
    8. After business rules (Only active records). Scripts configured to execute after the database operation with an order greater than or equal to 1000.
    Note:
    Like After business rules, Async business rules execute their logic after a database operation occurs. Unlike After business rules, Async business rules execute asynchronously, running in the background simultaneously with other processes. Async business rules run after the user submits the form and after the scheduler runs the scheduled job created from the business rule. The system creates a scheduled job from the business rule after the user submits the form but before any action is taken on the record in the database.