Skip to main content
WORK INWorkflow Studio
BRING

Brand access · Gorgias connection · A reviewer

FINISH WITH

A ticket, its draft, and verified dry-run evidence

Outcome: inspect a draft generated for a real helpdesk ticket before allowing the workflow to send replies. This walkthrough uses Response’s setup UI and the Temporal Engine behind it. Have your organization ready, permission to configure its workflow brand, and Gorgias access. Connect Shopify too when the workflow needs store policies or commerce context. If you are still waiting for those credentials, complete your first agent.

​
Before you begin

Finish line: one inspected replay with its ticket ID, run ID, draft, and dry-run evidence. The accelerator can change configuration and provider setup; review step 2 before starting it. Record the job ID while it runs so a teammate or assistant can resume inspection without starting another attempt. Use the onboarding record.

​
1. Select the brand and connect systems

Open Setup and Connect systems, or use Workflow Studio for an existing brand. Select the intended brand and connect the providers through the app’s connection flow. Keep the returned workflow brand UUID. Do not substitute the organization ID, store domain, or brand slug for it in tools that require brand_id.
Success: the intended providers appear connected and readiness checks identify no unresolved credential or configuration blockers. A saved credential alone is not proof of a healthy connection.

​
2. Draft and run a trial

In Automate your queue, choose Draft & run trial under Draft it from your helpdesk and run a trial. The accelerator can discover provider IDs, harvest macros/replies/policies, draft and apply configuration for an inactive brand, register webhooks, activate an eligible shadow brand, and queue ticket replays. Inspect each step’s report. ok, skipped, and failed mean different things: a finished job can still contain failed or skipped steps. The process may take several minutes.
The accelerator does not change routing mode. A newly bootstrapped brand starts in shadow; check the actual mode on an existing brand. The accelerator skips its activation step for live/canary brands, and it does not rewrite an already active brand’s configuration.
If you operate through MCP instead of the UI, use the accelerator task with the same brand. Do not launch both paths concurrently for the same onboarding attempt.

​
3. Read the first result

Inspect the workflow’s runs in Workflow Studio. Through MCP, use get_trial_report, list_brand_workflows, and get_workflow_run as exposed by your connection. For one replayed ticket, record:
  • The original ticket and workflow run IDs.
  • The draft response and the policies/context that support it.
  • Any skip, escalation, failure, or review decision.
  • Evidence that it was a replay/dry run rather than a customer dispatch.
Backfill runs carry dry_run: true, regardless of routing mode. They bypass the human-review waiting step and send nothing. A successful replay can finish as dry_run_completed; seeing no approval item for it is therefore expected.
First value: a reviewer can compare an actual ticket with the draft the workflow would have produced and decide what needs improving. “Brand active” or “job queued” alone is not this result.

​
4. Improve one behavior

Choose a specific gap: missing policy, wrong classification, unnecessary escalation, or an unhelpful draft. Review the relevant source/configuration and test the change against that case. Retain human-corrected cases as your evaluation set. For MCP configuration edits, propose and validate first. Apply against the current config version with a change note. Unattended configuration changes must use the engine’s require_golden_pass: true gate; a missing or failing evaluation is a reason to stop, not lower the threshold. See Workstream MCP.

​
5. Move to reviewed live traffic

Decide who approves the initial replies and verify the review gate remains enabled. After reviewing the trial and readiness, an authorized operator can change routing to canary or live. Through MCP this is set_brand_routing_mode, a separate consequential operation. Observe a real incoming event, inspect the draft, follow its approval, and verify dispatch. Only then count a first live outcome. Keep the review gate until your team has evidence for changing it. Returning routing to shadow changes future handling; it does not unsend replies.

​
See where onboarding is stuck

Use get_onboarding_funnel for the brand’s next_step and observed timings. The engine tracks setup milestones separately from real traffic milestones: first_event_received, first_draft, and first_reply_sent come from actual runs.

​
Save your progress

Before leaving, update your onboarding record with the identifiers, observed result, remaining blocker, and next action. If you switch to an AI assistant, use the resume prompt to verify current state before continuing.

​
Next steps

Improve one behavior

Propose, evaluate, apply, and verify a versioned configuration change.

Review your first week

Plan reviewed live outcomes and measure what improves.
Related: Troubleshoot onboarding · Manage agents and workflows with MCP · Durable workflow API walkthrough · From signup to first value.
Last modified on September 20, 2026