Lifecycle & decisions rapidvalue.eu →

Lifecycle coupling

Joiner-mover-leaver is the discipline of keeping access aligned to a person's lifecycle. Lifecycle coupling is the same discipline one level up: keeping access aligned to the lifecycle of the things the organisation is made of.

Onboard a supplier and somebody, eventually, creates a group for them. Retire a cost centre and that group outlives it — usually by years, usually noticed by an auditor rather than by anyone who could have prevented it. The work is not hard; it is just nobody's job, and it depends on a person remembering a connection that exists only in their head.

A coupling rule writes that connection down. It is the one place in the platform where the business object model drives access governance directly rather than through a parallel manual process — and it is deliberately conservative: it proposes, and a person decides. It never creates an entitlement and it never revokes access.

What a rule declares

Five things, all pickers over your own data rather than free text.

Which records it watches. A condition over a business record type — context dimensions such as departments, cost centres and legal entities, or your own custom types such as suppliers or projects. The condition uses the same filter DSL that drives triggers, dynamic groups and SoD rules, evaluated with the record as its subject. An empty condition is refused at save time: a rule that matches everything is not a rule.

Which kind of entitlement it is about. A scope: an optional target system, an entitlement category — security group, distribution group, mail-enabled group, shared mailbox or permission set — and optionally a specific entitlement type. Eligibility is checked when you save and again when the rule fires, so a scope that stops being valid stops the rule rather than silently widening it.

A mapping, from record attributes to exactly four things the proposal can be pre-filled with: a suggested name, a purpose, the value that fills the organisational placeholder in your naming convention, and the source the owner is derived from. Four targets, closed set. A mapping key outside it is a save-time refusal, because a mapping that writes where nothing reads is configuration that quietly does nothing.

What happens when a linked record changes — flag it for review, attempt a correction, or leave it alone.

What happens when a linked record ends — propose a deprecation, or nothing at all. There is no delete variant and no disable variant. The only end-side outcome is the platform's existing governed sunset machinery.

Beginning: a proposal, never a creation

When a record starts matching a rule, the coupling seeds a draft access request — an entitlement-onboarding draft in the ordinary intake queue, marked with where it came from, with the mapped name and purpose already filled in.

It stops there. No code path in the coupling creates an entitlement. The entitlement exists only after a person opens the draft, completes it, and the request travels its normal approval chain — the same chain, the same reviewers, the same evidence as a draft somebody typed by hand. Ownership follows from the mapping through the ordinary ownership cascade, and if nothing resolves, the cascade falls through as it always does rather than inventing an owner.

Two mechanisms stop the queue from filling with noise. A live link between a rule and a record suppresses re-seeding, and at most one non-terminal request can exist per rule-and-record pair — enforced in the database, not only in the code, so a cancelled draft does not block a deliberate retry but a duplicate cannot be created by two passes racing.

Where the mapping cannot resolve something, the draft is still created and the failure is named on it. Suppressing the proposal because one field would not render would hide the useful half of the signal.

Ending: propose-only, with a brake

When a linked record is archived, or passes the end of its validity window, the coupling proposes a deprecation plan in proposed status against the linked entitlement — and stops. Nothing is revoked, disabled or deleted. A human approves the plan, and only then does the platform's existing sunset clock start, with a grace period that is tenant-configurable and thirty days by default.

Three properties are worth stating outright, because they are what make an automatic end-of-life proposal safe to switch on:

A record that has merely vanished is not treated as a decision. The engine distinguishes ended — archived, or past its validity date — from absent, and absence alone is not evidence that anyone decided anything.

Cancel once and it stays cancelled. If a person cancels a proposal the coupling made, the engine records that and never proposes it again. An automation that re-asks a question a human already answered is not a control; it is noise that trains people to ignore it.

A mass-end brake. If a single pass would propose deprecation for ten or more entitlements and that is more than a quarter of everything the rule currently holds, the rule proposes nothing at all and raises a warning instead. The scenario it is built for is not exotic: a partial import, a bad synchronisation, a bulk archive run by someone testing something. All of those look, to a rule, exactly like a legitimate reorganisation — and the difference matters far too much to guess. The brake fails toward keeping access.

There is a matching brake on the beginning side: a per-rule ceiling on how many open drafts a rule may have at once, twenty-five by default and configurable from one to a thousand. There is no "unlimited". When a rule reaches its ceiling it creates nothing further and says so, and the ceiling counts drafts awaiting a human rather than entitlements — because the thing being protected is the review queue, not the directory.

Every one of those situations — ceiling reached, scope no longer eligible, brake tripped — raises one visible advisory naming which rule and which reason, and it clears itself on the first clean pass. A rule that stops working is never silent, and one rule going wrong never silences its siblings.

What it does not do

It does not change access in either direction. The only two writes the coupling ever makes are a draft request and a proposed deprecation plan. Both are questions put to a person.

It does not run on demand. There is deliberately no "converge now" endpoint. A record event nudges the affected record immediately; a daily pass is the guarantee behind it, catching anything an event cannot see — a validity window that expired by the clock, a rule created after the records it matches. Anything clock-driven is therefore within a day, not immediate, and the daily cadence is a choice: records move at organisational speed, a proposal lands in a human queue anyway, and a tighter loop would add load without adding signal.

A linked record's naming and description are watched too. Rename the source record, or edit its description, and the same event nudge that seeds a proposal on creation flags the linked entitlement for review — the same day, not on the next daily pass. One case is an honest gap rather than a broken check: a record completed with free text (no naming pattern was ever applied to it) has no tracked baseline to drift from, so there is nothing to compare. The platform says so on the edge itself — a distinct "not tracked" state, not a silent "nothing has changed" that would look identical to a genuine non-event.

There are no seeded rules. A coupling is a statement about how your organisation works, and there is no default that could be right for two organisations at once. Nothing fires until you write one.

It carries no approval configuration of its own. Both ends already have governance — the intake queue on one side, the deprecation approval on the other — and a third approval on the rule itself would be configuration that never runs.

Trying one safely

A rule has a dry run that writes nothing: which records match, what each resulting proposal would be named, which owner would be derived, and whether the brake would trip. It caps the number of records it walks and says when it did.

The honest use of that is not to admire the matches. It is to look at the ones you did not expect, before a rule that runs daily starts putting them in somebody's queue.

Further reading: