# AI Workflow Automation With Approvals

> AI workflow automation on Elaichi Black. Your own AI writes and test-runs the workflow, a person approves the risky step, and it runs as its owner.

**TL;DR** Elaichi workflows are AI workflow automation on Black: a schedule, webhook, Slack message or one of four other triggers starts the steps. Steps call connected tools, run an agent step and wait for a named person to approve. Claude, ChatGPT, Cursor or any MCP client, or the Elaichi Agent, writes the draft and test-runs it on real data. The test holds back every write and costs nothing; then a version is published, turned on and run as its owner, under the owner's restrictions.

## What does AI workflow automation look like in Elaichi?

Your finance team chases overdue invoices by hand every Monday. AI workflow automation in Elaichi turns that into a workflow, and a named person approves before anything goes out. A trigger starts steps that call your connected apps, and an agent step writes the text. Workflows come with the Black plan.

MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi is one governed MCP endpoint, `https://api.elaichi.ai/mcp`, in front of 650+ connectors. A workflow uses those same connections.

## Can your own AI write and test a workflow before it goes live?

Yes. Claude, ChatGPT, Cursor or any MCP client writes the workflow, checks it and tries it on real data before anyone publishes it. The Elaichi Agent inside the app can do the same.

Over MCP, workflows are built with `elaichi__automation__` operations. An operation `a.b` is the tool `elaichi__a__b`, so `draft__create` is `elaichi__automation__draft__create`. A typical build reads `schema` and `examples`, then calls `draft__create`. It refines with `draft__patch` and checks with `draft__validate`.

The Elaichi Agent, in the console or tagged in Slack, gets the same operations. Validating and test runs need no approval. Changing a draft or running the workflow shows an approval card first, unless the person chose Always allow. Publishing or turning on a workflow asks every time and can never be remembered.

Then the AI calls `dry_run`, which the console calls "Test run (changes nothing)" in the Run now dialog. It runs the latest draft against real data. Reads are real, made as the person who starts the test. Writes to connected tools, collections, state and knowledge are recorded as what would have been sent, and never sent. A notify step sends nothing, and an approve step carries on as approved. The test run costs no run time.

A webhook is a message an app sends to a web address when something happens in it. A webhook trigger in a draft already has its address. It keeps deliveries to it as samples (up to five, for seven days). The AI lists them with `webhook__samples`, and a test run can replay one as the payload. Only after that does someone `publish` and `enable`. No AI client or Agent can answer a workflow approval. None can reveal, rotate or set a webhook secret either.

## How do workflows, collections and dashboards fit together?

Black puts connectors, workflows, AI, collections and dashboards in one place, under one set of rules. Your team uses the AI it already has.

A workflow calls connectors and writes rows to a collection, a shared table. A dashboard reads that collection, or live data from a read-only toolbox tool. A `knowledge.search` step looks up reviewed documents in a knowledge base. Any MCP client at `https://api.elaichi.ai/mcp` builds and reads all of it. So does the Elaichi Agent, which can also create collections and build dashboards.

The Agent and workflow agent steps run on your own keys, one key per provider. The providers are Anthropic, OpenAI, Fireworks AI, OpenRouter or an OpenAI-compatible gateway.

The rules stay the same wherever a call starts. Every connected-tool call Elaichi runs passes one restriction check for the member it acts as. It does not matter which client or automation sent it. A person answers every workflow approval. The bill is seats plus one usage allowance pooled across the workspace.

## What can start an Elaichi workflow?

A workflow starts from up to five triggers, of seven types. No trigger fires on an event inside a connected app. That app sends a webhook instead.

