Creating Workflows

This guide walks you through creating a workflow from scratch. By the end, you will have a working multi-step process with assigned agents, gates, and a trigger that determines when the workflow runs.

Before you start

Make sure you have:

• At least one agent created in your workspace (workflows assign tasks to agents)

Any member of your organisation can create, edit, publish, and delete workflows — there is no role restriction on workflow authoring.

Create a new workflow

1. Navigate to the Workflows page

   Sign in to team.sprigr.com and click Workflows in the sidebar. This page lists all workflows in your organisation, with a source filter that separates workflows your team built from workflows installed by marketplace apps.

2. Click “Create Workflow”

   Click the Create Workflow button in the top-right corner. This opens the workflow creation form.

3. Enter basic details

   Fill in the following fields:

   • Name — A human-readable name for the workflow, such as “New Employee Onboarding” or “Refund Request”. This is what your team will see in the workflow list. A URL-friendly slug is generated from the name automatically; the slug is what you use when referencing the workflow via the API or agent tools.
   • Description — A brief summary of what the workflow does and when it should be used. This helps team members understand the purpose of the workflow at a glance.
   • Tags — Optional comma-separated tags for grouping and filtering.
   • Project — Optionally assign the workflow to a project so it appears alongside related work.

4. Select a trigger type

   Choose how this workflow will be started:

   • Manual — Team members start the workflow by clicking “Run” on the workflow’s detail page, or an agent starts it from a conversation. When you run it, you can optionally provide a JSON trigger payload that the first step receives as input (for example, the employee name and start date for an onboarding workflow).
   • Event — The workflow starts automatically when a specific event occurs. Set the event source and event type (for example, an order-created event from a connected platform, or an event from an inbound webhook), and optionally add a filter so the workflow only runs for matching events.
   • Schedule — The workflow runs on a recurring cron schedule. Set a cron expression and an optional timezone — for example, 0 9 * * 1 for “Every Monday at 9:00 AM”. Schedules cannot fire more often than every 15 minutes.

   Note

   You can change the trigger type after creating the workflow, but you will need to reconfigure the trigger settings.

5. Add steps

   This is where you define what the workflow actually does. Click Add Step to create your first step, then configure it:

   • Step name — A clear description of what happens in this step, such as “Send welcome email” or “Check inventory levels”.
   • Assigned agent — Select which agent will carry out this step. You can assign a specific agent, or resolve one by tag or role. The agent uses its persona, tools, and integrations to complete the task.
   • Instructions — Tell the agent exactly what to do in this step. Be specific — for example, “Using the Gmail integration, send a welcome email to the new employee at their personal email address. Include the start date, office location, and a link to the employee handbook.”
   • Step type — Choose the type of step. For most workflows, you will use Action steps (the agent performs a task). See Steps & Gates for details on all step types including conditions, forks, joins, pipes, and code steps.
   • Timeout — Optionally set how long the step may run before it times out, in minutes (default 15, maximum 60).

   Repeat this process to add all the steps your workflow needs. Steps run in the order you define them (top to bottom), unless you add fork/join steps for parallel execution.

6. Configure gates for each step

   For each step, set the gate type that controls what happens after the step completes:

   • Auto — The workflow moves to the next step immediately. Use this for steps that do not need human oversight.
   • Review — The workflow pauses and notifies a reviewer, who inspects the agent’s output and approves it to continue (or rejects it with a reason). Use this for quality checks.
   • Approval — The workflow pauses and requires explicit approval. An authorised person must click “Approve” or “Reject”. Use this for decisions with business impact, like approving a refund or publishing content.
   • Decision — The workflow pauses and the approver picks one of several named options. Each option routes the workflow down a different path. Use this when the next step depends on a human choice between several concrete outcomes.

   Approvers can be a specific agent, an agent resolved by tag, a company role, specific users, or the members of a team — whoever acts first resolves the gate.

   Every review, approval, and decision gate has a gate timing setting:

   • After (default) — The step runs first, then the gate reviews the output. Use for triage and after-the-fact quality checks.
   • Before — The gate runs before the step body, so a rejection prevents the step from executing at all. Use this for any step with external side-effects (sending email, charging a card, writing to an integration) so that rejection truly prevents the action.

   See Steps & Gates for full gate behaviour, approval context, and option descriptions.

   Tip

   Start with fewer gates and add more as needed. Too many approval steps can slow down your process. A good rule of thumb is to add approval gates only where the cost of an error is high.

7. Add typed output schemas (optional but recommended)

   For any step whose output feeds a condition, a decision gate, or a downstream step that expects specific fields, declare an output schema so the agent’s output is validated and typed at runtime. This catches silent type-mismatch bugs — for example, a string "true" flowing into a boolean condition.

   See Typed outputs for the full schema syntax and the strict / lenient / off strictness modes.

8. Save the workflow

   Click Save to create the workflow. Sprigr Teams runs validation at save time — missing approvers on gates, dangling transitions, cycles in the DAG, fork/join mismatches, decision gates with fewer than two options, and schedules that fire more often than every 15 minutes are all caught before the workflow can be saved. Validation errors are shown inline; fix them and save again.

   New workflows are created in an enabled state, so they are live as soon as they save. If you want to review the configuration before anything runs, toggle the workflow to Disabled on its detail page and re-enable it when you are ready.

   For manual-trigger workflows, the “Run” button is available while the workflow is enabled. For event and schedule triggers, the workflow starts automatically when the next matching event or scheduled time occurs.

Try asking your agent

“Build a 3-step workflow called ‘Emergency Dispatch’: Step 1 — triage the incoming request and assess urgency. Step 2 — find the nearest available technician. Step 3 — send confirmation to the customer with the technician’s ETA.”

Creating workflows via chat or MCP

You do not have to build workflows by hand. Your companion agent (or any agent with the manage_team tool) can create, validate, and update workflows for you — just describe what you want in plain English. The same surface is available to external tools over MCP via create_workflow and update_workflow.

Both the chat and MCP paths accept the full DAG schema: step id and type (action, condition, fork, join, pipe, code), gateType with rich gateConfig (approvers, justification template, option descriptions, expiry minutes, gate timing), conditions with field/operator/value triples, and explicit transitions. Missing step IDs are auto-generated and simple payloads (for example, a legacy requiresApproval: true) are mapped to the full schema automatically.

Ask an agent to validate_workflow before saving to run the same checks that the editor applies — cycles, dangling transitions, missing approvers, fork/join mismatches, and decision gates with too few options.

Editing an existing workflow

To edit a workflow, click its name on the Workflows page. You can modify the name, description, trigger settings, and steps at any time.

Edits are saved as a draft. Once a workflow has been published, live executions run against the published version, not the draft — your changes only take effect for new executions after you publish them. Executions that are already in progress always continue on the version they started with. See Versions & Publishing for the full draft, test, publish, and rollback flow.

Caution

A workflow that has never been published runs directly from its saved configuration, so edits to it apply to the next execution immediately. Once you publish for the first time, all changes go through the draft-and-publish flow.

Deleting a workflow

To delete a workflow, use the Delete Workflow action on its detail page. You will be asked to confirm.

Caution

Deleting a workflow also deletes its execution history. Past executions, their step outputs, and their approval records are removed along with the workflow and cannot be recovered.

Next steps

• Steps & Gates — Deep dive into all step types (action, condition, fork, join, pipe, code) and gate configurations.
• Workflow Execution — Learn how to monitor running workflows, handle failures, and review execution history.
• Versions & Publishing — Drafts, test runs, publishing, and rollback.
• Inbound Webhooks — Set up webhooks to trigger workflows from external systems.