# Workflow Editor URL: /response-workflows/workflow-editor Type: reference Description: A guided tour of the workflow editor — every setting, what it does, and how to use it. Keywords: workflow editor, settings, configuration, tour The workflow editor is where you build and configure Response Workflows. This page walks through every section of the editor, explains what each setting does, and provides guidance on how to configure it. Opening the editor [#opening-the-editor] From the Stylo dashboard, navigate to **Response Workflows** and either: * Click **New Workflow** to create a new one * Click an existing workflow to edit it The editor opens with the workflow name at the top and two buttons in the header: **Save Draft** and **Publish**. Editor layout [#editor-layout] The editor is organized into five sections: 1. **Essentials** — name, description, enabled toggle, tags 2. **Response Content** — where you write strategy instructions and/or build a template 3. **Activation & Context** — when to use, trigger type, conditions, tools, knowledge bases 4. **Guardrails** — escalation rules and post-response actions 5. **Automation** — background processing mode and response delay Below the main editor is the **Test Panel**, where you can run your workflow against real tickets without leaving the page. Each section is a collapsible card. You can work through them in any order. *** Essentials [#essentials] Basic information about the workflow. | Field | Description | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | A short name that describes the situation this workflow handles (e.g., "Order Refund Request"). Visible to agents when browsing workflows and in Assist suggestions. | | **Description** | Optional longer description. Not shown to customers — this is for your team's reference. | | **Enabled** | Toggle the workflow on or off. Disabled workflows won't appear in Assist suggestions or run in the background, but can still be executed manually. | | **Tags** | Tags for organizing and filtering workflows in the list view. These are workflow tags, not ticket tags. | *** Response Content [#response-content] This is the core of the workflow — where you define what the AI generates. This section has two tabs: **Strategy Instructions** and **Template**. Strategy Instructions tab [#strategy-instructions-tab] A text editor where you write guidelines for how the AI should handle this type of interaction. The AI uses these instructions along with the ticket context, tool data, and knowledge base articles to generate a complete response. Think of strategy instructions as the playbook you'd give a new agent: * What data to check * What decisions to make based on that data * What to include in the response * What tone to use * What to avoid See [Strategy Instructions](/response-workflows/strategy-instructions) for detailed guidance on writing effective instructions. Template tab [#template-tab] A rich text editor where you design the exact structure of the response. You can add: * **Static text** — paragraphs, headings, formatting that appear the same in every response * **Ticket placeholders** — dynamic values like customer name, ticket subject, pulled from the ticket * **Tool placeholders** — values from connected tools like Shopify order number, tracking info * **AI blocks** — sections where the AI generates text based on a prompt you provide Use the `{{` shortcut to open the placeholder menu, which shows all available placeholders grouped by source. Using one or both tabs [#using-one-or-both-tabs] You can use either tab on its own, or both together: | You fill in... | What happens | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Strategy Instructions only** | The AI generates the entire response from your instructions — no fixed structure, the AI adapts to each situation | | **Template only** | The AI fills in the placeholders within your structured template — the overall shape of the response is always the same | | **Both** | Your template controls the structure, and the AI blocks within it use your strategy instructions as additional context to generate smarter content | Most teams start with strategy instructions (it's faster to write and more flexible), then add a template later if they need more control over formatting. See [Response Modes](/response-workflows/response-modes) for a deeper comparison. *** Activation & Context [#activation--context] This section controls when the workflow runs and what information it has access to. When to Use [#when-to-use] A natural language description of the situations this workflow handles. This text is evaluated by AI when: * Ranking Assist suggestions for agents * Deciding which workflow to execute in background automation * Classifying incoming tickets Write it as if you're explaining to a colleague when to use this workflow: > "Use when a customer is asking about the status of an order they've already placed, including questions about shipping, tracking, or delivery timeline. Don't use for pre-purchase questions about shipping policies." Be specific about what the workflow handles AND what it doesn't handle. Trigger Type [#trigger-type] For background automation, this controls which ticket events trigger the workflow: | Option | Fires when | | ----------------------- | ----------------------------------------------------------------------- | | **Customer reply** | A customer posts a public message on the ticket | | **Agent internal note** | An agent posts an internal note (useful for agent-initiated automation) | This setting only matters for workflows that run automatically in the background. A workflow an agent runs manually doesn't use a trigger. Conditions [#conditions] Optional rules that the ticket must match for this workflow to run. Unlike the "When to Use" description (which is evaluated by AI), conditions are evaluated deterministically — they either match or they don't. Available condition types: * **All of** — every condition must match * **Any of** — at least one condition must match * **None of** — no condition can match Each condition checks a ticket field (subject, status, priority, tags, custom fields) against a value using operators like equals, contains, starts with, etc. **Example:** A "Refund Request" workflow might have: * All of: status equals "open" * Any of: tags contain "refund" OR tags contain "return" * None of: tags contain "escalated" Tools [#tools] Select which integrations the workflow should pull data from before generating a response. The available tools depend on which integrations you've connected in your Stylo settings. When a tool is enabled, the workflow automatically fetches the relevant data (e.g., order details from Shopify) and makes it available to both the AI and your escalation rules. Knowledge Bases [#knowledge-bases] Select which knowledge bases the AI should search when generating responses. The AI will find relevant articles and use them to ground its response in your actual documentation. * **Select specific knowledge bases** to scope the search to relevant content (e.g., only search the returns policy KB for a refund workflow) * **Leave empty** to search all available knowledge bases for your organization *** Guardrails [#guardrails] Escalation Rules [#escalation-rules] Define conditions where the workflow should **not** generate a response and instead leave the ticket for a human agent. Each rule checks a field from your connected tool data against a condition. The field picker shows all available fields based on which tools you've enabled — for example, if you've connected Shopify, you'll see fields like order total, fulfillment status, and financial status. | Setting | What it means | | ------------- | ----------------------------------------------------------------------------------------------- | | **Field** | Pick from the available fields for your connected tools (e.g., order total, fulfillment status) | | **Condition** | How to evaluate it (equals, greater than, is missing, etc.) | | **Value** | The value to compare against | | **Reason** | Why this should escalate — logged for your team's visibility | Rules are evaluated after tool data is fetched but before the AI generates anything. If any rule matches, the workflow stops immediately. See [Escalation Rules](/response-workflows/escalation-rules) for common patterns and best practices. Post-Response Actions [#post-response-actions] What happens after a response is sent. These apply to all execution modes (manual, cache, background). | Action | Description | | -------------------- | ------------------------------------------------------ | | **Set status** | Change the ticket status (open, pending, hold, solved) | | **Add tags** | Add tags to the ticket for routing and reporting | | **Remove tags** | Remove tags from the ticket | | **Set priority** | Change the ticket priority | | **Set custom field** | Set a custom field value on the ticket | Actions are applied after the response is posted. If the workflow escalates (an escalation rule matches), no actions are applied. *** Automation [#automation] Controls how the workflow runs in the background. See [Background Automation](/response-workflows/background-automation) for the full guide. Background Processing Mode [#background-processing-mode] | Mode | Behavior | | ----------------- | --------------------------------------------------------------------------------------------------- | | **Disabled** | Manual only — agents must select and execute the workflow | | **Cache** | Runs in background, pre-generates a response for agent review in the sidebar (an Assist suggestion) | | **Internal note** | Runs and auto-posts as an internal note (not visible to customer) | | **Public reply** | Runs, quality-checks, and sends directly to the customer | Response Delay [#response-delay] For internal and public modes, how many seconds to wait after generating the response before sending it. This gives agents a window to respond first — if they do, the automated response is discarded. Recommended settings: * **Public reply:** 30-60 seconds minimum * **Internal note:** 0 seconds (internal notes don't compete with agent responses) *** Saving and publishing [#saving-and-publishing] The editor header has two buttons: * **Save Draft** — saves your changes without making them live. Use this while you're still iterating. Your draft is preserved even if you navigate away. * **Publish** — saves your changes AND creates an immutable published snapshot. The new version goes live immediately — Assist suggestions and background automation will use it. **When to use each:** * Use **Save Draft** while you're building and testing. This lets you iterate without affecting the live version. * Use **Publish** when you're confident in your changes and ready to go live. Published versions are immutable snapshots. If you make a mistake, just edit and publish again — the new version replaces the old one. Previous versions are preserved in the execution history for audit purposes. *** Test Panel [#test-panel] The test panel sits below the main editor sections. It lets you run your workflow against real tickets without leaving the page — the fastest way to iterate on your instructions or template. How to test [#how-to-test] 1. Enter a **Zendesk ticket ID** in the test panel 2. Click **Run Test** 3. Stylo fetches the ticket's full context from Zendesk (customer info, conversation history, channel) and runs your workflow against it — using your current unsaved editor state, not the published version 4. The panel shows the result: **If the workflow generates a response:** * **Generated Response** — the full text the AI produced, displayed exactly as it would appear to the customer * **Tool Data** — a collapsible section for each connected tool showing the data that was fetched (e.g., order number, fulfillment status, total price). Expand to see the full data the AI had access to. * **Metadata** — execution time, which AI model was used, token usage (input/output), and which response mode ran (template, guided, or hybrid) * **Unresolved Placeholders** — if any template placeholders couldn't be resolved, they're flagged here **If an escalation rule fires:** * The panel shows an escalation alert with the rule that triggered and the reason — no response is generated, just as it would work in production You don't need to save before testing [#you-dont-need-to-save-before-testing] The test panel runs against whatever is currently in the editor — your unsaved strategy instructions, template changes, escalation rules, and tool selections. This means you can: 1. Change a line in your strategy instructions 2. Hit **Run Test** on the same ticket 3. Instantly see how the output changed No saving, no publishing, no leaving the page. Testing tips [#testing-tips] * **Test with different ticket types.** Run 3-5 tickets that represent different scenarios your workflow should handle. Does the AI adapt correctly? * **Test edge cases.** Try a ticket where the customer has no order, or where the order is in an unusual state. Does the workflow escalate when it should? * **Compare before and after.** When you change your instructions, re-run the same ticket ID to see how the output changed. This is the fastest way to refine your strategy instructions. * **Check the tool data.** If the response is wrong, expand the tool data section to see what the AI was working with. The issue might be missing data, not bad instructions. Moving to production [#moving-to-production] Once you're confident in the test results: 1. **Publish** your workflow to make it live 2. Enable **Cache** mode to start generating Assist suggestions — agents review before sending 3. Monitor how agents interact with the suggestions — do they use them as-is, edit them, or dismiss them? 4. When ready, move to **Public reply** mode for full automation Related [#related] * [Creating a Workflow](/response-workflows/creating-a-workflow) * [Conditions](/response-workflows/conditions) * [Actions](/response-workflows/actions)