Governed workflows / Templates

Compliance workflow templates: gates, evidence and records

Twelve workflows with approval gates, each written as what it can do, cannot do, needs approval for and records.

Ten are the processes organisations ask us about most: procurement, access review, change, vendor, DPIA, incident, KYC, attestation, refund and release. Two are shipped examples of the same pattern from regulated lines of business. We say plainly which exist today.

Build with AI Talk to our team

What exists today, and what is designed

Two of the twelve exist as templates in the platform’s seed data today. Six have a starting point: the human-input step and a related template or Worker exist, and the gates and records are yours to add. Four are designed only. Each card says which. Where two different people matter, you enforce that by how you assign the gates.

How to read the status

Shipped template. A template of this kind exists in Studio or the Marketplace today. Content and availability vary by plan.
Starting point. Studio has the building blocks (approval step, branches, agent and tool nodes) and a related template exists. You assemble the rest.
Designed. No template exists yet. This is the shape we would build, and the shape you can build yourself.

12 templates

Each one lists what it can do, what it cannot do, what needs a person to approve, and what it records.

Procurement approval

Designed

A purchase request is checked against policy, prepared by an agent, approved by the right budget holder and recorded end to end.

No template exists. The nearest shipped one is the contract-review workflow below.

What Procurement approval can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Collect the request and check it for required fields Look up the approved supplier and the contract terms Have the agent prepare a comparison and a draft purchase order Route the request to the approver for its value	Approve or pay anything on its own Raise the approval level to skip a gate Change a purchase order after approval	Purchases above the threshold set by the process owner Contract changes Sensitive external communications A second approver where your policy requires one, assigned by you today	Request and the data the agent read Comparison and draft as presented Each approver, decision and time Purchase order reference Outcome

Access review

Designed

A scheduled review of who has access to what, with a pack for each reviewer and a record of every keep or revoke.

No template exists. Reviewer-differs-from-subject is a rule you enforce when you assign the gates.

What Access review can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Start on a schedule and pull the entitlements export Have the agent flag stale or broad access Send each reviewer their pack and chase overdue ones Open a revocation ticket for each approved removal	Revoke or grant access directly Close the review while reviews are outstanding Let a reviewer review their own access	Each keep or revoke, by the resource owner Exceptions, with a reason Sign-off of the completed review, by the control owner	Export version and time Flags and the reviewer’s decision for each Reminders and escalations Revocation ticket references Sign-off

Change approval

Starting point

A change request is assessed, approved by the right person and linked to the deployment that follows.

Workflows have a human-input step with an assignee, approve and reject branches, and a timeout. Worker templates for code review and DevOps give advisory input.

What Change approval can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Collect the change request and attach test results Have the agent draft the risk assessment Route to the change approver and, for emergencies, to the after-the-fact reviewer Link the approval to the deployment record	Deploy the change Approve its own risk assessment Proceed if required evidence is missing	Normal changes, by the change approver Changes to restricted systems, by the system owner Emergency changes, reviewed afterwards by a named person	Request, evidence and risk assessment Approver, decision and time Deployment reference Rollback, if any

Vendor onboarding

Starting point

A supplier is onboarded only after the file is complete, the risk answers are reviewed and the right people have signed.

A contract-review workflow with named sign-offs exists and is the nearest match. The questionnaire steps and the risk review are yours to add.

What Vendor onboarding can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Send the supplier the questionnaire and collect the reply Have the agent check completeness and summarise the risk answers Route the file to legal, security and the risk owner in turn Create the checklist of what must be in place before first use	Create the vendor in the payment system Share company data with the vendor Skip a reviewer because the previous one approved	Legal review of the terms Security review where data is shared Final approval, by the risk owner	Questionnaire and documents with versions Gaps found and closed Each reviewer, decision and time Systems the vendor was added to

DPIA intake

Designed

A new project describes its data processing, an agent drafts the assessment, and the data protection officer decides.

No template exists.

What DPIA intake can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Collect the project description through a form Have the agent draft assessment sections and list open questions Route to the data protection officer with the draft and the evidence Set a review date	Decide that no assessment is needed Sign off the assessment Contact a supervisory authority	Sign-off, by the data protection officer Acceptance of residual risk, by the accountable owner Any consultation with an authority	Form submission and its version Draft and each edit Reviewer, decision and reason Residual risk accepted, and by whom Review date

Incident response

Starting point

An alert starts a response run: the agent assembles context, people take the actions that change things, and the timeline is the record.

Security analyst and production-support Worker templates, a paging integration and the run ledger exist. The gates and the timeline are yours to assemble. The platform does not file regulator reports.

What Incident response can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Start from an alert or a page Assemble logs and the relevant runbook for the responder Keep a running timeline Notify the on-call person and the incident lead	Take containment actions on its own Notify customers or authorities Alter or delete evidence	Containment, by the incident lead External communications, by the communications owner Notification to a regulator, by the accountable officer Closure and the post-incident actions	Alert and the context assembled Timeline with each action, approval and time Communication drafts and what was sent Closure and review actions

KYC review

Designed

A know-your-customer case is assembled for a qualified reviewer, who decides. Nothing is approved automatically.

No template exists. A KYC onboarding listing on this site is a sample listing, not a shipped template.

What KYC review can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Collect submitted documents Call the screening provider and record the result Have the agent check completeness and draft the case summary Route the case to the reviewer	Approve or reject a customer Dismiss a screening hit Store documents outside the permitted systems	Every decision, by the qualified reviewer Adverse or unclear hits, by the compliance officer	Documents and screening results Summary and its cited evidence Reviewer, decision and reason Escalations and outcomes

Policy attestation

Starting point

A policy round goes to named people, each attests for themselves, and the owner signs off the report.

