Loading

Workflow Templates

Twelve ready-made workflows, from record approval to month-end close: how to start from one and what each template does and asks for.

Starting from a Template

The Workflow Builder ships twelve ready-made workflows. You choose one, tell it which datastores, fields, statuses and people to use, and it creates a draft workflow for you to check, simulate and publish. Nothing runs until you publish it, and the template itself never changes: the new workflow is yours to edit.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — New from template… at the top of the library (Start from a template when there are no workflows yet)

Choosing a template

  1. Press New from template…. The gallery opens.
  2. Narrow it with Search (approval, dunning, reorder…) or Area: Finance, General, Integration, Inventory, Payables, Projects, Purchasing, Receivables or Sales.
  3. Read the cards. Each shows the template's name, its area (with "ERP" for the ERP ones), how it starts, how many steps it has, a one-line summary, the kinds of step it uses, and any sub-workflow it also creates.
  4. Click the template's name. Its form opens with a description of what it does.

Answering the settings

  1. Enter Name of the new workflow.
  2. Answer each question under Settings. Required ones are starred. They come in a few kinds:
    • Datastores: chosen from a list. ERP templates pre-select the ERP's own datastores where they exist.
    • Fields: offered from the datastore chosen above them, and refreshed when it changes.
    • Statuses of an ERP document: offered from that document type's own statuses and spelled as it declares them.
    • Records such as a company or supplier: answered by its code.
    • Approvers and people to tell: an e-mail address, group:id or name, team:key, or a list. Defaults such as group:Finance assume a group with that name exists.
    • Numbers (thresholds, days, minutes), an e-mail account, a business calendar, verification and signature types.
    • Text, which may include placeholders such as {{buyer}}, filled from the record when the workflow runs.
  3. Press Create the draft.

Answers are checked before anything is created: a datastore must exist, a field must belong to its datastore, a number must be numeric, and no answer may exceed 500 characters. Any problem is shown beside its question and nothing is created.

After the draft is created

  1. The toast says whether the draft validates ("It validates; test it on a record, then publish it.") or how many problems to fix, listed under Problems.
  2. If the template bundles a sub-workflow, it is created too, named after the new workflow and the child (for example "Month-end close - Period checks"). Open it and publish it first.
  3. Open the new workflow, read each step, and adjust wording, recipients and thresholds.
  4. Use Test… then Simulate on real records, once per branch.
  5. Publish.

What goes wrong

  • "N settings still need an answer." A required question is blank.
  • Problems after creation. Usually a field that does not suit the step, or an account or type that is not set up yet. Fix them on the steps.
  • Nothing happens when a record changes. The workflow is still a draft. Publish it, and turn on the Workflow Resume and Workflow Scheduler tasks if it waits or runs on a schedule.
  • A sub-workflow step fails. The bundled child was not published.
  • Approvals go nowhere. A default group such as group:Approvers does not exist here. Change the Approver on the step.

The twelve templates

Five general templates work on any datastore: Record approval, SLA escalation, Welcome e-mail sequence, Tell another system when a record changes, and Contract signing with an identity check. Seven are written for the ERP: Purchase order approval over a threshold, Supplier invoice exception, Overdue invoice dunning, New customer onboarding, Month-end close checklist, Project overrun alert and Stock reorder. See General Templates and ERP Templates.

Worked example

An office manager wants new supplier records approved before use. An architect chooses Record approval, names it "Supplier approval", picks the suppliers datastore, its Status field and its Name field, keeps pending, approved and rejected as the status values, enters group:Procurement as the Approver, and sets the person who asked to {{created_by_email}}. Create the draft reports that it validates. A simulation on a test supplier shows the approval request and, with the decision set to Rejected, the e-mail to the requester. They publish it.

Recommendations

  • Start from the nearest template rather than a blank canvas.
  • Check every default, especially group names and thresholds.
  • Publish bundled sub-workflows first.
  • Simulate before publishing, as for any workflow.

General Templates

Five templates work on any datastore: an approval, a deadline with escalation, a welcome sequence, a hand-off to another system, and a contract signing with an identity check. Each is a sound starting point for the most common processes, and each shows a pattern you can reuse in your own workflows.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — New from template…; filter Area to General or Integration

Record approval

