Skip to main content
A workflow is a graph of steps that Major runs for you. Each step is a node: run an agent with a prompt, call one of your deployed apps, branch on a value, loop over a list, wait, or ask a person to approve in Slack. A workflow starts when you click Run now, or on its own from a trigger: a schedule, a connector event, or a webhook call. Use a workflow when the work has a fixed shape - the same steps, in the same order, every time - and you want each step’s input and output recorded. Use a single agent when the work is open-ended and the agent should decide the steps.

Example requests

Describe the workflow to the Platform Agent or any client connected through MCP:
  • “Every weekday at 9am, pull yesterday’s signups from the CRM app and have the lead-scoring agent score each one.”
  • “When a Stripe payment over $1,000 fails, have the billing agent draft a note to the customer and ask #finance to approve it before it’s sent.”
  • “When someone posts in #support, have the triage agent classify the message and open a ticket through the helpdesk app.”
  • “Give me a webhook our backend can call with an order id to start a refund review.”

How workflows are defined

A workflow is a single JSONC file (JSON with comments). It lists the workflow’s triggers, its nodes, the edges between them, and the entry node where a run starts. The format is published as a JSON Schema at https://api.prod.major.build/public/workflow.schema.json, which also lists the graph rules every definition must pass. This workflow starts from a webhook, has an agent assess a refund request, asks a person in Slack, and issues the refund only if they approve:
Each node’s output is stored under its id, so later nodes can read it: { "$state": "lookup_order.total" } looks up a value, { "$expr": "..." } computes one with a CEL expression, and "{{assess.reason}}" interpolates one into a string. The workflow’s own input is under trigger.input. See State and input.

What workflows can do

A workflow can have up to 50 nodes. See Nodes for every field and the graph rules.

Building a workflow

Ask the Platform Agent in the web app, or any AI client connected through MCP. It looks up the agents and apps to use, drafts the definition, and runs it to test. The Workflows page in the web app shows the graph as it’s built, and you can also add nodes and triggers there directly. To edit the file yourself, use the CLI. Like agents and skills, workflows have two separate steps:
  • Save writes the definition as a new immutable version. Saving validates the file first; if it fails, nothing is saved and you get the list of errors. Saving never changes what runs automatically.
  • Publish makes the latest saved version live. This is the only step that turns triggers on: schedules start firing, connector event subscriptions are set up, and webhook URLs start accepting calls. Publish an earlier version to roll back.
Triggers in a saved but unpublished version do nothing. After you add or change a trigger, publish before you expect it to fire.

Running a workflow

  • Run now runs the latest saved version immediately, so you can test without publishing. If the workflow has an input_schema, you’re asked for the input first. When the workflow calls apps, choose whether app_call nodes hit the deployed apps or your live app sandboxes (Run with app drafts).
  • Triggers run the published version on their own and always call deployed apps. See Triggers.
You can also run a single node on its own to test it, with stand-in outputs for the nodes before it. Every run is recorded in the workflow’s run history with a per-node trace: status, resolved input, output, and any error. Runs execute as the person who last published the workflow (or its creator, before the first publish), so agents and apps use that person’s access.

Approvals in Slack

Workflows use Slack for two kinds of approval. Both need the Major Slack integration installed for your organization.
  • A human_approval node is a step in the graph. It posts its message to a channel with one button per option, can send reminders, and waits for a click or its timeout. Point its single outgoing edge at a router that branches on <node_id>.choice. Only people who are Major members with access to the workflow can answer.
  • An agent_call approval_channel routes that agent’s tool approval requests to a Slack channel. Without one, approvals stay in the app. Use it when an agent has tools set to Ask and no one is watching the run.

Sharing and access

Workflows have their own roles: User can view and run the workflow and answer its approvals, Editor can also edit and publish, and Admin can also share and delete.

Next steps

Nodes

Every node type, its fields, and the graph rules.

State and input

Pass data between nodes and define workflow input.

Triggers

Start a workflow from a schedule, a connector event, or a webhook.

CLI

Create and edit workflow files locally.