Authentication
Part of Human approvals in technical workflows
Recording who approved a sensitive action
Record the actual approval responder, the terms reviewed and the separately confirmed result of the sensitive action.
Record the authenticated person who responded, the precise request they answered and what happened after the decision.
The assigned person is who was asked. That field alone does not establish who responded, what terms were reviewed or whether the sensitive action succeeded.
For a proposed supplier-payment change, an operator should find the change presented and the person authorised to decide. They should also find the actual responder, the accepted decision and the resulting payment-record change.
Link the request, decision and effect
Keep these as distinct, linked events:
| Event | Useful fields |
|---|---|
| Request issued | Approval ID, business record ID, reviewed version or terms, proposed action, assignee, issue time and deadline |
| Decision accepted | Approval ID, authenticated responder ID, outcome, acceptance time, response channel and applicable reassignment reference |
| Action attempted or confirmed | Approval ID, operation, attempt reference, destination result ID when known, outcome and time |
Use a stable account ID when the identity service supplies one. Retain the identity value from the authenticated decision path and the rule that allowed that person to respond. A display name or email may help a reader but may change. If a delegate responded, keep the original assignment and record the authority change separately.
The standard approvals connector documents that its AssignedTo field accepts email addresses, user principal names and Microsoft Entra ID user IDs. These identify the assigned recipient, not necessarily the person who responded. Check the selected action’s actual output before designing a business audit record around the identity and response fields it exposes.
Identify the terms reviewed
Store a record version, immutable snapshot reference or selected material fields that identify the proposal shown to the approver. “Approved request 42” is ambiguous if request 42 later changes. The audit trail should show whether the decision still applied when the action was attempted.
An approver’s comment may explain a decision but should not replace its explicit outcome. The response time is also distinct from the destination action time. If a write is rejected or its response is lost, keep approved, action confirmed and action outcome unknown separate.
Audit Trail Data Requirements for Compliance
- Must track
- Approved terms version or snapshot
- Must track
- Actual responder identity (not just assignee)
- Must track
- Action outcome and timing separately from decision
Protect the evidence
OWASP’s Logging Cheat Sheet notes that application logging can support audit trails and advises using the intended purpose to guide how much is logged. Use safe references and summaries where they answer the audit question without copying an entire sensitive record.
Set access and retention according to the organisation’s actual requirements. This record design supports operational accountability; it does not establish compliance with a particular law, retention period or audit standard.
