Loading

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.