Workflows and triggers
Workflows organize automation graphs with scheduled and event triggers.
A Workflow is an automation graph with a Trigger, conditions, and actions. Use one when a saved Worksheet view is not enough to decide when work begins or which path it follows. Build and inspect Workflows at /dashboard/automations/workflows, then connect a Workflow to a Sequence only when the graph should control enrollment.
A Workflow is not an automatic send button. It starts as a draft graph, has a saved revision to check, and can be previewed before any execution is enabled. Read Modes for the difference between inspection, preview, and execution, and read Sequences for the separate enrollment and delivery lifecycle.
Create a draft graph
Architect uses the workflows skill to turn an outcome into a draft graph. It searches the workflow pack, gets the current schemas, and selects the capability that matches the requested graph change. The app shows the resulting Workflow in Automations, where you can inspect the trigger, nodes, and revision before continuing.
workflow.automations.create creates the Workflow container. A new Workflow starts with exactly one Trigger node called trigger-root. Unlike a Sequence, a Workflow needs a Trigger subtype and configuration, because the Trigger establishes when the graph can begin.
The capability is not a replacement for discovery. Fetch the create contract for its required inputs, then keep the returned identifiers with the draft. The returned state can include a web_url that opens the exact app object, but its JSON identifier remains the value used in later calls.
Add nodes to the current version
Add one node at a time with workflow.automations.node_add. Each call writes a new draft version and inserts exactly one node, so a caller provides a unique node id and uses the returned draft-version token for the next write. This versioning protects a later edit from silently applying to an earlier graph state.
Workflow node content is nested under data. The node id, type, and position stay at the root of the node shape. Keep those two levels separate when you construct a node, because moving a root field into data can leave the graph structurally incomplete.
Use a Workflow for workspace actions such as creating a Task, requesting manual review, or updating a Record when those actions belong to a graph. The Sequence palette is separate and is intended for delivery journey steps. This distinction keeps a Workflow’s automation decisions visible in the graph and keeps outreach cadence visible in the Sequence builder.
Lint and preview the saved revision
Lint and preview are checks on the saved revision, not execution requests. Run them after creating or changing nodes, and look at their result in the Workflow screen before treating the graph as ready for a later action. Architect can perform these checks as part of its working checklist, while the fetched tool contracts remain the authority for each request.
| Check | Result | Meaning |
|---|---|---|
| Lint | { valid, issues } | A free structural report. Every issue has a path, code, message, and blocking or warning severity. |
| Preview | Saved revision effect summary | A free read of the executable revision. It does not create a run, invoke a node, spend Credits, or send. |
Preview reports the saved revision’s external step count, external write count, pinned connection ids when present, and billing floor fields. It does not create a Run, invoke a node, spend Credits, or send a message. A clean lint is useful evidence, but each later write and publish action validates independently against the current graph.
Connect the graph to the next system
A Workflow can prepare or control work that another system carries out. For example, a Trigger can select the point at which a qualified Row reaches the graph, while a later Sequence action handles the separate enrollment lifecycle. The graph does not erase the Sequence boundary between draft, publication, enrollment, start, and delivery.
Build without waiting for a provider connection when the capability permits a draft. A missing LinkedIn account, mailbox, or other provider can block the later run or send step, but it does not prevent you from designing the graph and checking its structure. Resolve a missing connection in the app before retrying the capability that needs it.
Keep the Workflow revision as the shared reference for collaborators. The graph and its validation result make the proposed behavior visible before a later run exists. This is especially useful when one person designs the Trigger and another person owns the connected delivery system. It also preserves the reason for each later execution decision.
When it goes wrong
Start with lint output, not a guessed correction. The service can report workflow_graph_invalid, workflow_dynamic_branch_invalid, node_contract_unresolved, or node_unavailable when the graph or selected node cannot be accepted. Repair the returned path and rerun lint on the saved revision.
Content and variable failures have their own codes. message_copy_missing identifies missing message content, while template_token_unresolvable and variable_context_unavailable identify values the graph cannot resolve. Read the issue severity and message together, then change the relevant node rather than replacing unrelated parts of the graph.
node_blocker_unmet means a node’s prerequisite has not been met. Check the current node order, Trigger configuration, and referenced system, then fetch the schema again if the contract came from an earlier turn. Use the Run record after live work begins, because lint and preview report the revision rather than a completed execution.