Loading

Record Steps

The Records group of the Steps palette changes and reads data: Update record, Set status, Create record, Convert record, Look up and Set variables. Every write they make goes through the platform's normal save, so the record's audit trail, table rules, field security and validation apply exactly as they would to a person saving a form.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — the Records group of the Steps palette

Which record a step changes

Update record, Set status and SLA timer have a Record to change (or Stamp the deadline on) choice:

  • The record the workflow runs on: the usual choice.
  • The current row of a For each step: offered when the step sits on that loop's Each row path.
  • Another record (give its ID): choose In datastore and give the Record ID as a placeholder, such as {{found.ID}} or a created record's ID.

A scheduled run that is not started against a record has no record of its own, so choose a loop row or another record there.

Update record

  1. Choose the record to change.
  2. Under Set these fields, add a row per field: the Field and its New value. Values may use {{field}}, {{now}} or {{vars.name}}.

On an ERP document, an Update record that names the status column is refused: use Set status, which makes the document's own declared move.

Set status

  1. Choose the record, then the Status field.
  2. Enter the New status.
  3. For an ERP document, optionally give a Reason (ERP documents), recorded on the document's history.

The change is noted in the record's activity. On an ERP document (a purchase order, requisition, supplier or sales invoice) the step makes the document's declared move to that status, with the approvals, checks and postings that move applies. A move that is not declared from the document's current status fails the step and says where it can go. Moves that need a reason get the step's name when Reason is blank.

Create record

  1. Choose Create a record in.
  2. Under With these values, set each field of the new record.
  3. For an ERP document, fill in Its line (ERP documents): item, qty, unit_price and description, or the lines datastore's own field names.
  4. Optionally change Link the new record as (default "created"): the relationship shown in both records' links.

The new record is linked to this one and numbered when its datastore has a numbering scheme. Later steps use its ID as {{created.step.ID}}. An ERP document is created through the document engine, at its opening status with its counterparty defaults.

Convert record

  1. Choose Convert into a record in.
  2. Leave Convert this record instead (optional) blank to convert the run's record, or choose a datastore and give Its record ID.
  3. Under Copy fields, map each field From this record Into the new record.
  4. Optionally change Link the new record as (default "converted").

Between two ERP document types, such as a requisition into a purchase order, the document engine does the conversion: every open line is copied and linked, the source moves on, and no field mapping is needed.

Look up

  1. Choose Look in.
  2. Add rules under Find the record where, such as customer ID equals {{customer_id}}.
  3. Enter Save it as, for example "customer". Letters, digits and _ only, starting with a letter.
  4. Connect Found and Not found.

The first matching record is used, and later steps read it as {{customer.field}}. With no rules it finds the first record in the datastore, and Validate warns.

Set variables

Works out values once and names them for later steps as {{vars.name}}. See Placeholders and Variables.

What goes wrong

  • The step failed with a validation message. The write broke a field rule or permission, exactly as a form save would. The reason is in the step's detail in the run history.
  • "is not a field of" warnings: a field name no longer exists on the datastore.
  • "No field values: the new record will be blank." A Create record with nothing set.
  • A loop of saves. An Update record on the run's own record re-triggers an update workflow; use the Trigger's start conditions.

Every step here has If this step fails, carry on with the next one. Off, a failure stops the run.

Worked example

A lettings team converts an accepted application into a tenancy. A Look up saved as "property" finds the property by its reference. Convert record turns the application into a tenancy, copying the applicant's name and e-mail and linking the two. Set status moves the application to Converted, and Update record on Another record, the property ({{property.ID}}), sets its availability to Let.

Recommendations

  • Use Set status for statuses, especially on ERP documents.
  • Name look-ups for what they find.
  • Always connect Not found, even to an End step with a message.
  • Prefer Convert record where the new record comes from this one, so the two stay linked.