Document workflow automation
By Ai Flowi · Published .
Document workflow automation moves a supplied document through intake, validation, review and a controlled output step. Define each state, its responsible reviewer and the evidence needed for a transition before connecting extraction or document-writing components. This design uses a supplied queue and an explicit transition record rather than assuming a native approval service.
example configuration, not a recorded test. The proposed document lifecycle is documented in the catalogue; not production-tested by Ai Flowi.
1. Define the intake record and rerun key
Prepare a document queue with a stable record identifier, source identifier, source version, requested task and assigned reviewer. Record intake separately from acceptance. Readability alone supplies neither required-field evidence nor review acceptance.
Choose the business meaning of the rerun key before writing a row. If the key represents one source version and one processing request, a changed version needs a new key. A retry of the same request should retain its key. Have the intake process supply these identifiers; generated interpretations of document text cannot define which request a retry belongs to.
In AI Flowi Workflow, connect your model-provider account and required API key through model access (provider usage billed separately) and your Google account through Google authorisation; grant access to the queue spreadsheet and working document, obtain source permissions and appoint the transition reviewer.
Related: HR workflow: stages, owners and safe AI assistance.
2. Specify states as business controls
| State | Evidence required | Permitted next step |
|---|---|---|
| Received | Known record key, source version and assigned reviewer. | Read a permitted source. |
| Needs correction | Missing input or unreadable material recorded explicitly. | Request a corrected source through your existing process. |
| Ready for review | Required fields present and draft evidence inspectable. | Reviewer compares output with the source. |
| Accepted or rejected | A recorded human decision tied to the inspected version. | Only accepted text enters output preparation. |
| Output checked | The actual destination content has been inspected. | Close the request with its destination reference. |
These labels are a proposed ledger design, not product-provided approval states. Assign transition authority and identify the record that will hold each review decision. The minimum initial arrangement can be a reviewer-controlled queue with manual transitions; do not represent an extracted status field as authorisation to write a final document.
3. Read and extract without silently accepting
Use the Read File selection guide for intake loading, then tie the resulting text to the queue’s specific source-version record.
A corrected upload should return the request to intake checking rather than inheriting acceptance from the previous version. Keep the prior decision attached to the version it inspected. If a reviewer is reassigned while extraction is running, record the reassignment and make the pending draft available to that reviewer; do not treat the earlier assignment as proof that review occurred.
Give Structured Output a system_prompt that requests business-field extraction with source locators and reserves transition authority for the reviewer. A source can contain words such as “approved” without establishing that the current request was reviewed. Keep that wording as source evidence and let the supplied transition record determine the request’s state.
Implement extraction using the Structured Output interface, while evaluating required-field evidence independently of the model’s proposed completeness status.
Related: Table extraction: preserve headers, cells and source evidence before reuse.
4. Apply the required-field and reviewer gate
Compare extracted fields with the request’s required-field list. Check identity, source version and evidence for each value. Put missing or conflicting fields in needs-correction status, with a reason that the reviewer can act on. A populated field still fails the gate if it cannot be found in the source.
Bind acceptance to the request key, inspected source version and exact accepted content. If any of those change, return to review and retain the previous decision as history. A rejection needs a corrective reason, such as an unsupported value or missing attachment, so intake staff can supply a meaningful revision. Keep “needs correction” distinct from “rejected”: the former waits for evidence, while the latter records a decision on the reviewed request.
5. Update a keyed state record deliberately
Assign the stable request key to key_column; choose "RAW" in value_input_option using the Upsert Row reference.
Prepare row_data with the current state, source version, latest reviewed decision and destination reference when available. Save the transition separately before overwriting the row’s current state. If the sheet already contains two rows with the request key, resolve that ambiguity before updating either; a successful write to one row cannot make the other disappear from staff review.
The v2 Sheets test table records 12 PASS scenario groups and 1 UNMET group in each original/imported run. T7 remains unmet: both runs returned a raw 404 error instead of the intended controlled 502 response, without changing rows. Its duplicate protection covers sequential deliveries only; concurrent arrivals can create duplicate rows, so this result cannot validate simultaneous updates to a document ledger. Upsert also updates only the first matching row, so inspect existing duplicate keys before trusting state changes. A keyed current-state row is not an immutable transition history.
Related: RFP automation: prepare an evidence-backed response matrix.
6. Write accepted content and inspect the destination
Use Template Merge’s documented handoff for the accepted content, recording output-checked status only after inspecting the actual destination.
The separate validated-form recipe’s 42/42 check includes documented CR+LF conversion and Create Document, while this lifecycle’s state transitions and Template Merge handoff still require their own validation.
7. How do I test interrupted transitions and limit the scope?
Check a missing source, an unsupported extracted value, a rejected draft, a repeated request and a destination failure after the state write. The queue must preserve where work stopped. Inspect both destinations before retrying an uncertain operation; do not label a request complete solely because its ledger row changed.
Work through an illustrative interrupted request: its review is accepted, the state row is saved, and the document operation loses its connection. Leave the request accepted with output unresolved. Inspect the destination for the expected content before repeating the document operation. If it exists intact, record its reference and close the handoff; if it is absent or incomplete, record what failed and resume only that operation. Re-extracting the source at this point could produce different wording and invalidate the earlier acceptance.
Now reverse the interruption: the document is correct but the closing state write fails. Preserve the verified destination reference in the transition record and retry the ledger update after checking its current row. A lifecycle recovery check passes only when staff can distinguish these two cases without using a guessed “complete” label.
This design provides no inbox intake, unattended approval, automatic deletion or atomic transaction across Sheets and Docs. Stop when approval is unavailable or when the record cannot identify the source version. Use source auditing for version conflicts and procedure drafting for writing the document’s content.
Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.
Check the catalogue contracts and recorded use cases before implementing further transitions. Each ledger decision must point to the version and content that the reviewer actually inspected.