Building workflows
A workflow is built on its harness: the canvas showing the graph, laid out as Triggers → Steps → Result.
A workflow is inert until you enable it, so everything on this page is safe to experiment with.
Creating a workflow
Click New workflow and give it a name. You get an empty draft. Add a summary from the line under the title — Alma uses it, and so does the next person who opens the workflow.
Triggers
A trigger starts a run. Two kinds:
- Schedule — a cron expression, like
0 9 * * 1for 9am every Monday. - Event — something happened in a connected tool.
Every workflow can also be run manually, at any time, regardless of its triggers.
Add trigger creates an event trigger. To create a scheduled one, add a trigger and switch its type in the editor.
Steps
Each step has a kind:
| Badge | Means |
|---|---|
| Work | Does something |
| Approval | A person decides |
| Wait | Pauses for a condition |
| Branch | The path splits |
And an actor: Alma, a Person, a System, or something External.
Editing a step
| Field | Notes |
|---|---|
| Step name | Required |
| Instructions | What Alma should do at this step |
| Model | Workflow default, or pin to Sonnet 4.6, Opus 4.6, or Haiku 4.5 |
| Require approval after this step | See below |
| Retries on failure | 0–10 |
Pin a model deliberately: use the workflow default for most steps, and reserve Opus for steps that draft customer-facing content.
Approval checkpoints
Turn on Require approval after this step to stop the run there until a person signs off. Choose who:
- Anyone on the team — the first person to look at it can approve
- Specific people — only they can
Write gate instructions telling the reviewer what to check. “Confirm the discount is within guardrail and the usage trend is real” gets a better decision, faster, than “Approve?”
Only people can approve — Alma’s own agent memberships are excluded from the approver list.
Put checkpoints where judgment changes the outcome: anything irreversible, customer-facing, or past a threshold. An approval on a step nobody reviews adds latency without adding safety.
Editing by chat
The rail on the right of the harness edits the canvas by conversation. Describe a change and Alma applies it card by card. Click a card first to give it context.
Access
The Access tab controls two things.
Tool modes
Every tool a step uses gets a row, set to Automatic or Needs approval.
A tool’s mode applies to the whole workflow, not one step. Changing it rewrites the setting on every step that uses the tool. If any step routes the tool through a person, the row reads Needs approval.
New workflows default to Needs approval, unless your workspace changed that default in Security.
Access rules from Connections still apply on top of this. If a rule denies a tool to the people behind this workflow, setting it to Automatic doesn’t override that — the rule wins.
Visibility
A baseline audience, plus rules for specific groups and people, each with Can view, Can edit, or Full access, as Allow or Deny. Resolution: deny wins, and person > group > tier.
Use the Who sees it now card to check the result before relying on it.
Coming soon. The baseline offers Everyone, Admins & up, and Owners only, but Owners only saves the same as Admins & up and reads back that way. Use a deny rule if you need owner-only access.
Changing the baseline is owner-only. Making a workflow visible to the whole workspace requires org admin.
Saving
Triggers and steps save as a whole list — a deleted step is deleted for real on save. Removing a step’s checkpoint cancels any decision pending on it, so a suspended run aborts rather than waiting on a gate that no longer exists.
Result
The rightmost column shows where runs land: Success, Partial, Cancelled, or Escalated.
Coming soon. Results are shown but can’t be edited on the canvas yet. Ask Alma in the chat rail to change them.