--- sourceDocument: Zurich ServiceNow AI Platform Administration sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/platform-administration Release : - zurich ft:locale : - en-US ft:publication_title : - Zurich ServiceNow AI Platform Administration ft:clusterId : - platadm bundleId : - platadm workflow : - Platform --- # Rule precedence # Precedence between data lookup, assignment, and business rules {#ariaid-title1} Release version: Zurich Updated July 31, 2025 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 Precedence between data lookup, assignment, and business rules This content explains the execution order of various scripts, engines, and rules in ServiceNow related to database operations such as insert, update, or delete. Understanding this order is crucial for ServiceNow customers to predict and control how data is processed and modified during these operations. Show full answer Show less ## Execution Order Details The execution sequence around a database operation is divided into several stages: * **Before Business Rules:** Scripts set to run before the database operation are executed first, differentiated by their order value (\< 1000 and ≥ 1000). * **Before Engines:** Multiple engines operate without a strict order, including approval, assignment, escalation, data policy, field normalization, role synchronization, execution plan, update version, data lookup, and workflow engines (default workflows). * **Database Operation:** The system performs the actual insert, update, or delete in the database. * **After Business Rules:** Scripts configured to run after the database operation execute, again split by order (\< 1000 and ≥ 1000). * **After Engines:** Engines such as label, listener, table notifications, role synchronization, text indexing, update sync, deferred workflows, and trigger engine execute without a strict order. * **Email Notifications:** Notifications related to insert, update, or delete events are sent based on notification weight. * **Async Business Rules:** These run asynchronously in the background after form submission and after scheduled jobs created from the business rule run, providing non-blocking processing. ## Key Considerations for ServiceNow Customers * Client-side scripts run before form submission and server processing, so they occur before any database operation. * Understanding the order helps troubleshoot and design processes where data lookup, assignment rules, and business rules interact. * Assignment rules and data lookup engines run before the database operation, allowing them to influence record data prior to persistence. * Async business rules enable deferred processing, which is useful for non-critical actions that should not delay user experience. ## Related Functionality and Resources * Assignment rules and data lookup rules modules help automate task assignments and data enrichment. * Workflow assignments integrate with these processes for complex task management. * ServiceNow provides examples and guides such as baseline assignment rules to assist with configuration. 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, executes 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 aren't 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) {#c_PrecBetweenAssignmentAndBusRules__ul_qgd_vdj_dq} 3. Before business rules: Scripts configured to execute before the database operation with an order greater than or equal to 1000. 4. Database operation: The system performs the insert, update, or delete operation on the database. 5. After business rules: Scripts configured to execute after the database operation with an order less than 1000. 6. After engines. The following aren't 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). {#c_PrecBetweenAssignmentAndBusRules__ul_ck4_h2j_dq} 7. Email notifications: The following are executed based on notification weight: * Notifications sent on an insert, update, or delete * Event-based notifications {#c_PrecBetweenAssignmentAndBusRules__ul_rgj_n2j_dq} 8. After business rules (active records only): Scripts configured to execute after the database operation with an order greater than or equal to 1000. {#c_PrecBetweenAssignmentAndBusRules__ol_qjj_rdj_dq} 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. **Related concepts** * [Assignment rules module](https://www.servicenow.com/docs/JUPta_fwWYDgSygxll~9Xg "The Assignment rules module allows you to automatically set a value in the assigned_to and assignment_group fields when a set of conditions occurs.") * [Data lookup rules](https://www.servicenow.com/docs/Ar0OSZBBgBxurMEEu2yYsg "Data lookup rules offer a generic way to change any field value, not just assignment fields.") * [Workflow assignments](https://www.servicenow.com/docs/zzuRG39dDPXt40MVp6QFeg "An alternative to creating data lookup or assignment rules is to create one or more workflow tasks that assign a task record as part of a workflow.") **Related tasks** * [Create an assignment rule](https://www.servicenow.com/docs/k9J1wUqoU89ogYGPBVJuEg "Automatically assign a record according to one or more conditions in an assignment rule. Assignment rules are designed to run at the time you open a record.") * [Create an assignment data lookup rule](https://www.servicenow.com/docs/OBNmtiX0FShczKRPyAEEeA "Automatically assign a record using Data Lookup and Record Matching.") **Related reference** * [Baseline assignment rules example](https://www.servicenow.com/docs/Z9vSjmgInM0WLi0AQhZ1gg "A baseline instance contains certain assignment rules.") **Related topics** * [Business rules](https://www.servicenow.com/docs/access?context=c_BusinessRules&version=zurich&pubname=zurich-api-reference&ft:locale=en-US)