Access level by role (DMN)
Access decisions often have a natural precedence: the most permissive matching role wins. Priority encodes that without depending on row order.
#What this example shows
A Priority hit policy, ordered by output value.
A list input, matching several roles in one rule.
An explicit deny as the safest default.
#Columns
Column | Type and meaning |
|---|---|
Role (input) | string: the user's role |
Account status (input) | string: active or suspended |
Access (output) | string: admin, write, read or none |
#The decision table
Hit policy: P (Priority: admin, write, read, none). Cells are FEEL expressions, so a range, a list or a negation is a legal value; a dash means the input is irrelevant to that rule.
Role | Account status | Access | Annotation |
|---|---|---|---|
- | "suspended" | "none" | Suspension beats every role |
"owner", "admin" | "active" | "admin" | |
"editor" | "active" | "write" | |
"contributor" | "active" | "write" | |
"viewer", "guest" | "active" | "read" | |
- | - | "none" | Default deny |
#Making it your own
Priority is decided by the output order you declare, not by row order.
A default-deny final row is the pattern to copy for any access decision.
Keep the role list in allowed values so an unknown role cannot slip through.
#Related
The hit policy is the whole decision.
