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’striggers, 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:
{ "$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.
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 whetherapp_callnodes 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.
Approvals in Slack
Workflows use Slack for two kinds of approval. Both need the Major Slack integration installed for your organization.- A
human_approvalnode 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 arouterthat branches on<node_id>.choice. Only people who are Major members with access to the workflow can answer. - An
agent_callapproval_channelroutes 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.