Plans and permissions:
- Add-on: AI agents, billed separately
- Create, edit, publish, and activate workflows: Admin, Manager, or Team Lead role, or a custom role with Workflows set to Can create, edit, and delete workflows
- Test a workflow: Admin, Manager, or Team Lead role, or a custom role with Workflows set to Can create, edit, and delete workflows or Can test and view workflows
- People with Can view workflows see the builder as read-only: the Build tab is called View, and Manage activation is called View activation.
Use workflows to tell your AI agents how to handle a specific kind of case, such as a cancellation request or an order status question. A workflow has a trigger, which decides which cases it handles, and a series of steps that look up data, branch, reply to the customer, and update the case. You build each workflow once and can run it on email, chat, and voice.
To open the builder, go to AI support > Workflows and select a workflow, or select Create workflow.
If you haven’t chosen what to automate yet, start with Planning workflows for automation.
Navigating the workflow builder
| Item | What it’s for |
|---|---|
| Workflow name and badges | The badges show the channels where the workflow is active, and when it was last changed. |
| Manage activation | Turns the workflow on or off for each channel. See Workflow activation. |
| More actions menu | View history lists past versions of the workflow. |
| Build tab | The builder, where you set the trigger and add steps. |
| Test tab | Runs the workflow against many saved cases at once. See Workflow bulk testing. |
| Monitor and View cases tabs | Show how the workflow performs on live cases. See Workflows page. |
| Trigger step | The first step, labeled with the workflow title. Select it to choose which cases the workflow handles. |
| + (Add next step) | Adds a step after the one it follows, ends the workflow there, or connects to a step that already exists. |
| Published version and Draft | Switch between the live workflow and your draft. See Save, publish, and clone. |
| Undo and Redo | Reverse or reapply your last change. |
| Test | Runs the workflow on one case or a test message. See Test a workflow. |
| Save as draft, Publish changes, Clone | Save your changes without affecting live cases, make them live, or copy the workflow. See Save, publish, and clone. |
How workflows work
- When a case comes in, Assembled compares it with the triggers of your active workflows and selects the workflow that matches. Case filters are checked first, then the selection criteria.
- A workflow runs only on the channels where it’s activated. A new workflow is Inactive on every channel until you change it in Manage activation.
- Steps run in order. A step can create variables, such as a value from Zendesk or a detail in the customer’s message, for later steps to use.
- Variables you reuse across workflows are called smart fields. See Smart fields.
- Changes you publish update the live workflow right away, including on channels where it’s Automated.
- To work on changes without affecting live cases, save a draft.
- You can build one workflow for several channels. Channel-specific behavior, such as skipping a step on voice calls, can be handled inside the workflow with a Guide step or a condition.
Create a workflow
- Go to AI support > Workflows.
- Select Create workflow.
- Enter a Name. Use one that says what the workflow does, such as
Order cancellation - initial contact. The name appears on the Workflows page and in reporting. - Under Eligible channels, select the AI agents this workflow can run on: Chat agent, Email agent, or Voice agent. You can change this later in Manage activation.
- Select Create workflow. The builder opens with the trigger step.
- Set the trigger and add steps.
- Select Save and create workflow.
The workflow now appears on the Workflows page as Inactive. To delete or clone it later, open the menu on its row on the Workflows page.
Set the trigger
The trigger decides which cases the workflow handles. Select the trigger step to open its settings, fill them in, and then select Update step.
| Setting | What it does |
|---|---|
| Workflow title | The workflow’s name. The AI agent also uses it as context when choosing a workflow, so make it descriptive. |
| Case type | Any interaction, Initial interaction (new cases, and the default), or Follow up (replies on ongoing cases). This applies to email agent workflows only. For most email workflows, keep Initial interaction, so the workflow doesn’t run in the middle of a conversation. |
| Case filters (optional) | Rules on Zendesk fields, such as brand, status, or tag. The workflow only runs on cases that meet all of them. |
| Run this workflow whenever all case filters are met, ignoring any selection criteria | Selects the workflow based on the case filters alone. Use it when the filters fully define the workflow’s scope, such as every case tagged billing. |
| Smart field rule | If you see it, matches cases on the values of smart fields. |
| Run this workflow if no other workflow is selected | Makes this the fallback workflow for cases no other workflow matches. |
| Scope | The workflow’s purpose: what it should achieve or resolve for the customer. |
| Trigger conditions | The kinds of cases the workflow should handle, with examples. |
| Types of cases to exclude | If you see it, the kinds of cases the workflow should not handle. |
The selection criteria (Scope, Trigger conditions, and Types of cases to exclude) are instructions in plain language. They can’t be edited while either of the two “run this workflow” options is selected.
Write selection criteria that work
Getting the selection criteria right is one of the most important parts of building a workflow.
- Write it as you would brief a new support team member. Include example phrases, the words customers actually use, and context about your business. Don’t assume the AI agent knows your product names or industry terms.
- Say what to leave out. Exclusions prevent the workflow from picking up cases that belong to a similar workflow, such as a refund request that also mentions “cancel”.
- Ask for explicit intent. If the workflow picks up cases by inferring what the customer might want, add a line such as “Only select this workflow when the customer directly asks about [topic]. Don’t select it if the request isn’t stated.”
- Leave out topics you’re not ready to automate. For example, exclude questions about a newly released feature until your knowledge base covers it, so those cases go to your support team.
- Start from your existing documentation. A standard operating procedure, a help article, or a set of example cases is a good starting point. Some teams paste these into an AI tool to draft the criteria, then edit the result.
If you see Get AI suggestions next to Selection criteria, select it, describe what you’d like to improve (for example, “This workflow is picking up shipping delay questions, but should only handle cancellations”), and select Confirm. You see suggested additions and deletions, which you can review before you save.
Add steps
Important: Publishing replaces the live version. If you publish while a draft exists, the draft is replaced and can’t be recovered.
- Select + after the step where the new one should go, then select Add step.
- Search for or choose a step type. Steps are grouped into Workflow steps and Tools and integrations.
- Optionally, enter a Step name.
- Fill in the step’s settings, then select Update step.
- Select Save as draft or Publish changes to keep your work. Steps aren’t saved until you do.
To stop the workflow after a step, select + and then End workflow. To send a branch to a step that’s already in the workflow, select + and choose the existing step.
| Step | What it does |
|---|---|
| Guide | Gives the AI agent step-by-step instructions in plain language, including lookups, API calls, and replies. See Guide steps in workflows. |
| Analyze case | Reads the case and saves what it finds as variables, such as the customer’s sentiment or an order number. |
| Condition | Splits the workflow into branches based on variable values. |
| Reply | Writes and sends a reply to the customer. |
| Collect information | Asks the customer for details you can’t look up. |
| Handoff | Hands the case to a support team member, based on your handoff settings. |
| Wrap up | Ends the case with a closing message and updates its details. |
| Map lookup | Converts a value using a fixed mapping, such as a country code to a support region. |
| Redirect to workflow | If you see it, ends this workflow and continues in another one. |
| Custom API tool | Looks up or changes data in your own systems through an API endpoint. See Custom API endpoints. |
| MCP tool | Calls a tool from an MCP connector. See MCP connectors. |
| Database query | Runs a saved SQL query against a database connector. See Database connectors. |
| Zendesk update ticket, Zendesk leave internal note, Zendesk data lookup | Update a Zendesk ticket, add a private comment, or read ticket, requester, and organization details. Available when Zendesk is connected. |
| Google sheets CSV lookup | Looks up a row in a Google Sheet. |
| Shopify, Salesforce, and Loop steps | Look up or update records in those platforms. Each appears when that platform is connected. |
| Create case | If you see it, creates a case in your contact platform. |
Condition
A Condition step splits the workflow into branches. Each branch has a Branch name and one or more conditions on variables from earlier steps, combined with “and” or “or”. Branches are checked in order (IF, then ELSE IF), and ELSE catches everything else.
For example: an Analyze case step sets sentiment to positive, neutral, or negative. A Condition step sends negative cases to an empathetic reply and a handoff, and everything else to the standard reply.
Analyze case and lookups
An Analyze case step reads the conversation and saves what it finds as variables. For each variable, enter a Variable name, choose a Variable type (Text, Boolean, or Image), and write a Variable description that says what to look for. You can also choose smart fields under Information to collect.
- Analyze drafted reply analyzes the AI agent’s last drafted reply instead of the conversation. If the step runs before a reply is drafted, the workflow errors.
- Loading message is sent to the customer if the analysis takes longer than 3 seconds. It’s translated into the customer’s language.
- To tell two similar requests apart, a Boolean variable such as
is_influenceris often more reliable than a Text variable.
A Zendesk data lookup step imports ticket, requester, or organization fields, including custom fields and tags, as variables. For example, look up the customer’s organization to personalize a reply or route the case to a specialized team.
A Google sheets CSV lookup step finds a row in a Google Sheet based on a value in the case and imports it as variables, for example to look up pricing or a policy. Share the sheet with cal@assembledhq.com, and set it up as a simple table:
- The first row contains the column headers.
- Every row has the same number of columns.
- There are no merged cells or complex formatting.
Reply and Collect information
A Reply step writes and sends a reply to the customer.
- Compose reply method: Cal generated writes the reply from your Response instructions, and Fixed response sends the text you enter. Instructions can describe the tone, what to include or leave out, and an example reply, and can use variables from earlier steps.
- Do not use brand style settings: turns off your brand’s style guide for this reply.
- Macros to use: select Use Zendesk macros and choose the macros the AI agent can draw on.
- Knowledge sources to use: Dynamically fetched sources, Specific sources, or No sources.
A Collect information step asks the customer for details you can’t look up, such as an order number. Enter Response instructions for how to ask, and choose the smart fields or variables to collect. The AI agent asks for one detail at a time and skips any it already has from earlier in the conversation.
Zendesk actions
A Zendesk update ticket step changes ticket fields without replying to the customer: the status, tags, assignee or group, custom fields, and form. Use it to route cases, set the status after an automated reply, or tag cases for reporting.
A Zendesk leave internal note step adds a private comment for your team, written by the AI agent or fixed. For example, after looking into a billing question that needs a person, the note can summarize what the AI agent found and suggest next steps.
Test a workflow
Test a workflow before you turn it on, and again after every change. A test shows which workflow was selected and why, and what each step did, without replying to anyone.
- In the builder, select Test. To test which of all your workflows a case would select, select Test on the Workflows page instead.
- Choose what to test with:
- Case ID: a previous case. Choose where to Start test from, such as Initial interaction event or Current state of case.
- Chat: a test conversation with your chat agent.
- Email: a test email. Enter a subject and body.
- Voice: a test phone call with your voice agent.
- Outbound call: if you see it, your voice agent calls your phone and runs the workflow.
- If you see Version of this workflow to test, choose Published or Draft. Under Other workflows to test against (or Workflow candidates on the Workflows page), choose the workflows that could compete for the same cases.
- Select Test.
Keep in mind: Steps that change data in other systems, such as a Custom API tool step set to Action (Write), don’t run during a test. To test what happens next, select Simulate API responses and enter values for the step’s output variables.
Read the results
- Workflow selection: which workflow was selected and why, for example “The ticket references GCal, which matches the criteria for the workflow about the Google Calendar integration.”
-
Steps: each step that ran, in order, with its result. Variables from Analyze case steps, such as
sentiment: neutral, and the branch each Condition step followed appear here. - Reply: the reply the AI agent would send, with its rationale.
Before you turn a workflow on, test each of these:
- Cases the workflow should select.
- Cases it shouldn’t select, including cases that belong to similar workflows.
- Edge cases, such as a refund request that also mentions “cancel”.
- Every branch, with at least one case per path.
To test many cases at once and measure accuracy, see Workflow bulk testing. If a step’s rationale and its result disagree, see A step’s result contradicts its rationale.
Save, publish, and clone
Important: Publishing replaces the live version. If you publish while a draft exists, the draft is replaced and can’t be recovered.
- Save and create workflow: saves a new workflow for the first time.
- Save as draft: saves your changes to a draft without changing the live workflow. If you already have a draft, Save and replace existing draft asks you to confirm, because the draft is overwritten.
- Publish changes: makes your changes live. If the workflow is Automated on any channel, Assembled asks you to confirm, because your changes start handling cases immediately.
- Draft: switches to your draft. From there, Save draft saves it, Publish changes makes it live, and Reset draft to published version discards its changes.
- Clone: copies the workflow, so you can try a different approach without changing the original.
Activate the workflow
When testing looks right, select Manage activation and choose how the workflow runs on each channel: Inactive, Agent review (email only, where support team members approve each action in Copilot), or Automated. Most teams start with Agent review or a low autosend percentage and increase it as they gain confidence. For every option and a recommended ramp, see Workflow activation.
Review live results and improve the workflow
Once a workflow is active, check it regularly, especially in the first weeks.
- Monitor tab: resolution, handoff, and error rates for this workflow, and the steps that cause the most handoffs and errors. See Workflows page.
- View cases tab: the cases the workflow ran on, with each step’s results.
- AI quality > QA review: review and score conversations, including a sample of automated cases every week. See Quality review.
Look for three things:
- Selection accuracy: the right cases are selected, and none are missed. Aim for more than 80% before you increase the autosend percentage.
- Reply quality: replies are accurate, on brand, and resolve the issue.
- Handoff rate: a high rate can mean gaps in knowledge or logic, and a very low one can mean cases that need a person aren’t being handed off.
When a case is selected wrongly or missed, add clearer examples to the selection criteria, test again with that case, and publish. To keep the case as a regression check, add it as a test case for bulk testing.
Best practices
- Start simple. Begin with a short workflow and add branches when you see a need for them.
- Build one workflow per job. Separate workflows for separate requests are easier to test and fix than one large workflow.
- Use case filters to narrow scope. Filters keep the selection criteria focused, especially as you add more workflows.
- Name steps and variables clearly. Test results and reports are much easier to read.
- Define variables before you use them. A step can only use variables from steps that run before it.
- Plan for the unexpected. Add a branch for missing data or an API error, and end it with a handoff.
- Keep titles consistent. As your list of workflows grows, a naming pattern such as “Topic - case type” helps everyone find the right one.
For common patterns, such as sentiment-based routing or an order lookup, see Planning workflows for automation.
Troubleshooting
A step’s result contradicts its rationale
In a workflow test, or in a case’s step history, a step’s Rationale can reach one conclusion while the variable it sets says the opposite. For example, the rationale says the two dates match, but dates_match is false. This can happen with any step that both explains its reasoning and returns a value, and it’s most common in steps that compare two values. You can prevent it by changing how the step is built.
When one step is asked to work through some logic in words and also return a structured value, such as a true or false variable, the explanation and the value don’t always agree. The more values a step has to compare, and the more variables it returns, the more likely they are to drift apart. The fixes below apply to any step whose result depends on comparing two specific values, not only dates and duplicates.
Important: If a step’s value drives a decision that affects the customer, such as approving a refund, a credit, or a payout, assume a mismatch can happen on any case, not just the one you found. Use the fixes below instead of relying on one AI step’s true or false value for that decision.
| Cause | How to tell | What to do |
|---|---|---|
| The step compares two exact values | In the step’s test results, the Rationale compares dates, IDs, or amounts, or checks whether a value is already in a list. | Use code for the comparison instead of AI. See Does the step compare two exact values? |
| One step both reasons and decides | Open the step in the builder. The decision variable is set in the same step as a long explanation. | Split the reasoning from the decision. Use one step that works through the question in words, such as a Text variable that summarizes what it found, and a second, simpler step that turns that summary into the true or false value. |
| The step returns a lot at once | Open the step in the builder and check how many variables it sets. With this cause, it sets several variables, or variables with nested values. | Split the step into smaller steps. The fewer values one step returns, the less room there is for any of them to drift from its reasoning. |
Does the step compare two exact values?
For comparisons with one right answer, such as two dates matching, two IDs matching, or a value already in a list, code is more reliable than asking the AI agent to compare.
To check whether this applies:
- Go to AI support > Workflows and open the workflow.
- Select Test, choose Case ID, and enter the case where you saw the mismatch. Or open the case from the View cases tab.
- Find the step in the results and compare its Rationale with the values of the variables it set. With this cause, the rationale compares dates, IDs, or amounts, or checks whether a value is already in a list.
- Open the step in the builder and check whether the decision depends on comparing two specific values.
To fix it, use code for the comparison. In an Analyze case step, you can set a variable with JavaScript instead of AI parsing.
- In the builder, select the Analyze case step that should hold the result, or add one after the steps that set the values to compare.
- Select Add Variable, enter a Variable name such as
dates_match, and set Variable type to Boolean. - Set Analyze method to Code.
- In JavaScript code, write the comparison. Insert the variables from earlier steps from the list as you type. The value of the last line is saved to the variable.
- Select Update step, then test the workflow with the case again.
For example, this checks that two dates have the same YYYY-MM-DD value:
var first = String({{date1}}).trim();
var second = String({{date2}}).trim();
var isDate = /^\d{4}-\d{2}-\d{2}$/;
isDate.test(first) && isDate.test(second) && first === second;
The same pattern works for duplicate checks: compare the two IDs or values, and let the code return true or false.
Keep in mind: Code can be up to 5,000 characters, and it stops if it runs longer than 750 milliseconds. If you don’t see Analyze method, contact our team to turn on code analysis.
It’s fine, and often necessary, to use AI to find or tidy up the values first, such as reading a date from an uploaded image or converting a date to one format. Keep that step’s job to finding the values, and do the comparison in a later step with code. Each step then does the one thing it’s best at.
If a step’s result still contradicts its rationale, chat with our team and include the workflow’s name and the step’s name, the case ID and whether you saw the mismatch in a test or on a live case, a screenshot of the step’s rationale and the variable values, and what you’ve already tried.