Deriving a role from a demand

Sometimes the candidate list finds nobody — and the reason is not a missing person but a missing role. The demand is then the moment where it is said for the first time that this work is needed.

Why this is not a single button

A role is not a container for everything that stood in a demand. It is a bundle of activities serving a shared purpose — which is why purpose is a required field on the role type.

A button that tips the activity list one-to-one into accountabilities produces catch-all roles without a purpose and damages the model faster than it saves work. A list of unrelated activities must become either more than one role, or part of it belongs to an existing one, or the demand itself was really several.

Step 1 — Show what already exists

The search runs per individual activity, not per role. The purpose is conflict avoidance:

An activity that sits in two roles is a role conflict. Two roles claim the same work and nobody knows who decides. In a role-based model that is a defect, not a blemish.

Each activity yields one of three findings:

Finding	What to do
Already covered	No new role — link the demand to the existing one. The most common correct outcome.
Similar	The human decides: same thing meant, or actually something else?
Nowhere yet	Candidate for the new role.

If all activities are covered, the path does not continue at all — the role is already there.

The search is a help, not a guarantee. It finds what is linguistically similar; a role naming the same work differently can slip through. If the semantic index is unavailable, only a text comparison runs — and that is stated explicitly, so “nothing found” is not read as “there is nothing”.

Step 2 — Group and justify

You sort the remaining activities into groups. Each group needs a purpose — no default, no placeholder generated from the demand’s name.

If you cannot phrase a purpose, you have not found a role. The continue button stays disabled while any group lacks a purpose or has no activities.

rALPH can suggest

Grouping and phrasing a purpose is language and pattern work — laborious for people, natural for a model. Via “Suggest a grouping” rALPH delivers groups, draft purposes and a reason why these activities belong together. It also names the activities it can assign to no group — often the most valuable statement, because it shows where the demand itself is fuzzy.

The suggestion appears as a pre-filled, fully editable grouping, not as a result. Nothing is saved before you confirm; the purpose texts stay freely overwritable. And here too you only get further once every group carries a purpose — even one from rALPH has to be kept or replaced.

If no AI is configured for the tenant the button is absent and the wizard works unchanged, just without a pre-fill. The call costs tokens and therefore only runs on explicit request — never automatically when opening.

Several roles may emerge from one demand; that is exactly what the grouping is for. If several purposes appear, that is also a hint that the demand was heterogeneous — then it is worth splitting it.

Step 3 — A draft, not a record

Only then does the regular role creation form open per group, pre-filled:

From the group	Becomes on the role
activities of the group	accountabilities
the purpose you entered	purpose
the demand’s competence requirements	REQUIRES relationships

Saving goes through the normal draft path. That means, without any extra work: write permissions on the role type, its approval mode, the validator rules and the audit trail all apply. A dedicated shortcut path would bypass exactly that chain.

After approval you link the new role to the demand via REQUIRES_ROLE — from then on the activity axis takes effect in matching.

Related

• Reading the candidate list — Why the candidate list was empty
• The demand profile — three axes — Activity as the first axis
• Roles — Roles, purpose and accountabilities
• Demand & Resource Planning — The overview