The certification feature records human attestations against controls. The round, the chasing and the report are yours to assemble.

What Policy attestation can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Send the policy and the attestation request to the named people Track responses and chase overdue ones Compile the report of who has and has not attested	Attest for anyone Edit the policy text during a round Close the round with responses missing	Each person’s own attestation Exemptions, by the policy owner Sign-off of the final report, by the policy owner	Requests, reminders and escalations Each response and who gave it Exemptions and reasons Final report and sign-off

Customer refund approval

Starting point

A refund recommendation is approved by a person for amounts above the threshold, and every refund has a record.

Workflows have a human-input step with approve and reject branches, and a customer-support agent sample exists. The refund policy and the payment hand-off are yours to add.

What Customer refund approval can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Start from a support ticket Have the agent read the order and recommend an outcome Auto-route small refunds under your policy and larger ones to an approver Pass the approved refund to the payments system	Issue a refund above the threshold without an approver Change the threshold during a run Approve a refund its own agent recommended, as the only reviewer	Refunds above the threshold set by the process owner Goodwill exceptions Any reply that admits liability	Ticket and order fields read Recommendation and policy applied Approver, decision and time Payment reference Outcome

Release approval

Starting point

A release goes out only when the gate evidence is in and the release owner has said yes.

A release-manager Worker template exists and is advisory. Our own practice of owner-decided releases is described on the approvals page.

What Release approval can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Collect test results, defect lists and gate evidence Have the agent compile the readiness report Route to the release owner and, for restricted keys, the key holder Link the decision to the release record	Publish, tag or promote a release Waive a failed gate Mark a gate passed without evidence	The release decision, by the release owner Each waived gate, with the reason Signing, by the key holder	Evidence for each gate Report and recommendation Decision, who took it and when Waivers and reasons Release outcome

Contract review with senior sign-off

Shipped template

A contract goes through conflicts clearance, a reviewing lawyer and a senior sign-off, each as a named gate.

A template of this kind, built as a workflow with a human gate at each step, exists in the platform’s seed data. Whether it is listed for your plan: <template availability by plan - founder to fill>.

What Contract review with senior sign-off can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Intake the contract and the parties Hold at a conflicts-clearance gate Route to the reviewing lawyer, then to the senior lawyer Record each decision on the case	Skip a gate Treat an agent review as a lawyer’s sign-off	Conflicts clearance Review by the reviewing lawyer Sign-off by the senior lawyer	Contract and parties Each gate, who decided and when Comments on the case Final outcome

Tiered sign-off for claims

Shipped template

A claim moves through gates by value and risk: a larger reserve needs a more senior person. An example of tiered approval from a regulated line of business.

A template of this kind, built as a workflow with human gates, exists in the platform’s seed data. Whether it is listed for your plan: <template availability by plan - founder to fill>.

What Tiered sign-off for claims can do, cannot do, needs approval for, and records
Can	Cannot	Requires approval	Records
Capture the first notice of a claim Fast-track straightforward cases to a checkpoint Route larger reserves to senior reviewers Record each gate and decision	Pay a claim without the required gate Lower a gate because an earlier one passed	Special-investigation acknowledgement Reserve sign-off, by tier Coverage decision	Claim details Each gate, assignee, decision and time Escalations Final decision

How to read a card

Can lists the steps the workflow runs on its own, including what an agent prepares. Cannot lists what it will not do without a person. Requires approval lists the gates, with who decides. Records lists what each run leaves behind, which is what you hand to a reviewer.

Thresholds are never numbers here. They are set by the process owner: <approval threshold - set by the process owner>. Retention is set by the customer, not by Swfte: <retention period - set by the customer, not by Swfte>. Marketplace availability for each template is <Marketplace listing for this template - founder to fill>.

What a template does not do

A template is a design for controls and records. It does not make a process meet a regulation, it does not file anything with an authority, and it does not replace the judgement of the people who approve. The platform does not enforce that an approver differs from the requester today. Whether a template suits your jurisdiction and risk is for you and your counsel, and none of this is legal advice.

Frequently asked questions

Which of these templates exist today?

Two exist as templates in the platform’s seed data: contract review with senior sign-off, and tiered sign-off for claims. Six have a starting point, and four are designed only. Availability by plan is not published here.

Can I build these myself in Studio?

Yes. Workflows have a human-input step with an assignee, approve and reject branches and a timeout, agent nodes, branching and many integrations. The cards show the shape. The gates, the thresholds and the records are yours to set.

Who owns the approval thresholds?

The process owner. The cards say "above the threshold" and give no number, because the right figure depends on your organisation, your risk appetite and the rules that apply to the process in your jurisdiction.

Do the templates make a process compliant?

No, and we do not claim that. They are designs for gates and records that can support the evidence you need. The exact posture depends on your use case, jurisdiction, deployment and configuration. This is not legal advice.

Where do the same processes appear as agents?

On the governed agent templates page. There each process is written for the agent that prepares the work, with its own Can, Cannot, Requires approval and Records, so you can read the agent and the workflow side by side.

Start from a template, keep the approval in your hands

Start with one entry point. Add intelligence, agents, workflows and infrastructure as you prove value.

Build with AI Talk to our team

What exists today, and what is designed

12 templates

Procurement approval

Access review

Change approval

Vendor onboarding

DPIA intake

Incident response

KYC review

Policy attestation

Customer refund approval

Release approval

Contract review with senior sign-off

Tiered sign-off for claims

How to read a card

What a template does not do

Related pages

Frequently asked questions

Which of these templates exist today?

Can I build these myself in Studio?

Who owns the approval thresholds?

Do the templates make a process compliant?

Where do the same processes appear as agents?

Start from a template, keep the approval in your hands

Ready to build with Swfte?