Build an operations workflow

An operations workflow runs internal work, such as routing a decision to your team. A bot handles a conversation; a journey follows customer activity. Choose the mode that matches the work you want to start.

Use one for work like this: a refund over a certain amount gets checked by a manager, a new supplier is verified before anyone orders from them, or a failed delivery becomes a ticket assigned to whoever covers that region.

The two buttons on Automations → Workflows are the choice: New workflow is this one, New Journey is the customer-facing one. In the list they're tagged Operations and Journey. Progress on a row opens that workflow's live runs.

Plan with Qyra

Describe the staff outcome you need. Qyra checks existing automations and available Work queue information before planning another workflow. Pending work does not by itself mean another workflow is needed; review the existing process and any reported problems first.

Choose an existing automation to change it, create a new one for additional work, or keep the setup. These choices prepare a review; they do not publish, run or complete the work.

Choose the Catalog items

Choose Everything, item types, categories or individual items in the automation's Catalog settings. The same choices are available in the mobile automation settings.

Everything, types and categories can include newly eligible items in future runs. Individually chosen items stay fixed. Changing the Catalog does not add items to a run that has already started.

An Order can start the automation when any of its items matches. Steps about those items stay limited to the matches. An invoice for the complete Order needs an explicit Complete Order choice; its amount still comes from the Order.

An invoice or support ticket without a Catalog item can start an automation only with Everything selected. A customer journey can also introduce selected items before a purchase, without treating the customer as having bought them.

Selecting an item does not add promotions, review requests or other steps. Tell Qyra what you want to achieve. Customer permissions, communication preferences and the rules for each action still apply.

What starts one

An operations workflow starts from a business event, not from a customer's own activity. The triggers it can use:

• Orders — Order Placed, Order Confirmed, Order Completed, Order Cancelled
• Order lines — Order Line Preparing, Ready, Dispatched, Fulfilled, Failed and Cancelled
• Invoices — Invoice Issued, Invoice Paid, Invoice Overdue, Invoice Voided, Invoice Needs Approval
• Payments — Payment Review Created, Payment Activity Confirmed
• Support tickets — Support Ticket Raised, Resolved and Reopened
• Manual Start or an API / Webhook Event

So "when an order completes, create a reminder for the team to check in" is an operations workflow on Order Completed.

Triggers about a customer's own actions — a new contact, a tag, a form, a lead stage, a booking, a campaign open, a new message — start journeys only. When internal work needs one of those, start a journey on it, or have the workflow start a journey with Start Customer Journey.

Workspace activity

Some workflows configured through the API start when a teammate adds Contacts, imports Contacts, creates a Campaign or sends a message, or when a Campaign completes. These triggers do not appear in the canvas trigger picker.

A message must have a recorded send result; saving or queueing it does not count. Imports wait for their final result, which may include partial or failed follow-up work. Check the import result before assuming every requested change was completed.

Choose the person who performed the action, or that person and workspace administrators. Campaign completion is automatic, so it requires administrators rather than an individual actor. If an action's result is still unknown, check its record before repeating it.

First-time workspace triggers configured through the API apply to the first recorded Contact addition, Campaign or Segment creation, or accepted email/SMS send. They start for the teammate who performed that action. They do not mark the workspace's Check/Mark Milestone flag; use Mark Milestone when the workflow's work is complete. These flags do not measure a customer's Goal.

What it can do that a journey can't

Five steps exist here and not in a journey. All five create work for people rather than send things to customers:

• Create Support Ticket
• Assign Conversation
• Move Lead to Stage
• Create Reminder
• Start Customer Journey — the handover. Internal work decides something, then puts the customer into a journey about it.

Operations workflows include an End step. A Journey Goal measures a business outcome and only stops further steps when its achievement settings say to exit.

Waiting for a person

Wait for Decision stops the workflow, asks someone, and carries on down whichever path they chose.

Those waiting decisions collect in the Work queue.

When the decision is about a customer message, choose Customer message and connect the later Email, SMS or WhatsApp step. The Work queue keeps the exact recipient and wording that was prepared. Approve allows Qcom to send that saved wording after its final checks; edits made to the workflow or template afterwards do not change it. Reject continues the run without sending the message. Qcom checks the customer, sending connection and permission again immediately before an approved message is sent.

The work queue

Under Automations, this is every decision waiting on an internal workflow.

Claim one to make it yours, so two people don't both work it. Then decide — the buttons are named for the kind of decision:

| Kind | Options | | --- | --- | | Approval | Approve · Reject | | Review | Complete review · Return | | Verification | Verify · Not verified | | Action required | Complete · Cannot complete |

A decision note is optional. Write one when you turn something down — it's what the next person sees.

Filter by My work, Unclaimed, Open, Completed, Rejected or Expired. Expired means the decision deadline passed. Open the task and its workflow run to check what happened next; expiry does not by itself prove the work completed or identify why nobody decided.

Progress

Open the workflow and switch to Progress. You get five counts, refreshed as you watch:

• Active — running now.
• Waiting — a decision is sitting in the Work queue.
• Needs attention — a waiting decision is overdue.
• Failed — these do not resolve themselves.
• Completed — finished.

Actions lists the waiting decisions for this workflow. Open a task to claim or decide it in the Work queue. The queue stays the place people work; Progress is where you see this workflow's runs.

Beneath Progress, every active run: which step it's on. Issues holds the failed ones. Open a run for its step history.

When a run fails

Three recoveries, on the run itself:

• Retry — run the failed step again after checking what it already did and correcting the cause.
• Resume — carry on from where it stopped.
• Stop — end it for good.

Retry all re-queues every failed run at once, with a confirmation first. Use it after fixing one cause that broke them all, not when they failed for different reasons.

Before retrying, inspect the step history and any order, payment, ticket or external change it started. A run can fail after some work completed. If a result is uncertain, establish what happened before repeating it. Fix the cause first; a broken connection will still be broken on another attempt.

What it needs

The Scale plan. Workflows — both operations workflows and journeys — are a Scale feature, along with Progress, the Work queue and journey analytics. Bots are not, so an inbox can still be answered automatically on a lower plan.

Related

• Build a journey
• Create an automation
• Save, publish, and go live
• What the builder tools do
• Choose what starts an automation