Put human judgment where the decision matters.
Let policy identify the actions that need a person. Give the reviewer the request, the reason for escalation, and the consequence of their decision in Decision Desk.
The action to govern
Release a payment
An approval should change what happens next.
A payment instruction creates a real obligation. When the amount or circumstances cross your policy threshold, the action needs a decision from an accountable reviewer. KLA connects that decision to the governed execution path.
A payment reaches its approval threshold.
The agent prepares the instruction. Policy requires a human decision before it can proceed. In Decision Desk, the reviewer can inspect the request and its supporting context, then approve or reject it.
€420,000Supplier payment
- Requested by
- Treasury payments agent
- Operation
- Submit payment
- Supporting document
- Supplier invoice
Approval threshold€250,000
Treasury reviewer
Required approval roleReview payment
The amount triggers the payment-approval rule. The payment stays on hold while treasury reviews the request.
Policy outcome: require approval
Agree who can decide, and what approval permits.
Approval design starts with the business rule. Configure the trigger, reviewer permissions, and the next action together so that each decision has a clear scope.
Process owner
When to pause
Identify the amount, data sensitivity, or case condition that requires review.
Control owner
Who may decide
Set the reviewer permissions and separation of duties required for this action.
Operations team
What happens next
Define the approved path, rejection outcome, and handling for an expired or failed request.
Execution Lineage
Follow the decision through to its outcome.
A recorded approval and a completed action answer different questions. Review both, with the policy and supporting context that connect them.
Explore Lineage Explorer- Why did this need review?
- The policy decision and the request that triggered it.
- Who made the decision?
- The reviewer identity, decision, timestamp, and recorded reason.
- Did the action complete?
- The execution result, including a failure that still needs attention.
Define what a successful evaluation must show.
Bring one workflow, the action you need to control, and the people who own its rules. Agree the integration scope and acceptance criteria with KLA.
Discuss your workflow- A request below the review threshold follows the configured policy.
- A request above the threshold stays paused until an authorized decision.
- Rejection, expiry, and execution failure each have an inspectable outcome.
Does every action need human approval?
No. Policy selects which actions require approval. Other configured outcomes are allow, warn, and block. Choose thresholds and conditions for the specific workflow.
Does approval mean the action succeeded?
Approval authorizes the configured next step. The downstream action can still fail. KLA records the decision and execution state separately so operators can see what requires follow-up.
Can we keep our existing approval responsibilities?
Use your existing control owners and reviewer roles when designing the Process. Validate permissions, separation of duties, and escalation behavior as part of the evaluation.