Systems & data rapidvalue.eu →

Record processes

A supplier record gets created in a spreadsheet, mailed to Finance, retyped into two systems, and nobody can say afterwards who approved it. A cost centre is retired in the finance system and lives on everywhere else for a year. These are not identity problems, which is exactly why they usually have no governance at all — they fall between the ERP that owns the number and the IGA platform that owns access.

RapidValue already lets you model your own object types — suppliers, facilities, projects, external organisations — with ownership, context, validity and provisioning as first-class aspects. A record process is the next step: a lightweight, governed flow for creating, updating or retiring one of those records, authored by an administrator and started by whoever needs it.

The claim it has to defend is narrow: a record never appears, changes or disappears without an approval that is attributable, and without a form the platform actually enforced.

What an administrator authors

A process is declared on an object type and describes four things.

Which operation, on which type. Create, update or retire — and the type it targets is picked from your live registry, not typed. All three execute for real: a create writes a new record, an update patches exactly the attributes the form supplied, a retire archives. Retire is deliberately the word: the underlying action is the reversible archive path, never a hard delete, so a retired record stays readable and its history stays intact.

A form. Fields drawn from a closed set of controls — text, long text, date, select, and two genuine type-ahead pickers that query the server as you type (identity and object reference). Validation is real and server-enforced, not a hint: format (email, URL), regular-expression pattern, length, numeric range and date range, each carrying an optional message you write yourself so a rejection says something a business user can act on. A field can be shown or hidden based on an earlier answer — one source field, equals or in, no nesting. The absence of nested AND/OR is a decision rather than a gap: this evaluates the form's own in-flight answers on every keystroke, and a general query language there invites conditions nobody can predict from reading the form.

A field can be hidden with a fixed value, in which case the server stamps the constant and discards whatever a client sent for it. And a field can be marked form-only — context for the reviewer rather than data for the record. Read that one precisely: it is the attribute mapping that enforces it. Where a process declares a mapping, only mapped targets are written and a form-only answer never reaches the record; a process with no mapping at all writes the answers straight through, which is what lets a simple update process work without authoring one. Form-only is a mapping-time guarantee, not a form-time one.

An approval chain. Either a pre-configured chain from the shared reviewer-chain registry — the same named chains that route access reviews and access requests — or a chain composed inline. Nothing special is invented here: multi-step sequences, quorum, and the platform's single resolver all apply unchanged. Auto-approval exists and is an explicit step in the chain rather than a mode, so a process configured to approve itself says so where you read the chain.

A process with no approval block configured does not silently approve. It falls through to the tenant default for this kind of intake — an administrator approval, seeded per tenant — and the builder renders that default in full rather than implying it.

Who can start it. A portal card carries a name, description, category and an optional service-level label, and a role list decides who sees it. An empty role list is the off-switch, and an absent list means everyone — a distinction the code makes explicitly, because collapsing the two would turn "nobody" into "everybody" the first time an administrator cleared the field.

The visibility rule is evaluated by exactly one function, called both by the catalogue that draws the card and by the endpoint that accepts the submission. Two copies of that rule drift into one of two failure shapes: a card that refuses when clicked, or a process nobody can find. One function makes both impossible.

The builder refuses rather than storing something unfulfillable

A dozen distinct configurations are rejected when you save, each naming what is wrong rather than failing generically: a target type that does not exist, a retire process carrying an attribute mapping (the archive path ignores attributes, so the mapping could never run), a reviewer chain that is not in the registry, an unknown role or category, a regular expression that does not compile, a hidden field with no fixed value, a stage assigned to nobody who could ever fill it in.

That posture is the point. A process that saves and then fails when a real person submits it is worse than one that refuses at authoring time, because the failure lands on someone who did nothing wrong and cannot fix it.

Multi-party intake

Some records genuinely cannot be described by one person. A new supplier is known to the requester — who they are, what they will deliver, which department sponsors them — and to Finance, who hold the VAT number and the banking details. Modelled as one form, it becomes a form the requester cannot complete; modelled as two requests, it becomes two records and a reconciliation problem.

A create process can therefore declare stages: two or more parties, in order, each supplying their own slice of one shared form. Stage one is the launcher's own part, completed in the same act as starting the process — through the same validator, with the same audit line as every later party. Later stages are routed to a named identity, a role, a scoped role or a sponsor, and the person who owns that stage sees the answers already given, under their labels, before adding theirs.

When the last stage settles, the collected answers are merged and submitted through the same single-party machinery: the same approval chain, the same task type, the same fulfilment. Approval and outcome are identical whether one person or five filled the form in. A process with zero or one stage never touches any of it.

Multi-party is create-only. An update or retire process with more than one stage is refused at authoring time, and the refusal says why: stages describe multi-party data collection, and "which existing record are we all editing" is a question stages do not answer. That boundary is named rather than half-built — the same reason the builder refuses the nine other unfulfillable configurations.

What the approver sees

An approval carries a title in business words — Create record: Northwind Logistics, Retire record: Cost centre 4180 — and the field labels the requester actually saw. Never an internal attribute key.

Those labels are a snapshot, taken when the request was submitted, not a live lookup. If somebody renames a field between submission and decision, the approver still sees what was asked. An update renders as a before/after diff with unchanged fields counted rather than listed; a retire states plainly what archiving does.

A rejection requires no ceremony but does record a reason, and the reason and the decider's name are readable afterwards on the requester's own view of the request. Depending on how the process is configured, a rejection either closes the request or returns it to the requester to correct and resubmit.

What it is not

It is not a workflow engine. There are no branches, no parallel tracks, no scripting. It is a form, a chain, and one of three outcomes. Anything that needs more than that is a different tool, and pretending otherwise would produce the usual result — a workflow product nobody can reason about, embedded in a governance product where reasoning is the entire value.

It does not create entitlements. A record process targets object types only. An earlier iteration could also create a target-system entitlement directly, and that capability was removed rather than left in place: it had no owner, no classification, no naming check and no duplicate check — precisely the state the platform's entitlement-onboarding governance exists to prevent. Where a record should drive access, that runs through lifecycle coupling, which proposes rather than creates.

Five parties is what the builder offers, not a constraint the server enforces. If that distinction matters to you, treat it as a design guideline rather than a limit.

Further reading: