Start with a decision you keep making.
Perhaps new billing questions need the same department. Perhaps a waiting ticket needs a reminder. An automation is useful when you can explain the event, the checks and the next action clearly.
We’ve built TruCom rules around those parts: a trigger starts the evaluation, conditions decide what matches, and actions carry out the steps you have chosen.
Choose a small task you can describe in a sentence.
Look for a repeated decision that already has an agreed next step. “Send new, unassigned billing tickets to Billing” is specific enough for the next teammate to understand and for you to test.
Write down what should happen and what should be left alone. For the example rule, billing tickets without an owner are included. Other topics and tickets already being handled should keep their current place.
Name the rule after its purpose. Someone reviewing it later should be able to tell which work it handles without reading every setting first.
The trigger is the event that starts the check.
Choose a supported event that fits the moment you want the rule to consider. That might be a ticket being created, a customer sending a message, a status changing or a service target becoming due.
The event determines the kind of record the rule works with and the fields and actions available to it. A ticket rule has ticket conditions and actions; a feedback rule works with the supported feedback fields and steps.
Our example starts when a ticket is created and checks its current tags. If your team adds the billing tag later, use a trigger such as Ticket tags changed for that process. Choose the event that actually happens when you need the decision.
Time-based ticket rules are useful for work that has been inactive or has remained resolved for a chosen period. Set the timing around your support routine so the reminder has a clear reason.
Make the matching conditions say what you mean.
Conditions narrow the work the trigger brings in. You can check supported details such as status, priority, tags, department or whether a record has an assignee. The choices depend on the trigger and record type.
Every check needs to match.
For our routing example, the ticket must have the billing tag and have no assignee. Both parts describe the work we want to move.
One matching check is enough.
The same conditions would include any unassigned ticket, even one about another topic. They would also include a billing ticket already owned by Amina.
Use the comparison that fits the field: an exact value, a tag match, an empty value or a supported numeric threshold. The rule uses those recorded values. A subject that mentions an invoice does not itself create a billing tag.
Test a request that should match and one that should stay out. The difference between the two tells you whether the conditions describe your process clearly.
Choose what changes when the rule matches.
In our example, the actions assign the ticket to Chidi in Billing, set its priority to High and send an internal notification to the assigned teammate. The sequence is deliberate: the assignment is in place before the notification goes to its recipient.
Other supported ticket actions include updating status, adding tags and leaving an internal note. Conversation rules can help with assignment, priority and status. The available action list follows the event and type of work you chose.
Notifications in automations are for supported internal audiences, such as an assignee, workspace managers or a selected teammate. Your team still handles customer correspondence through the inbox and tickets. Knowledge-based AI replies have their own settings and workflow.
Rules also connect to work beyond the inbox. Feedback events can help assign and organise feature requests. Service events can notify the team, and incident rules can create or reuse a linked urgent ticket for escalation.
Check what is true when the work is ready to run.
A rule can run after its event or use a configured delay. TruCom checks the current record’s conditions when execution begins. If someone has already picked up the ticket during the wait, an unassigned-only rule can skip it.
For time-based ticket inactivity, the reference is the last public reply, or creation if there has not been one. An internal note does not reset that public-reply reference. Rules for time since resolution use the ticket’s resolution time.
Choose delays and time thresholds that give your team a useful prompt. A reminder should help someone review progress and decide on an update; it should fit the expectations you have set with the customer.
When you add a delayed rule, check who is responsible while it waits and what happens if the request changes. Include that situation in your test.
Use a dry run before making the rule part of the day.
Select an appropriate record from your workspace and run a test. A dry run evaluates the conditions, shows whether they match and lists the actions that would be planned. It records the test without carrying out those actions.
- Try the straightforward match.
For the billing example, choose a ticket with the billing tag and no assignee. Check the destination, priority and notification recipient.
- Try a request that should stay out.
Use a different topic. Then try a billing ticket that already has an owner. With All conditions, both should be left alone.
- Read each planned step.
Check the people, departments and values the actions refer to. A matching test helps confirm the decision; the destinations must also remain available when the live action runs.
Once the examples behave as intended, enable the rule and review its early runs. Access and execution allowances follow your workspace’s plan and configuration.
Review what happened, including the work that was skipped.
The execution record gives your team a place to see the condition checks, action results and any reason a run could not continue. Read the result in the context of the request you were trying to handle.
The run is scheduled or being processed. Review its progress before assuming the changes have happened.
The actions finished. Read their results and check the record when confirming the outcome.
The conditions may no longer match, or the rule may have been disabled. Leaving the record alone can be the intended result.
Read the recorded reason. A blocked run may need a plan or rule-limit check; a failed action may need its destination or configuration reviewed.
If an action fails, later actions are not reached. Check the action results and the current record before repeating work or changing the rule.
You can disable a rule while your process changes. Disabled rules stop accepting new work, and queued runs check that the rule is still enabled before proceeding. Disabling a rule does not undo actions that have already happened.
Keep related rules easy to follow. Duplicate-event checks and loop protection help limit repeated work, while your team should still review rules that affect the same fields or responsibility.
Start with one useful rule, test the requests it should include and exclude, then review the result with the people who do the work.