Authorisation Logic Audits for Case Management
Most authorisation failures in case management do not start with a missing login check.
They start when the real operating rule is more specific than the system can represent.
A refund below 100 goes to support. A refund above 100 needs a manager. A refund above 1,000 needs finance. A write-off may depend on currency, customer segment, case age, or risk score. The requester cannot be the approver. These are real controls operations teams use.
The system cannot express them. The rules move elsewhere: Slack, a spreadsheet, a manager's memory, or custom code one team understands and nobody reviews.
That is where the audit problem begins.
Access Control Is a Starting Point, Not a Control Model
Basic access control answers a narrow question: can this person open this screen or call this endpoint?
Case management needs a sharper answer. Logging in and performing a specific action on a specific case are two different things. A support agent can close a routine enquiry but not approve a payment exception. The same role may have different limits by queue, region, product, or customer tier. The same action can be legitimate in one workflow and require escalation in another.
Authorisation that cannot represent that context stops being a control. It becomes a formality. The real decision moves off-system, and the case record no longer shows how the work was governed.
Numeric Thresholds Are Where Policy Models Break
Many operating rules in case work are numbers, not abstract permissions.
Refunds above 250 require team lead approval. Credits above 1,000 require finance. Claims older than 30 days need exception handling. Adjustments above five percent need a second reviewer. Teams use these thresholds to calibrate how much risk can move quickly.
The common mistake is to hard-code the numbers into each workflow. That works once. The threshold changes. Another team needs different limits. An auditor asks why a specific case crossed a boundary. The hard-coded rule fails in every situation.
The team can find the code. They cannot prove which policy version was active when the case moved.
Auditors ask two questions. What does the system do now? What did it do then, and under whose authority?
Flexibility and Consistency Are Not Opposites
Authorisation logic must be configurable. Today's thresholds will change, and different teams need different rules. But flexible does not mean informal.
There is a real difference between a policy model that adapts and one-off implementations that each invent their own logic.
In the first model, someone with authority defines the rules in a structured, reviewable form. Support agents can request refunds up to 250. Managers can approve up to 1,000. Finance must approve anything above that. The requester cannot be the approver. A threshold change has a place to happen. There is a record of who changed it. There is a way to show which version governed the decision.
In the second model, every workflow carries its own version of that logic, often in code nobody else reads. Changing it means finding every place it lives. Auditing it means reconstructing policy from implementation.
The first model is auditable. The second is a future reconstruction project.
The Rule Itself Needs to Be Part of the Record
For authorisation to be auditable, knowing an action was allowed is not enough. The record must show why.
A sensitive action runs. The evidence trail should capture the actor, the case identifier, and the action requested. It should capture the relevant inputs: the amount, the case age, the risk score, whatever the rule evaluated. It should capture the policy or rule that matched, the outcome, and the timestamp. If the rule required an approval path, the approval appears there too.
That structure turns authorisation from an invisible gate into decision evidence. Without it, the team may be enforcing rules correctly. They cannot demonstrate it. They would need logs, code, or operator interviews to reconstruct the decision after the case closed.
Denied Attempts Are Evidence the Control Worked
Authorisation audits tend to focus on successful actions. That misses half the story.
An operator tries to act outside their authority. The system blocks it. That denial is proof the control worked. It shows the boundary held. A record that keeps only successful paths gives a misleading picture.
A refund above the operator's limit is blocked and routed to a manager. The case record should show the initial block, the routing, and the approval. That sequence tells the story of a workflow that handled the case correctly. Hiding the first attempt and showing only the final approval makes the process look cleaner than it was.
Denials also protect the operator. If a decision is challenged later, the record can show the authorisation check ran. It can show the control was applied. It can show escalation happened as required.
Policy Changes Are Control Changes
One authorisation question usually gets missed: who changed the rule, and when?
An approval threshold moves from 1,000 to 5,000. That is not a routine configuration update. It is a change to a financial control. The audit trail should capture who made it, the change itself, the activation time, and the affected cases. Older cases should remain governed by the rule in effect when they moved.
Disputes and regulatory reviews are time-sensitive. The question is rarely what the policy says today. It is what the policy was when the case was handled. Without versioned authorisation policy, that question is hard to answer cleanly.
Evidence Belongs Near the Case
Authorisation evidence should not live only in a security log.
Security logs are useful for investigation. They are not where operators, managers, and auditors make sense of a case. The case record is where the operational story needs to be legible. The case arrived. The operator requested an action. The authorisation rule evaluated the context. The system allowed, blocked, or escalated the request. The action executed only after the required path was satisfied. The outcome and evidence stayed attached.
That does not mean every policy evaluation must appear in the interface. It means the evidence must be accessible where the case is reviewed, not locked away in a system only engineers can query.
Auditability Requires Context, Versioning, and Denied Attempts
Authorisation logic that holds up under audit has a consistent set of properties.
Decisions are context-aware. The rule sees the actor, the action, the case details, the amount, and the relevant operational fields. Numeric thresholds are first-class policy inputs, not constants scattered in code. The system can force the requester and approver to be different people. This is maker-checker: the person who prepares an action cannot approve it. Policy versions are preserved, so the team can show which rule was active at any point. Denied attempts are logged, not silently discarded. The decision record sits near the case, not only in a separate log stream.
Those properties make authorisation inspectable. They make it easier to explain and defend. Low-risk work moves quickly. High-risk work stays controlled and provable.
Latch Fits Authorisation into the Case Workflow
Latch fits authorisation into the case workflow, not as a side check attached after the action runs.
The platform is built around one idea. A sensitive action needs a case record with operational context. Role and permission checks run at the point of action. Approval paths cover higher-risk work. Numeric thresholds map to real operating rules. Denied attempts stay visible. The audit history keeps the authorisation decision close to the case it governed.
That is the practical difference between "someone had access" and "this case followed the right rule". The distinction matters for teams handling refunds, write-offs, reprocessing, exceptions, entitlement changes, or other case-linked actions. The system has to control what happens next and explain the decision later.