Features / Platform
Workflows
The repetitive parts, done for you
Rules that act when something happens: tag it, route it, notify someone, escalate it, or reply with something you have already written.
When
conversation.handoff_requested
And
Then
assign
Assign to the on-call owner
slack
Post to #support-escalations
add_tag
Tag it needs-human
Run log
A row is written whether it acted or not.
- executedpriya@beacondata
All three actions ran
- skipped_conditionssam@harborline
Priority was normal, the rule wanted high
- suppressed_cooldownpriya@beacondata
Same contact, still inside this workflow's cooldown
- suppressed_quietdev@northwind
Quiet hours. Held until morning rather than dropped
- suppressed_global_capana@harborline
This contact has had its automated messages for the week
What it does
- Triggers on the events the product publishes, from a handoff to a merged investigation
- Actions across conversations, tags, assignment and notifications
- Canned responses for the answers you give constantly
- Every run recorded, so you can see what fired and why
Without it
The same five clicks, several hundred times a week
You are the routing rule
Every morning you read the queue top to bottom, work out which ones are billing, which ones are bugs, and hand them to the right person. It takes twenty minutes and produces nothing except a queue in a slightly different order.
The escalation that sat there because nobody was told
A customer asked for a human on Friday afternoon. The handoff happened, the conversation moved, and not one person was notified. You found it on Tuesday, by which point they had asked what the cancellation process is.
Something sent that email and nobody knows what
A customer replies asking why they got the same onboarding message three times. You go looking, find four rules that could plausibly have done it, and there is no record of which one fired or how often.
How it works
A trigger, some conditions, some actions
Triggers are events the product actually emits: a conversation created or updated, a customer asking for a human, a message arriving, a mention in a note, a ticket created, linked, updated, assigned, resolved or moved between states, an investigation changing stage, and a group of captured reports being finalized. Actions send an email, enroll someone in a sequence, send a webhook, add a tag, assign a teammate, create a ticket, or post to Slack.
Routing rules run first, top to bottom
Before any of that, ordered rules look at the tag, priority, product, channel or a keyword and decide who owns it. First match wins, so reading the list from the top tells you exactly what will happen to a new message.
What that includes
- Before any of that
- ordered rules look at the tag
- priority
- product
- channel or a keyword
- decide who owns it
The rules cannot pile onto one person
Each workflow has a cooldown, and above them all sits an organization-wide cap on how many automated messages a single contact can get in a day, week or month. Out of the box that cap is three a week, and quiet hours hold the rest until morning.
Every run is recorded, including the ones that did nothing
A run is written down whether it acted or not, with the reason: conditions did not match, still inside the cooldown, held by quiet hours, blocked by the contact cap, the wrong product for this context, or the context moved while it was running. Failures are kept too.
What that includes
- still inside the cooldown
- held by quiet hours
- blocked by the contact cap
What it means for you
The queue is sorted before you open it.
The billing questions are with the person who knows billing and the outage reports are already marked urgent. Your first twenty minutes go on the hard conversation instead of on sorting.
The escalation reaches somebody on Friday
The moment a customer asks for a human, the person who should know is told. It reaches them while the customer is still at their desk and still willing to talk about it, instead of on Tuesday in a report.
You can prove what fired, and what deliberately did not
When someone asks why a customer got that message, or why they did not, the answer is a row with a reason on it. Nobody has to reason backwards from the customer's inbox.
The honest limit: The settings screen offers a few triggers that nothing in the product publishes yet, including the survey and feedback ones, so a workflow built on those will save and then never fire. Build on the events listed above. Separately, workflows are meant to sit under the same approval policies and caps as the rest of the product, and that binding is not enforced in code yet. Until it is, treat a workflow action as something that will run unattended, and keep it inside what you would let it do without you.