Skip to content

Platform

One approval engine. One inbox. One ledger.

Document versions, CAPAs, nonconformances, change requests, complaints, audits and inspection lots all approve through the same engine, and so do the record types you build. Every step lands in one task inbox, and every signature in one ledger. Learn it once.

A running workflow: its triage step approved, the QA closure step in progress with its assignee and completion rule, and overall progress and elapsed time alongside.

The engine

Many record types in. One engine. One place the work lands.

There is no second approval system anywhere in the product. Each record type below starts a run on the same chain of objects, named here after the tables that hold them.

  1. Templateworkflows

    The process, drawn once: steps in order or in parallel, reviewers by role or by name, ALL or ANY to pass, a due-in, and whether a comment or a signature is required.

  2. Versionworkflow_versions

    Publishing retires the version before it, so one version is live. A step with nobody to review it cannot be published.

    Database refusesA retired or archived version never comes back.
  3. Runworkflow_instances

    One per record submitted, tied to the version it started on.

    Database refusesIts status moves only through the engine’s own actions.
  4. Stepworkflow_instance_steps

    Carries its own copy of the rule, due-in, comment and signature settings, so editing the template later does not rewire a run in flight.

    Database refusesIts status moves only along legal edges, and only through the engine.
  5. Tasktask_instances

    Activating a step gives each reviewer a task with a due date.

    Database refusesAn approval task cannot be actioned except through the endpoint that checks the signature.
  6. Signaturesignatures

    Where the step asks for one, the reviewer re-authenticates and the signature is written against their task or step.

  • One inbox

    My Tasks

    Whatever module a step belongs to, the task lands in the same queue, with its record and due date.

    • Documents, CAPAs and NCs side by side
    • Overdue dates stand out
  • One ledger

    Signatures and the audit trail

    Every signature is a row in one signature ledger, and every change to templates, runs, steps and tasks is on the audit trail.

    • One signature table for every record type
    • The same append-only audit trail
    Anatomy of a signature

Not on the engine. Quality events and training have their own, simpler flows: an event has one assigned reviewer, and training runs on assignment, completion and a manager’s verification. And a run does not branch on the record’s data. Steps run in the order the template sets.

One inbox

Everything waiting on you, wherever it came from.

A step activating anywhere in the system creates a task. Those tasks land in one list with their record, its type and its due date, so nobody has to remember which module was waiting on them.

  • Assignments from every module in a single queue
  • Due dates computed from the step that created them
  • Open the record straight from the task
The My Tasks inbox: documents, CAPAs and nonconformances assigned to one person in a single queue, each with its entity type, category and due date, overdue dates in red.

Automation rules

When this happens, tell these people.

A rule reads: when a record of this type is created, updated or changes status, and these conditions match, do this, optionally only at certain sites or in certain departments. Most actions notify groups, people, the owner, the supplier or outside email addresses. A quality event can also raise a nonconformance, and a record type you build can raise a task.

  • Conditions over the record’s own fields
  • Scoped by site and department
  • Works on the record types your admins build, including a daily date check
An automation rule being set up: the record type, the statuses that trigger it, the groups, people and email addresses to notify, and optional site and department scope.

The rules

What the engine will not let anyone do

The rules sit on the engine’s own tables, so a direct write through the app’s GraphQL API is refused like any other caller.

Set a run or a step to approved by hand
Run and step statuses change only through the engine’s actions, such as approve, reject, reassign and cancel, and only along legal edges.
Database refuses
Tick off an approval task directly
An approval task can only be actioned through the endpoint that verifies the signature and advances the run. A task cannot be re-pointed at another record.
Database refuses
Bring back a retired process
Retired and archived template versions are terminal. To change the process, you publish a new version.
Database refuses
Publish a step nobody can review
Publishing is refused, and the version goes back to draft, if any step has neither a role nor a named reviewer.
Server refuses
Rewire an approval already in flight
Each run keeps its own copy of the step rule, due-in, comment and signature settings. Template edits apply to the next run.
Server refuses
The route, the reviewers and the deadlines
Steps, parallel groups, ALL or ANY, due-ins and comment and signature requirements are yours to set per template.
You configure

Connections

What it connects to today

A short list, and a true one.

ConnectionWhat it is for
Service accountsMachine users for system-to-system work. They have no password and cannot sign in; their keys are shown once and stored hashed, and they act with only the roles you give them. Created by a person, never self-issued, and set up with us on request.
Google and MicrosoftSign in with the accounts your people already have.
Google Cloud Storage or S3-compatible storageDocument and attachment storage.
SendGridOutbound notification email.

There is no public API, no webhooks and no ERP, MES or LIMS connector today.

Straight answers

What evaluators ask about the engine

Does every record type run on the engine?

No. Document versions, CAPAs, nonconformances, change requests, both kinds of complaint, audits, inspection lots, specifications, log books and the record types you build do. Quality events have one assigned reviewer instead, and training runs on assignment, completion and a manager’s verification.

Can a workflow branch on the record’s data?

No. A template runs its steps in the order it sets, sequentially or in parallel groups. It does not choose a path from a field on the record. If two kinds of record need different routes, give them different templates.

What happens to approvals in flight when we change the process?

They finish on the settings they started with. Each run keeps its own copy of the step rules, due-ins and comment and signature requirements, and publishing a new version retires the old one for the next run.

Is there an API or webhooks?

Not a public one, and no webhooks. For system-to-system work we set up a service account with you: a machine user with its own roles, no password, and a key that is shown once and stored hashed.

See one engine run your documents, CAPAs and NCs.