# 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 [Discount by customer tier (DMN)Two inputs, one output, no overlaps.](https://help.gocapable.com/diagrams/discount-by-customer-tier-dmn.html) [Loan eligibility (DMN)First hit policy, because the rules are ordered.](https://help.gocapable.com/diagrams/loan-eligibility-dmn.html) [DMN examplesBack to the rest of these examples.](https://help.gocapable.com/diagrams/dmn-examples.html) --- _The hit policy is the whole decision._