Loading

Compliance Checks

Compliance checks are the things that must be done before a record can go ahead: a signed parental consent, an in-date insurance certificate, a declaration. You define each kind of check once, say which records it applies to, and the platform lists the checks on every record that needs them and holds the approval stage until they are met.

Where to find it

Architect Panel → Data:

  • Datastores — the Requirement Types datastore, where each kind of check is defined

Architect Panel → Automation:

  • Rules — the rules that decide which records a check applies to

How the pieces fit

  1. A requirement type describes one kind of check and what proves it.
  2. A rule (optional) decides which records it applies to.
  3. A user input view stage with the Require Compliance stage action works out which checks each record needs when it reaches that stage, and holds the stage until they are met. Setting up the stage is covered in User Input Views.
  4. The Checks pane on the record lists each check and is where evidence is recorded. See The Checks Pane.

Nothing is supplied: the platform ships with no requirement types and no rules, because the checks belong to your organisation.

Defining a requirement type

Open the Requirement Types datastore and add a record. The fields are:

  • Key: a stable identifier, such as parental-consent.
  • Name: what people see, and what appears in the sentence that blocks progress. Write it as a thing to be done: "Parent/guardian consent".
  • Description: what the check is and why it is asked.
  • Applies To: the kind of record that carries it, for example application, placement, student or employer. It must match the value the stage uses, or the check is never asked.
  • Evidence: what proves it. See below.
  • Blocks Confirmation: on, and the stage cannot be approved until the check is met. Off, and the check is listed as optional and blocks nothing.
  • Applies When: the key of a rule. Blank means the check applies to every record of that kind.
  • Chase Clock: optionally, an obligation type key, so outstanding checks are chased like any other deadline. See Obligations & Deadlines.
  • Valid For: for declarations only, how long one lasts, written calmonths:12, caldays:30 or hours:48.
  • Enabled and Order: switch a type off without deleting it, and set the order checks are listed in.

The kinds of evidence

  • document: met by an approved, in-date controlled document. Its expiry comes from the document. See Document Control.
  • consent: met by a signature request that every signer has completed. See Electronic Signatures.
  • declaration: met when somebody with edit rights records it as done. The weakest kind, so use it only where nothing better exists.
  • assessment and verification: offered by the field, but not currently usable, because no assessment or verification can yet satisfy a check. Do not choose them.

How "Applies When" behaves

When a record reaches the stage, each type's rule is asked about that record's own fields. If the rule matches, or cannot decide (an empty field, a missing rule, a rule never published), the check is asked for. That is deliberate: for a safeguarding control, asking too often is the safe mistake. The Rules screen shows "Asked for but not here." when a type names a rule key that does not exist.

Which checks apply is worked out when the record reaches the stage. Changing a rule later does not add or remove checks on records already past that point.

What goes wrong and how to tell

  • The stage approves with no checks listed: no enabled type has an Applies To matching the stage's "This Record Is A" value.
  • Everybody is asked for a check meant for a few: the Applies When rule is missing, draft only, or cannot decide (check it with Preview on the Rules screen).
  • No chase clock opens: check your first test record; leave Chase Clock blank if you do not use obligations.

Worked example

A work-experience scheme needs parent/guardian consent from applicants under 18, and an in-date employer's liability certificate for every placement. The architect publishes a rule parental-consent-applies (ageatstart < 18), then adds two requirement types: "Parent/guardian consent" (Applies To application, Evidence consent, Blocks Confirmation on, Applies When parental-consent-applies) and "Employer's liability insurance" (Applies To placement, Evidence document, Blocks Confirmation on). The confirmation stage of the application form is set to Require Compliance for the application, also checking the linked placement. A 16-year-old's application now waits for both; a 19-year-old's waits only for the insurance.

Recommendations

  • Publish and preview the rule first, then name it in Applies When.
  • Use Blocks Confirmation only for genuine controls; leave the rest optional.
  • Prefer document or consent evidence to declarations.
  • Test with one record of each kind before going live.