Loading

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.