Automations
Rules that run on new threads, new comments, and status changes — set a field, assign an owner, or ping the team.
An automation is a rule on a project: when this happens, and these conditions hold, do these things. Manage them in Project → Automations.
Anatomy of a rule
Trigger
Exactly one of:
| Trigger | Fires when |
|---|---|
thread_created | New feedback arrives |
comment_created | Someone replies on a thread |
status_changed | A thread's status moves |
Conditions
All optional; every one you set has to hold for the rule to run.
| Condition | Matches on |
|---|---|
| Environment | The environment the thread was filed into |
| Issue type | The thread's type |
| Priority | The thread's priority |
| Status | The thread's status |
| URL path contains | Substring of the page path |
| Title contains | Substring of the thread title |
| Comment contains | Substring of the most recent comment |
Leave everything blank and the rule runs on every event of that trigger.
Actions
Any combination of:
- Set status
- Set priority
- Set issue type
- Assign to a workspace member
- Notify Slack — posts the rule name, project, and a link to the thread
- Notify email — emails the workspace's configured address
Recipes
Route critical production bugs to the on-call engineer.
Trigger thread_created; conditions environment = Production, priority =
Critical; actions assign to that person, notify Slack.
Catch checkout problems wherever they're reported.
Trigger thread_created; condition URL path contains /checkout; actions set
priority High, notify Slack.
Acknowledge a reopened thread.
Trigger status_changed; condition status = Open; action notify email.
Send everything from the client's staging link to one owner.
Trigger thread_created; condition environment = Staging; action assign to the
account lead.
Behaviour worth knowing
- Every matching rule runs. Rules aren't ordered and there's no first-match-wins. If two rules both set priority, the last one to apply wins — so prefer conditions specific enough that two rules don't fight.
- Rules don't re-trigger each other. A rule that changes status does not
fire your
status_changedrules, so you can't build a loop by accident. - Failures are contained. A rule whose Slack webhook is broken doesn't stop the other rules, and never blocks the thread from being created.
- Only the most recent comment is matched. "Comment contains" looks at the latest comment on the thread, not the whole history.
- Rules are per project. Copy a rule into each project that needs it.
Automations or integrations?
They overlap, and it's worth being deliberate:
| Want | Use |
|---|---|
| Every new thread posted to a channel | An integration |
| Some threads posted, based on conditions | An automation with Notify Slack |
| A ticket created in Linear / Jira / GitHub | The thread's right-click Integrations menu |
| Feedback pushed into your own system | An outbound webhook |
Automations need a Slack or email integration already connected at the workspace level before their notify actions can deliver anything.
Triage
Status, priority, assignees, labels, and custom issue types — the fields you use to turn a pile of feedback into a queue.
Feedback links & forms
Hosted pages that collect feedback from people who will never install the widget — a free-text form, a structured questionnaire, or a guest pass for the widget itself.