Conditions are the criteria that determine when a support expert agent will be executed. They are essential to ensure that the configured actions only occur in specific and relevant contexts within a ticket.
How condition blocks work
When setting up a support expert agent, you will define activation conditions within two blocks:
- Combined Condition (AND): ALL conditions in this block must be true for the agent to be triggered.
- Independent Condition (OR): At least ONE of the conditions must be true for the agent to be triggered.
If you use both blocks at the same time, the agent will only be triggered if all conditions in the first block are met and at least one condition in the second block is true.
What are trigger conditions?
Not every condition can trigger an agent on its own. For the support expert to function properly, you must include at least one trigger condition—that is, a condition that represents a specific event or change in the ticket.
See the difference:
Category | Example | Is it a trigger condition? | Reason |
Ticket status | Ticket: is → Open | ✅ Yes | Represents a specific moment: when the ticket is opened. |
Ticket: Status → Equals Closed | ❌ No | It is only a current characteristic of the ticket, without indicating a moment of change. |
⚠️ Attention: If your agent doesn't have any trigger condition, it won't be activated.
You can use more than one trigger condition, but remember to combine them carefully so they don’t prevent the agent from being executed.
Sentences as trigger conditions
If the trigger condition involves a sentence, the agent will only be activated with an exact match. For example: if the condition is “password change,” the agent will only be executed when that full phrase appears. Isolated terms like just “change” won’t be enough.
Time-based conditions
Time-based conditions (such as Dwell time or Not recorded for [X] hours) work best when combined with classification conditions, such as:
- Urgency
- Category
- Service
- Status
- Justification
This combination improves performance and avoids unnecessary triggers.
In summary:
|
Practical use cases
See below some examples of conditions and how they can be used in practice:
Condition | How it works in practice |
Ticket: is → Reopened | Triggers the agent whenever a reopened ticket by a customer is identified. Can be used to automatically reclassify or reassign the ticket. |
Ticket: Status → Equals to On Hold | Used to apply actions to tickets that are on hold, such as sending a notification to resume service or reassigning to another agent. |
Ticket: Due date → Changed | Performs actions whenever the ticket's due date is changed. Ideal for logging the reason for the change or notifying the requester. |
Ticket: Requester: Type → Equals to Company | Allows you to apply actions only when the requester is a company, such as automatically redirecting to a corporate support group. |