- **manual:** "Run now" in the console, the API or an AI client.
- **cron:** a five-field [cron schedule](https://en.wikipedia.org/wiki/Cron) in an [IANA time zone](https://www.iana.org/time-zones), UTC by default, no more often than every five minutes.
- **schedule_once:** one time, at least a minute ahead.
- **webhook:** a delivery to the workflow's own address.
- **slack:** a message or a reaction in chosen Slack channels.
- **collection_row:** a row inserted, updated or deleted in a collection.
- **automation_run:** another workflow's run succeeding or failing.

If a run is still going, each trigger skips the new one, queues it or cancels the old one.

## How do webhook triggers check each delivery?

Every webhook trigger has its own address, `https://api.elaichi.ai/webhooks/automation/awh_<id>`. It checks each delivery in one of three ways. The default is [Standard Webhooks](https://www.standardwebhooks.com/) signature headers, with a five-minute timestamp tolerance.

Token mode takes a bearer token, a secret sent with each request. HMAC mode has presets for GitHub, Stripe, Slack and Linear, or a custom setup. HMAC is a signature made with a shared secret. A secret is shown once and handled only in the console.

Each endpoint also guards what comes in:

- A delivery is capped at 512 KB, and at 600 a minute per endpoint.
- A repeated delivery is not run again.
- Credential headers are stripped before the workflow sees the payload.

## Which steps does a workflow use?

The steps that do most of the work are `call_tool` for connected tools, `agent`, `approve` and `wait`. Every step can carry a run_if condition, a retry policy, a timeout and an error mode.

`call_tool` runs one connected tool, and can pin one connection. The `agent` step runs a model chosen in the step, or the organization's default from Settings > AI models. Around them sit `foreach`, `branch`, `filter`, `transform`, `notify`, `slack.reply`, the collection and knowledge steps, `code` and `automation.call`, among others.

There is no fetch step. Elaichi does not browse, search or fetch the web for a workflow or the Elaichi Agent, and an agent step has no web fetch tool.

## How do approvals work in a workflow?

An approve step stops the run until a person says yes. The AI never approves its own work: no AI client, Agent or workflow can approve or reject.

The step asks named people or teams, plus the owner unless the step leaves the owner out. It can bar the person who started the run from approving. On the console's Approvals page, the card says "On behalf of Emily Carter, who owns this workflow."

The request also goes to Slack and email. A Slack card carries Approve and Reject buttons only when no destructive step waits behind it. Email carries only a link to the console. A request expires after 72 hours by default. The step then fails with `approval_expired`, unless it is set to continue. A rejection cancels the run unless the step is set to carry on.

Elaichi does not force an approve step before a step that deletes. Validating or publishing warns when a destructive step has no approve step before it, and the builder adds one.

## How would a weekly overdue-invoice chase work?

The workflow reads invoices on a schedule, drafts reminders, waits for a person, then sends. Emily Carter, a finance lead with the Member role, asks Claude to build it.

1. **Trigger.** A cron trigger, `0 9 * * 1` in America/New_York: every Monday at 9:00 AM.
2. **Read.** A `call_tool` step lists open invoices from the [QuickBooks connector](/connectors/quickbooks/).
3. **Filter.** A `filter` step keeps invoices more than 14 days past due.
4. **Draft.** An `agent` step writes a short reminder for each customer.
5. **Approve.** An `approve` step asks Jake Morgan, with Emily included as owner.
6. **Send.** A `foreach` step runs the [Gmail](/connectors/gmail/) tool "Create a message" (`create_a_gmail_message`) once per reminder. A `collection.upsert` step logs each one to an "Invoice chase" collection.
7. **Follow up.** A `wait` step pauses three days. Then a `notify` step posts the invoices still open to [Slack](/connectors/slack/).

Claude validates and test-runs the draft. The QuickBooks read is real, as Emily. The emails, rows and Slack post are recorded, not sent. Emily checks what each send step would have sent, then publishes and selects Turn on. A dashboard on the "Invoice chase" collection shows the team each week's chase. Jake approves on Monday, and the three-day wait costs nothing.

## How does a workflow go from draft to live?

Draft, validate, test run, publish and turn on are separate actions, so nothing goes live by accident. Publishing makes a new numbered version, and is refused while validation finds errors. Turn on is its own button.

Turning a workflow off stops its triggers and lets running runs finish. It keeps the published version and the draft. An earlier version can be made live again from Details > Versions > "Restore this version". That leaves the draft as it is.

## Whose access does a workflow run with?

A workflow's real runs act as its owner, with the owner's connections and access. They are limited to the tools its published version declares. The console says so: "This workflow runs with its owner's access."

The organization's restrictions on the owner apply while the run goes. So a restriction change reaches a run already under way. The owner is re-checked about every minute. If the owner can no longer act, or no longer holds `tool:execute`, the run fails with `owner_invalid` and the workflow is paused. So when Emily leaves and her membership ends, her chase stops instead of running on.

Member holds `automation:publish`. So a member can publish their own workflows that write or start from a webhook or Slack message. Reaching workflows other people own needs `automation:manage`, held only by Org Admin and Org Owner.

## What happens when a step fails or a run runs long?

Elaichi retries what is safe to retry and stops on what is not. A step that writes is never sent twice when its outcome is uncertain.

A step can try up to five attempts in all. A retry after a rate limit waits at least as long as the app's [Retry-After](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After) header asks. A write with an uncertain result ends as `outcome_unknown`, for a person to check in the app. In the invoice chase, a customer never gets the same reminder twice from a retry.

| Limit | Value |
|---|---|
| Steps per workflow | 50, nested at most three levels |
| Approve and agent steps | Five of each |
| Runs at once, per organization | Ten; more wait their turn |
| Queued runs, per workflow | 20 |
| Wall-clock time per run | Two hours, plus declared waits, approvals and agent steps |
| Run history | 30 days after a run finishes |

The Runs tab shows each step's status and error, and an agent step keeps its transcript. A failed or canceled run can run again from the failing step or from the start, on the version it first ran.

## What does a workflow cost on Black?

Black is $24 per user per month, or $18 per user per month billed yearly ($216 a year). Usage past a free monthly allowance costs extra. These are US-dollar list prices; [the pricing page](/pricing/) shows your own. You pay per user, never for the AI apps working for them.

| Meter | Free each month | Past the allowance |
|---|---|---|
| Run time | 1,000 run minutes | $0.02 a run minute |
| Collection storage | 1 GB-month | $5 a GB-month |

The allowance is pooled across the organization and resets on the 1st. Prices past it are in US dollars. The console says: "Only working time counts. Waiting for a person or a timer is free." Test runs cost nothing.

To cap spend, use "Set a run-time limit" on a workflow, or a "Usage budget" in Settings > Billing.

The 14-day free trial is Black itself, with every Black feature on: workflows, collections, dashboards, knowledge bases and the Elaichi Agent. No card is needed to start. Its one limit is the free monthly usage, 1,000 run minutes and 1 GB, which is a hard stop until you buy Black. A trial that ends moves to the free Personal plan and deletes nothing. [Start the Black trial](https://app.elaichi.ai/signup) and build your first workflow.

## When you may not need Elaichi workflows

Skip Black if your team only asks its AI for things in the moment. Gold covers that, with connectors, sharing, restrictions and SSO. It lists at $15 per user per month in USD, or $10 per user per month billed annually.

Workflows fit poorly when the work must react to events in apps that cannot send a webhook. They also fit poorly when the work must read public web pages. A general automation tool may suit that shape better. See [how Elaichi compares with a dedicated automation platform](/blog/elaichi-vs-workato/) first.

For the rest of Black, read [the Black plan overview](/blog/elaichi-black-plan/), the [spend controls guide](/blog/elaichi-spend-controls/) and [what the Elaichi Agent does](/blog/elaichi-agent/). Browse [the connector catalog](/connectors/) for the apps a workflow can call.

## FAQ

### Can Claude or ChatGPT build an Elaichi workflow?

Yes. Over MCP, Claude, ChatGPT, Cursor or any MCP client builds Elaichi workflows with the elaichi__automation__ operations. Examples are elaichi__automation__draft__create, draft__validate, dry_run and publish. The Elaichi Agent inside the app uses the same operation catalog. It asks the person every time before it publishes or turns on a workflow. No AI client or Agent can answer a workflow approval or read a webhook secret. Workflows come with the Black plan.

### Does a test run of an Elaichi workflow change anything?

A test run in Elaichi runs the latest draft against real data. Tools that only read are really called, as the person who starts the test. Tool calls that write are recorded as what would have been sent, and never sent. The same goes for collection writes, state writes and knowledge writes. A notify step sends nothing, and an approve step carries on as approved. A test run costs no run time.

### Who can approve an Elaichi workflow step?

Only a person. An approve step asks named people or teams, plus the workflow's owner unless the step leaves the owner out. Approvers answer on the Approvals page in the Elaichi console or in Slack. No AI client, Elaichi Agent or workflow can approve or reject. A request expires after 72 hours by default.

### Does waiting for an approval cost run minutes on Elaichi Black?

No. Elaichi Black bills only the time a workflow run is working, such as the tool calls it waits on and its agent steps. Waiting is free: for an approval, in a wait step, on a called workflow or at a usage limit. Test runs cost nothing.

### Can an Elaichi workflow start from an event inside a connected app?

Not directly. Elaichi workflows have seven trigger types: manual, cron, schedule_once, webhook, slack, collection_row and automation_run. None is an event inside a connected app. To start from a new deal or a new issue, have that app send a webhook to the workflow's webhook address.

## Read next

- [Elaichi Black: Workflows, Dashboards and the Agent](/blog/elaichi-black-plan/) — Elaichi Black puts connectors, workflows, dashboards and AI in one place, under one set of rules. Your own AI does the building. Here is what it adds and costs.
- [Shared Tables and Live Dashboards for Your AI](/blog/elaichi-collections-and-dashboards/) — Shared tables and live dashboards on Elaichi Black. A workflow writes the rows, your AI reads them, and leadership sees one published dashboard.
- [QuickBooks read-only for a finance team in Claude](/blog/finance-team-claude-quickbooks-read-only/) — QuickBooks has no read-only OAuth scope, so QuickBooks read-only has to be enforced by whatever calls the API. Here is how to do it with one restriction.