Starts when a record is added. Its status is set to pending and the approver is asked, and e-mailed a link so somebody without back-office access can decide. Approved records are marked approved and the requester gets an in-app note; rejected ones are marked rejected and the requester is e-mailed the outcome.

  • Settings: Records are in, Status field, Status while waiting (pending), Status when approved (approved), Status when rejected (rejected), What to call the record, Approver, The person who asked ({{email}}), Send e-mail from.
  • Pattern: Set status around an Approval step with both ports connected.

SLA escalation

Starts when a record is added. A due date is worked out, counting only working time when a calendar is chosen, and written to the record; the run waits until then. When it wakes it reads the record afresh: if it is still not closed, its priority is raised and the escalation contact is told; if it was closed in time the run simply ends.

  • Settings: Records are in, Time allowed (minutes) (480), Count working time from, Store the deadline in, Status field, Status of a finished record (Closed), Priority field, Priority after escalation (high), What to call the record, Escalate to (group:Managers).
  • Pattern: SLA timer, Wait until the deadline, then a Condition.

Welcome e-mail sequence

Starts when a record (a new contact, customer or member) is added. It sends the welcome e-mail at once, waits, sends a tips e-mail, waits again and, unless the record has been marked as left in the meantime, sends a check-in e-mail.

  • Settings: Records are in, E-mail field, Name field, Status field, Status of someone who has left (Left), Tips e-mail after (days) (2), Check-in after a further (days) (5), Send from.
  • Pattern: E-mail and Wait steps, with a Condition after the last wait so a changed record is respected.

Tell another system when a record changes

