Specialist Assignment and Review

The Procurement Specialist workflow has two halves: configuring the rules that decide who gets which purchase requisition, and the Specialist Review dashboard where the assigned specialist actually processes incoming requisitions.

Both are covered in the Procurement Specialist guide. This page is a deeper reference for how the two underlying tools behave, with concrete examples of how rule conditions are evaluated.

Specialist Assignment Rules

Where: Main menu → Administration → Assignment Rules (/specialist-assignment-rules).

Assignment rules are evaluated automatically when a purchase requisition is submitted for specialist review. The system inspects the requisition's department, project, and planned budget, then walks through the configured rules in priority order. The first rule that matches determines which user (holding the Procurement Specialist role) receives the requisition.

Rule fields

A rule has the following fields:

• Rule Name — descriptive label (for example, IT Purchases or High-value over €10,000). Required.
• Department — optional. If set, the rule only matches requisitions whose department equals this value. The comparison is case-insensitive (Marketing matches marketing). If left blank, the rule matches any department.
• Project — optional. If set, the rule only matches requisitions linked to this exact project (matched by project ID). If left blank, the rule matches any project (or no project).
• Min Budget / Max Budget — optional. If set, the rule only matches when the requisition's planned budget falls inside the range. Bounds are inclusive: the budget must be >= Min and <= Max. Either bound can be set independently (only a minimum, only a maximum, or both). If both are blank, budget is not considered for this rule.
• Specialist — the user (with the Procurement Specialist role) who will receive matching requisitions. Required.
• Priority — non-negative integer. Rules are evaluated in ascending order, so the lowest priority number is checked first and a matching rule with a lower number wins over one with a higher number.
• Active — when off, the rule is completely ignored during evaluation. Useful for temporarily disabling a rule without deleting it.

A blank field means "matches any"

Department, Project, Min Budget, and Max Budget are all constraints. Leaving one blank removes that constraint, so the rule becomes broader. A rule with all four blank matches every requisition — it is the ultimate catch-all and should always sit at the highest priority number so narrower rules get a chance first.

How a rule is matched

For the requisition's (department, projectId, budget), a rule matches only if all of its set constraints are satisfied:

Rule field	Matches when…
Department (set)	requisition department equals the rule department, case-insensitively
Department (blank)	always (any department, including a requisition with no department)
Project (set)	requisition's project ID equals the rule's project ID
Project (blank)	always (any project)
Min Budget (set)	requisition has a budget and budget >= Min
Max Budget (set)	requisition has a budget and budget <= Max
Min/Max Budget (blank)	that bound is not checked

Note that when a rule has a budget bound but the requisition has no planned budget, that rule does not match.

The matching algorithm

1. Load all rules, drop any that are inactive.
2. Sort the remaining rules by Priority ascending (lowest number first).
3. Walk the list top to bottom; the first rule whose constraints all match wins, and its specialist is assigned. Evaluation stops immediately.
4. Relaxed-department fallback (see below) — only if step 3 found nothing.
5. If still nothing matches, the requisition cannot be submitted and the user gets a specific error (see No-match behaviour).

Designing the rule set

Put narrow, specific rules at low priority numbers (for example, priority 0 — high-value purchases over €50,000 go to the head of procurement), then add broader catch-all rules at higher numbers. Because the lowest number is checked first, specific rules get the chance to claim a requisition before a generic rule does.

Relaxed-department fallback

There is one important second pass that the rule list does not make obvious.

If no rule matches on the first pass and the requisition has no department set (blank/empty), the system runs the active rules a second time, ignoring the Department constraint on every rule. Project and budget constraints are still enforced — only Department is dropped. The first rule that matches under these relaxed conditions wins.

This means a department-specific rule can still pick up a requisition that has no department, as long as its project and budget constraints are satisfied. The fallback only triggers when the requisition's department is blank; a requisition that has a department that simply isn't covered does not get this relaxation.

No-match behaviour

A no-match blocks submission — it is not a silent "skip"

If neither the strict pass nor the relaxed-department fallback finds a rule, the requisition cannot be submitted for specialist review. The user receives a clear error explaining why, drawn from the actual rule configuration. The requisition is not simply left "unassigned" — submission is rejected.

The error message adapts to the cause:

• No rules configured at all — "This requisition cannot be submitted for review yet — no specialist reviewers have been configured. Please contact your administrator to set up specialist assignment rules."
• Department not covered — if rules use departments but none cover this one, the message lists the covered departments. If the requisition has no department but the rules all require one, it says so and lists the departments specialists are assigned to.
• Budget out of range — if rules use budget ranges and the requisition's budget falls outside all of them, the message lists the covered ranges. If the requisition has no planned budget but rules require one, it says a budget value is required.
• No specific reason — if none of the above pinpoint it (for example a project mismatch), a generic message explains that no rule matches the combination of department, project, and budget.

Every message ends with "Please contact your administrator to resolve this."

Worked example

Suppose a tenant has these active rules (no project constraints, for clarity):

Priority	Rule Name	Department	Min Budget	Max Budget	Specialist
0	High-value IT	IT	50,000	(blank)	Alice
10	IT standard	IT	(blank)	50,000	Bob
20	Marketing	Marketing	(blank)	(blank)	Carol
100	Catch-all	(blank)	(blank)	(blank)	Dave

Now consider four submitted requisitions:

#	Department	Budget	Result	Why
1	IT	80,000	→ Alice (rule High-value IT)	Lowest priority (0) checked first; IT matches and 80,000 >= 50,000. Evaluation stops.
2	IT	20,000	→ Bob (rule IT standard)	Rule 0 fails (20,000 < 50,000). Next rule (priority 10): IT matches and 20,000 <= 50,000.
3	(blank)	5,000	→ Dave (rule Catch-all, via relaxed-department fallback)	Strict pass: rules 0/10 require IT, rule 20 requires Marketing — none match a blank department, and rule 100 (blank department) matches → actually wins on the strict pass already. (See note below.)
4	Finance	5,000	→ blocked	Finance matches no department-specific rule, and the only blank-department rule here would still match…

Reading examples 3 and 4 correctly

The relaxed-department fallback only matters when every matching candidate has a Department set. In the table above, rule 100 has a blank department, so it already matches on the strict pass — example 3 resolves to Dave without needing the fallback, and example 4 would also resolve to Dave because the catch-all matches any department.

To see the fallback and a true no-match, remove the priority-100 catch-all so every remaining rule is department-specific:

Priority	Rule Name	Department	Min Budget	Max Budget	Specialist
10	IT standard	IT	(blank)	50,000	Bob
20	Marketing	Marketing	(blank)	(blank)	Carol

• Requisition with blank department, budget 5,000 → strict pass finds nothing (both rules require a department). Because the department is blank, the relaxed-department fallback runs: it re-checks ignoring department. Rule 10 (priority 10, checked first) now matches because budget 5,000 <= 50,000 → assigned to Bob.
• Requisition with department Finance, budget 5,000 → strict pass finds nothing (Finance is neither IT nor Marketing). The fallback does not run because the department is not blank. → blocked with the message: "Department "Finance" does not have a specialist assigned. Currently covered departments: IT, Marketing."

For step-by-step instructions on creating a rule, see the Procurement Specialist guide → Creating a New Rule.

Specialist Review Dashboard

Where: Main menu → Approvals → Specialist Review (/specialist-review).

The dashboard lists every purchase requisition that has been assigned to the currently signed-in user for review. It is the specialist's daily inbox.

Each row shows:

• Request No.
• Request Name
• Department
• Budget (planned budget and currency)
• Date (date of the request)
• Review action button

Click Review on any row to open the full requisition. From there the specialist can:

• update or correct the requisition details,
• set the procurement method (Simple Procurement, RFQ or RFP),
• select the supplier (or supplier shortlist),
• push the requisition into the next stage of the procurement workflow.

If no requisitions are currently assigned, the page shows an empty state with the message "No requisitions pending review".

Permissions

Action	Required permission
Access the Specialist Review dashboard	PurchasesRequisitions / Review
View / search assignment rules	SpecialistAssignmentRules / View, SpecialistAssignmentRules / Search
Create / edit / delete assignment rules	SpecialistAssignmentRules / Create, Update, Delete (typically restricted to tenant administrators)
Be selectable in the Specialist field of a rule	user must hold the Procurement Specialist role

If a user with the Procurement Specialist role is missing from the Specialist dropdown, check that the role is correctly assigned in Platform Users.

Related guides

• Procurement Specialist — full walkthrough for both halves of the workflow.
• Purchase Requisitions — what a specialist actually edits on the requisition.
• Platform Users and Assigning a role to a user — how to grant the Procurement Specialist role.