Workflows and tickets

Tickets are where workflows meet your team. A ticket can start a workflow, host its approvals and questions, and collect the replies that resume a paused run, all on one timeline instead of a scatter of notifications.

Three ways they work together

As a trigger. A workflow can start when a new ticket is created, when a new message arrives, or when an internal note is added, if your admins enabled those triggers for that workflow. Messages the workflow generates itself are ignored as triggers, so the same flow does not re-trigger forever.

As a linked run. A workflow run can be attached to a ticket your team is already viewing. Updates from the workflow (questions, approvals, outcomes) appear in the ticket thread when configured, so support sees a single timeline rather than a separate system to check.

As the place for human input. A paused workflow can wait for a reply on the ticket. When someone posts a normal message, the workflow resumes and reads the new context; the exact behavior depends on how the step was configured. This is the same surface where approvals appear, and it is where chat conversations land when Harriet escalates to your team through the channels described in Channels.

A typical flow: someone opens a ticket about a broken door lock, a workflow triggered on new ticket asks structured questions on the thread (building, floor, urgency), waits for the answers, then routes internally when complete.

When a run gets a ticket

Whether a new ticket appears depends on how the workflow started and how it is configured.

• Started from chat: Harriet creates a ticket only when that workflow has ticket creation enabled. New workflows leave this off, so a chat run stays ticketless until someone turns it on. Existing workflows keep whatever they already had. When a ticket is created, it becomes the usual place for approvals and follow-up messages tied to the run.
• Started by a ticket trigger: the workflow already has a thread, so Harriet continues on the same ticket rather than opening another.
• Started by a schedule, webhook, or other event: no ticket is auto-created just because the trigger fired. If human visibility is needed, build a step that explicitly creates or updates a ticket, or start the flow from chat when a tracked thread is wanted.

A team member typing "Start vendor onboarding" in web chat gets ticket #4521 with the run attached; the same checklist fired by a midnight schedule might only write to the run history unless the workflow includes a create-ticket step.

Keeping the noise down

Because workflow-posted messages never count as triggers, a run can post updates on the ticket it was triggered by without setting itself off again. Two habits keep the rest tidy:

• Align triggers with the right inbox or group so a finance workflow does not fire on IT tickets by mistake.
• Avoid bot-style test messages on live tickets while debugging; they can trigger the wrong automation.