Starts when a record is changed. If it has the status that should be sent on, the record goes to the other system as JSON over HTTPS. A successful call marks the record as sent; a failed one marks it as failed and tells the administrators, with the reason, so it can be sent again.

  • Settings: Records are in, Status field, Send records with the status (Ready), Store the result in, Send to (https://), If it fails, tell (group:Administrators).
  • Pattern: a Webhook with its On error port connected. Only an architect can change the Webhook step afterwards.

Contract signing with an identity check

Starts when a contract record is added. The other party's identity is checked first; once verified, the contract document on the record is sent for signature. When it is signed, two things happen side by side: the contract is converted into a record of your choice (an account or a project) and linked, and a welcome text goes out. Once both are done, a WhatsApp message and a welcome letter follow. A failed check or an unsigned contract marks the contract as stopped.

  • Settings: Contracts are in, Party name, e-mail and mobile fields, Contract document field, Identity check, Signature type, Signer role (party), Turn a signed contract into a record in, Its name field, Contract status field, Status when it stops (Stopped).
  • Pattern: Verification and Signature in sequence, then Parallel and Join. Each message carries on if its channel is not set up.

Before you publish one

  1. Check that every group named in a default (group:Managers, group:Administrators) exists, or change it.
  2. For SLA escalation and the welcome sequence, turn on the Workflow Resume task, or their waits never end.
  3. For contract signing, set up the verification and signature types first; see User Verification and Electronic Signatures.
  4. Simulate each branch, then publish.

What goes wrong

  • The welcome sequence keeps going after someone leaves. The Status of someone who has left does not match the value your records actually use.
  • The webhook template fails every time. The default address ends in .invalid on purpose; replace it with your system's https:// address.
  • Nobody is escalated. The Status of a finished record is spelt differently from your closed status, so every record looks closed or none does.

Worked example

A membership organisation uses Welcome e-mail sequence on its members datastore, with the tips e-mail after 3 days and the check-in a further 10 days later. It writes its own wording into the three E-mail steps, simulates a new member, and publishes. When a member cancels in their first week, the final check-in is not sent, because the Condition reads the Left status after the second wait.

Recommendations

  • Rewrite the message wording in your own voice before publishing.
  • Match status values exactly to the ones your datastore uses.
  • Reuse the patterns: approval with both ports, SLA plus wait plus condition, webhook with an error route.

ERP Templates

Seven templates are written for the ERP's own datastores and document types. They move documents only by their declared status moves, so every check and posting a move carries (supplier hold, budget, three-way match, open period) still applies, exactly as from the ERP desks. They are listed first in the gallery with an ERP badge.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — New from template…; the ERP templates are listed first

Purchase order approval over a threshold

Starts only when a purchase order is sent for approval (moves to Pending Approval); the Trigger's start conditions mean any other save starts nothing and a second save starts no second approval. Orders at or below the threshold are issued straight away. Above it the approver is asked, by e-mail too, while a timer runs alongside: if nobody has decided in time, the escalation contact is reminded. Approving issues the order and tells the buyer; rejecting cancels it and tells the buyer why. Settings include Needs approval above (5000), the three statuses, Approver (group:Approvers), Remind after (hours) (24) and Tell the buyer at ({{buyer}}). Use it instead of an approval matrix for purchase orders, not as well as one.

Supplier invoice exception

Starts when a supplier invoice is submitted. The three-way match engine checks it against its order and receipts. A clean match is approved for payment. When lines are held, the purchase order is looked up: differences within the tolerance (25) are accepted with the reason recorded; larger ones go to an approver (group:Accounts Payable). An accepted bill is approved and the accounts payable system is told over a webhook, or the AP team is notified if the call fails. A rejection returns the bill to Draft.

Overdue invoice dunning

Runs every day. A For each step takes every posted, unpaid sales invoice past its due date (at most 500 a day) and looks up its customer, skipping one whose dunning is blocked or who has no e-mail. On the reminder days (7, 14, 21 days overdue) it e-mails a reminder. Once 30 days overdue it sends a final notice by e-mail and post and puts the customer on credit hold with the reason, which also stops the final notice repeating. For consolidated statements and fees, use the receivables console's dunning run instead.

New customer onboarding

Starts when a customer is added. The customer is put on credit hold, their contact is verified, and your credit agreement (one document, chosen by number) is sent for signature. Once signed, a credit-review task is created and linked with a deadline (2880 minutes, in working time with a calendar), and the run waits until then. If the credit team has released the hold, the bundled Welcome sub-workflow starts; if not, the credit team is chased. A failed check or unsigned agreement leaves the customer on hold and tells the sales owner.

Month-end close checklist

Started by hand on an accounting period, from its Processes page. Three branches run side by side: the bundled Period checks sub-workflow raises a posting-check task and waits for it; a look-up finds any of the company's bank reconciliations still in progress and warns finance; and a VAT preparation task is created. When all three arrive at the Join, the financial controller is told the period is ready to close.

Project overrun alert

Runs every day, one run per project. It looks up the project's budget (no budget ends the run) and asks the projects engine for spend so far against it. Past the alert percentage (90) the project manager is texted, sent a WhatsApp message and given an in-tray alert; the run then waits for the quiet period (7 days), during which the schedule skips that project, so the alert is not repeated.

Stock reorder

Runs on a schedule. A For each step takes every active item with a reorder point. The stock engine gives its quantity on hand in the chosen company, and a library function works out a reorder quantity. An item at or below its reorder point gets a one-line purchase requisition from the chosen supplier, which is submitted, approved and converted into a draft purchase order through the requisition's own moves. Review and issue the orders from the purchasing console. An approval matrix on requisitions would also have to pass.

Setting one up

  1. Choose the template; the ERP's own datastores and fields are pre-selected where they exist.
  2. Pick statuses from the lists offered: they are the document type's own.
  3. Choose real groups for approvers and people to tell, and records (company, supplier) by their code.
  4. Create the draft, publish any bundled sub-workflow, simulate, then publish.
  5. For the scheduled templates, turn on the Workflow Scheduler task; for those that wait, the Workflow Resume task.

What goes wrong

  • A Set status step fails with "where it can go". The status given is not a declared move from the document's current status. Pick it from the offered list.
  • A purchase order is refused at Issued. An enabled approval matrix on orders is also asking; use one or the other.
  • Nothing starts when a timesheet is approved. Some ERP actions do not pass through the platform's save, which is why Project overrun runs on a schedule.

Worked example

A distributor sets up Stock reorder for its UK company with its main supplier, running every 1440 minutes, at most 500 items. A simulation on the next morning's data shows three requisitions and three draft purchase orders it would create. After publishing and turning on the Workflow Scheduler task, the buyer finds the draft orders waiting in the purchasing console each morning.

Recommendations

  • Read the ERP documentation for the documents a template moves; see Transactional Documents.
  • Choose either a template or a matrix for purchase approvals, not both.
  • Give the process owner a role on the workflow so they can see its runs.
  • Simulate scheduled templates before turning the scheduler on.