Speed to lead
Build a workflow that connects worksheet, sequence, and trigger work.
Use this month-one play when new worksheet rows need a timely, repeatable next action. It turns a real row source into a small workflow that evaluates new rows and can enroll qualified ones, while keeping authoring, validation, publishing, activation, and delivery as separate facts. Start with Workbooks and worksheets for the trigger data and read Workflows and triggers for the execution model.
The workflows skill is for automation that is not an outreach cadence to people. It teaches Architect to find an existing workflow first, build the smallest graph that meets the stated outcome, and validate after every change. A workflow can be built and checked before an email, Slack, or other connection exists, because a missing connection blocks activation rather than authoring.
Needs and produces
You need a trigger source, usually a worksheet whose rows represent the subjects of the automation, plus a clear answer to what should happen, what it may change, how often it should run, and when it stops. Before building, Architect frames those facts and searches existing workflows and sequences by the named purpose. If a matching automation exists, change that match instead of creating a duplicate.
The result is a saved workflow graph with its requested trigger, nodes, explicit branch outcomes, and validation result. When the graph is ready, publishing stores the version that will run and activation turns its trigger on. The play produces a workflow that can score new rows and enroll qualified rows, but it does not treat a draft or a successful validation as evidence that any row has been delivered to a destination.
A worksheet trigger remains valid when the worksheet is empty or still filling. Rows can enroll as they land after an active trigger is in place. This lets you check the workflow now while accurately reporting that it is waiting for rows, rather than treating an empty source as an error.
Frame the job and inspect the workspace
In the Workflows screen, look for an existing automation with the requested name and inspect its current graph before editing. The skill tells Architect to search workflows and sequences first, because a named object might already be an automation. Only when both searches return empty should it consider whether the named thing is a task, record, or worksheet instead.
State the trigger, subjects, effects, cost, exits, and recurrence in plain language. Use a template when one fits the goal, otherwise use the smallest graph that produces the outcome. A request to enroll rows is not missing information: use the workflow whose table trigger is the visible worksheet, or build a draft for that worksheet with appropriate steps and a follow-up task per person by default.
Every node must use its real settings and actual workspace options. Before writing a node, Architect reads the node type settings and relevant choice fields such as channel, worksheet, and account. A value that changes on each run belongs in a runtime input. When a trigger, record, or earlier node should supply that value, Architect lists the graph variables and uses only a listed token instead of inventing variable syntax or saving an empty value.
Build and validate the graph
Build the entire graph in one pass when every node is known. When the design needs exploration, add one node at a time and read the saved result before adding the next. For an existing workflow, change only the named node or setting and leave the rest of the graph untouched. Removing a node means removing that node, not recreating a graph that risks dropping an unrelated branch.
Conditions should point at real worksheet columns, and every branch needs an explicit result, including the case where a value is missing. This avoids dead ends and orphan nodes. The requested graph should visibly distinguish a qualified row from a row that lacks evidence, so the workflow does not convert uncertainty into a silent enrollment decision.
Validation happens after each change. A workflow is ready only when validation is clean and the saved graph contains every requested node and path. In the Workflows screen, compare the saved graph with the original outcome statement, then inspect the validation messages rather than assuming a successful save proves the graph can run.
- 1
Resolve the existing system
Architect uses theworkflowsskill to search existing workflows and sequences. In Workflows, confirm whether the request is an edit to a live system or a new draft tied to the selected worksheet. - 2
Read triggers, settings, and variables
Architect reads the worksheet trigger, node schemas, workspace options, and graph variables before writing. Check that every condition names an actual worksheet column and that changing values are runtime inputs. - 3
Save the smallest complete graph
Architect adds the requested nodes and explicit branch outcomes. In the graph view, check qualified, unqualified, and missing-value paths instead of accepting a graph with an unconnected branch. - 4
Validate and repair
The workflow skill validates after every change and fixes each real error before validating again. Check the returned validation result and the saved graph together before calling the draft ready. - 5
Preview lifecycle state
Architect previews activation and reads the required maximum-credit ceiling from that preview. Check whether the workflow is draft, published, active, running, or finished, because those labels describe different states.
Publish, activate, and observe
The lifecycle is ordered: build or edit the draft, validate it, fix errors, publish, then activate. Publishing stores the version that will run. Activation turns the trigger on. Enrollment and delivery happen later and need their own result reads. Do not report an active trigger as a completed action on a particular row.
A missing email, Slack, or other connection does not stop you from building, saving, or validating. It does block activation, so name the exact connection still required and leave the checked draft available. An active worksheet trigger snapshots its saved view on periodic ticks and idempotently enrolls rows that land later. A draft, paused, or inactive workflow does not refill from later rows.
Use the activation preview before a live activation. The workflow skill specifies that the activation call needs the params.max_credits value shown by the preview's required_caps.max_credits. Send that value unchanged. It is a ceiling supplied to the call, not a substitute for reading the preview, and it must never be guessed. Live enrollment has no send cap in this workflow lifecycle guidance: every eligible selected row is enrolled.
Credits and leading metric
The play's leading metric is qualified rows enrolled within minutes. Measure it from a completed run or observed enrollment result, not from the number of nodes in the graph. Reads and validation establish the design; preview establishes the activation scope and required ceiling; live effects establish themselves only through the resulting run and destination state.
Show the cost scope before a priced live action and keep any repair narrow. The activation ceiling comes from the current preview. If the workflow is waiting for rows, record that state rather than spending on a fabricated test subject. If a real row later enters the workflow, follow its run to terminal state and check the expected path in the graph and the destination it reached.
When it goes wrong
If validation reports an error, read the real setting or variable that caused it, correct that bounded node, and validate again. Do not invent a node id, field name, or variable token to silence a validation failure. If a condition references a missing column, either use the real available column or report that the required data is absent. A clean saved graph is required before the workflow is called ready.
If activation is blocked by a missing connection, keep the validated draft and report the exact connection to add. Do not rebuild the workflow or claim an empty worksheet is the blocker. If the worksheet is empty, an active valid trigger waits for new rows. If an activation result is unclear, read current state before retrying so a trigger or enrollment is not applied twice.
For a failed run, start from the run history and then inspect the trace for the specific node's state, attempt, output, receipt, and error. Retry a failed node only when the effect did not occur. A succeeded node with a receipt must not run again. A timeout, lost connection, or missing receipt is an unknown outcome: check the outside system or trace before retrying. Continue a paused or checkpointed run from its checkpoint instead of restarting it. Use Find out why something failed for that evidence path.
Next play
Use Weekly review after the workflow has real activity, so you can compare runs, qualification, sequence analytics where relevant, and credits from finished work. If the worksheet used by the trigger has unclear source evidence or a broken score, use Clean up a worksheet before adding more workflow paths.