# Understanding the order and interaction of automations in Kustomer > Kustomer processes automations in a defined sequence When multiple automations depend on the same attributes or outcomes understanding this order is critical Source: https://help.kustomer.com/en_us/understanding-the-order-and-interaction-of-automations-in-kustomer-HygfAukWzg Last updated: 2026-07-29T18:42:22.794Z Kustomer processes automations in a defined sequence. When multiple automations depend on the same attributes or outcomes, understanding this order is critical for designing reliable automation logic. ## In this article * [Understanding the automation execution order](#automation-execution-order) * [Understanding anti-patterns](#anti-patterns) * [Antipatterns with business rules](#antipatterns-with-business-rules) * [Using Customer Assist Rules](#customer-assist-rules) * [Using Workflows](#using-workflows) * [Using Business Rules](#using-business-rules) * [Using SLA Rules](#using-SLA-Rules) * [Using Queue Rules](#using-queue-rules) * [Designing reliable cross-automation logic](#cross-automation-logic) * [Testing and validating automation behavior](#testing-and-validating-behavior) ### Understanding the automation execution order Execution of events is partially ordered, and re-evaluates as rules are triggered. There is an **initial pass**, a **re-trigger** pass, and **async re-entry** passes. All automations operate on the conversation record. Updates from any automation immediately modify this shared state and may trigger additional automations. Event → Initial Evaluation Pass ``` → Customer Assist Rules → Workflows are triggered → Business Rules → SLA Rules → Queue Rules → Skill Rules → Queue Assignment Rules ``` Async: ``` → Workflow executes later → Updates conversation → Triggers new evaluation cycle ``` Some automation behavior occurs outside this initial pass. Satisfaction survey sending, outbound webhooks, async customer creation, and other workflow triggers are driven by emitted events and background workers. These systems may run after the originating event, may apply their own send/filter/scheduling conditions, and may themselves produce additional updates or events. For this reason, they should be treated as asynchronous re-entry points rather than fixed positions in the initial automation order. The order below represents an **initial pass**. If no other rules trigger automations outside this sequence during this pass, execution occurs in this order: 1. Customer Assist Rules 2. Workflows 3. Business Rules 4. SLA Rules 5. Queue Rules * Skill Rules * Queue Assignment Rules When reasoning about automation interactions, think in terms of **cycles**: Event → evaluate eligible automations → update shared record → emit follow-up event(s) → re-enter evaluation/background processing as needed. Because of this, avoid relying on one automation’s side effects being visible to another automation in the same pass unless the specific behavior is documented for that automation. Use explicit conditions to prevent loops or unintended re-triggering when rules or workflows update fields they also listen to. ### Understanding anti-patterns Automation outcomes may vary if logic depends on asynchronous operations or multiple systems updating the same attribute. These anti patterns represent pitfalls that can lead to unintended behavior: * Routing inside Workflows * Assigning before Queue Rules unintentionally * Circular Business Rule updates * Cross-system dependencies without triggers ### Antipatterns with Business Rules Avoid relying on Business Rules to react to conversation updates while a Conversational Assistant is actively handling the conversation. During Assistant handling, the conversation’s `phase` is set to `excluded`. Business Rules do not evaluate updates while the conversation remains in this phase. They can evaluate again after Assistant handling concludes and the phase returns to `active`. For example, do not use a Business Rule when an action must occur immediately in response to a message, attribute change, or other update that happens during the Assistant interaction. Use a Workflow or an Assistant-native action for logic that must run during that period. ### Using Customer Assist Rules Customer Assist Rules determine which assistant handles a conversation. They run before all other automation types. **How Customer Assist Rules work** * Evaluate top to bottom. * First match wins. * If no rules match, the system assigns a default assistant. **Common use cases** * Assign assistants by channel, such as chat or email. * Route conversations by language or region. * Route conversations by topic or intent. **Best practices** * Place specific rules first and fallback logic last. * Always configure a default assistant to handle unmatched conversations. ### Using Workflows Workflows handle complex or multi-step automation logic. They trigger immediately when an event occurs, such as _Conversation Created_, but run asynchronously and do not block other automations. **How Workflows work** Because Workflows run asynchronously, they may complete after other automations have already evaluated. For example: * A Workflow sets a `language` attribute. * A Business Rule depends on that attribute. * The Business Rule may evaluate before the Workflow completes, causing the Business Rule to behave incorrectly. **Best practices** * Use Workflows for API calls, branching logic, and delays. * Avoid splitting dependent logic across Workflows and Business Rules when timing matters. * When downstream logic depends on a Workflow result, have the Workflow set an attribute or tag first, then trigger the dependent logic using a Business Rule. ### Using Business Rules Business Rules modify conversations based on defined triggers and evaluate top to bottom. **How Business Rules work** Business Rules trigger based on specific conversation events. Common trigger types include: * _Assigned_ * _First Inbound Interaction_ * _Inbound Interaction_ * _Marked Done_ * _Reopened_ * _All Updates_ * _Team Assigned_ * _Unassigned_ **Re-triggering behavior** Business Rules can trigger additional rules through updates. For example: * Rule A updates a tag. * Rule B depends on that tag. * Rule B runs immediately after Rule A. This creates layered automation logic, but introduces risk if rule ordering is not carefully controlled. > **Note:** Deploying AI assignment conditions creates a Business Rule that assigns the conversation to an AI team. **Best practices** * Order rules carefully to control execution flow. * Avoid circular updates that could cause repeated triggering. * Use the _All Updates_ trigger cautiously to prevent unintended cascades. ### Using SLA Rules SLA Rules apply service level expectations to conversations. They run after Business Rules and evaluate top to bottom, where the first match wins. Only one SLA applies per conversation. **Common use cases** * Apply faster response times for high-priority customers. * Set different SLAs by channel or region. **Best practices** * Place the most specific rules first. * Use attributes such as customer tier, language, or channel to target rules precisely. * Test overlapping conditions to confirm correct matching. ### Using Queue Rules Queue routing runs in two phases: Skill Rules run first, followed by Queue Assignment Rules. ### Using Skill Rules Skill Rules assign skills to conversations before routing. They run before Queue Assignment Rules and evaluate on all conversation updates. **How Skill Rules work** * Evaluate top to bottom. * Skills can be applied even if a conversation is already assigned. * Skills removed manually or by another rule are not re-added. Skill Rules apply skills to conversations before Queue Assignment Rules run. Skills can influence which agents or queues are eligible during routing, but applying or changing a skill does not automatically unassign, reassign, or move a conversation that is already assigned. To force routing to re-evaluate after a skill change, the conversation must be unassigned or updated by automation in a way that causes Queue Assignment Rules to run again. **Best practices** * Use Skill Rules to define agent capability requirements. * Keep rules specific and targeted. * Avoid broad conditions that could match unintended conversations. ### Using Queue Assignment Rules Queue Assignment Rules determine the final queue assignment for a conversation. **How Queue Assignment Rules work** * Run after Skill Rules. * Evaluate top to bottom. * First match wins. * Skip entirely if the conversation is not explicitly assigned. * Re-run if the conversation becomes unassigned. > **Note:** If a Business Rule assigns a conversation before Queue Rules run, Queue Assignment Rules are skipped entirely. **Best practices** * Centralize routing logic in Queue Assignment Rules. * Avoid assigning conversations earlier in the automation sequence unless intentional. * Use unassignment to force Queue Assignment Rules to re-evaluate. ### Designing reliable cross-automation logic When automations interact, timing and sequencing become critical. A common issue involves Workflows and Queue Rules running at different times. **Example: Workflow timing vs. Queue Rules** 1. A Workflow sets `customer_type = VIP`. 2. A Queue Rule routes VIP customers to a specific queue. 3. Queue Rules evaluate before the Workflow finishes. 4. The conversation routes incorrectly. **Recommended solution** Instead of assigning a queue directly in a Workflow: 1. Remove the existing queue assignment in the Workflow. 2. Allow Queue Assignment Rules to re-run automatically. **General design guidelines** * Keep routing logic centralized in Queue Assignment Rules. * Use Workflows to prepare data, not to make final routing decisions. * Use Business Rules to react to attribute changes. * Avoid designing logic that depends on asynchronous completion timing. ### Testing and validating automation behavior Automation behavior can vary based on timing and rule interactions. Before deploying automations in production, validate each path using test cases that reflect real-world conditions. **What to validate** * Rule execution order. * Attribute availability at the time rules evaluate. * Queue assignment accuracy. * SLA assignment correctness. * Re-trigger behavior under update conditions. **Recommended approach** Build test cases that cover different channels, attribute combinations, and timing conditions. Review automation logs to verify that execution order matches your design intent.