Automating workflows with rules

A rule represents a set of actions that are automatically run by the system when a particular event occurs on a ticket and certain conditions are met. For example, a rule can be used to:

• Add the label Order when new tickets are created that have subject starting with New Order and are from a specific sender (i.e. orders@your-domain.com)
  

• When the Refund label is added to a ticket, auto assign it to Nancy
  

There are many types of events that cause a rule to run in Enchant:

• a new ticket is created
  

• state is changed on a ticket
  

• ticket is assigned to a user
  

• a user is mentioned in a note
  

• a specific label or label of specific color is added or removed
  

• a customer or user has replied
  

• a specific satisfaction rating is received
  

• a user followed a ticket
  

• certain time period has passed since a label was added/removed, since state was changed, since assignee was changed, since reply/note was added etc.
  

Rules are a great tool for automating workflows but also come in handy for implementing custom SLA(s).

Add and update rules in the settings tab.

From the bottom left corner of the screen, click the cog icon on app navigation bar.

From the sidebar on the left, click on Inboxes option under the Product section:

For a specific inbox, click Rules

From the top right of the rules page, click the Add Rule button.

Here, you can name the rule and tweak it to automate the desired workflow:

In the above screenshot:

• Name: The name of the rule
  

• All of these conditions: Run the actions if all of these conditions pass. The first condition in this group identifies the event that will cause this rule check and run (if other conditions are met).
  

• Any of these conditions: Run the actions if any of these conditions pass
  

• Run these actions: These are the list of actions that will run if the conditions pass
  

Add conditions by clicking Add a condition button in either "all" or "any" sections. Select the desired condition from the options:

Let's look at what a rule condition looks like. A condition describes how a ticket attribute should compare to a certain value for the condition to be true. For example in the condition below:

• Ticket Attribute: Ticket Subject
  

• How it compares: does not contain
  

• Value: repairs
  

Any part of the condition that's a bold blue button allows you to customize it. Each condition provides a set of comparisons and values to choose from.

Currently, a rule conditions can be based on the following ticket attributes:

• Ticket Subject
  

• Ticket State
  

• Ticket Assignee
  

• Ticket Labels
  

• Ticket Type
  

• Ticket Attachment
  

• Ticket User Reply Count
  

• Ticket Customer Reply Count
  

• Ticket followers: users that are currently following the ticket
  

• Customer Name
  

• Customer Email Address
  

• Last Satisfaction Rating
  

• Receiving Email Address
  

• Email Headers (From, To/Cc)
  

• Email Body
  

If the rule's event condition (first condition that specifies when the rule will run) was based on a change such as state was changed or user was assigned, then additional conditions also become available:

• For state changed: Old State right before the state was changed
  

• For user assigned: Old User right before the assignee was changed
  

If the rule's conditions are met, then the actions specified in the Run these actions section are performed on the ticket.

Click Add Action button to select from a list of available actions to run.

Currently, rule actions can:

• Set the state
  

• Assign or un-assign the ticket
  

• Update subject
  

• Add a label
  

• Remove a label
  

• Clear all labels
  

• Add a user to followers
  

• Remove a user from followers
  

• Remove all followers
  

• Mark ticket as spam
  

• Send ticket to trash
  

• Move ticket to another inbox
  

• Stop processing rules (that come after in the list of rules -- read this section to understand when this action can be used)
  

Rules run in the order they are shown in the Settings page interface. Actions taken by a rule impact other rules that run after it. So, the order in which the rules are sorted is important.

You can change the order of rules using the Sort button on the Rules page:

A sort popup is shown with the rules that can be re-ordered by simply dragging and dropping them.

The actions performed by rules show up on ticket history similar to user activity. It also allows you to see whether something was done by a certain rule or a user.

Sometimes you need to create a rule that's very similar to another. Rather than creating it from scratch, you can start by cloning another from the rule listing.

Rules can easily be disabled from the rules listing. While a rule is disabled, it will not be checked for conditions to match when changes to tickets happen.

This also gives you time to implement new workflows completely and then turn it on only when you're ready to go forward.

Every time a ticket is updated, the system takes a single pass through all rules defined in the inbox of the ticket. So, each rule in the inbox is checked at least once but never more than once (a rule can be skipped if processing was stopped by a previous rule who's conditions were met). Here's a real example:

Let's say a ticket's state was changed to hold, and there are 4 rules defined in the ticket's inbox.

• Rule #1: event condition is when a ticket is created, so this one will not run.
  

• Rule #2: event condition is state is changed to hold or snooze, so for this rule other conditions will be checked. Let's say the conditions are met and the rule's action adds a label vendor query.
  

• Rule #3: event condition is when label vendor query is added. Note that at this point the ticket has two changes on it, the original state change and a label addition done by Rule #2. Since this rule runs when label is added, other conditions of this rule will be checked. Let's say they are also met and this rule's action assigns the ticket to a user John who is responsible for taking over and communicating with the vendor. And the rule's second action also includes stop processing rules.
  

• Rule #4: Since, the conditions of Rule #3 were met and it's actions stopped processing of further rules in the list, this condition will not be checked. If the conditions of Rule #3 were not met, the processing of rules would have continued and this rule would have been checked just like the previous 3 based on event and other conditions.
  

Changes made by a rule's actions impact the rules that come after it in the sequence but do no cause previous rules in the list to be checked a second time. This prevents the system from getting caught up in a loop and keeps things simpler so you know what to expect.

However, if the same ticket ends up going through changes later in its lifecycle such that the rule's conditions are met again, the same rule will run on it again on that ticket.