Identity events: the audit log
Every identity transition in your workspace is recorded as an immutable row in the Identity events audit log. This is the evidentiary record an auditor will ask for, and the troubleshooting surface you use when a verification does not go the way you expected.
Open Settings, then Verification, then the Posture tab, and follow View identity events for this workspace. Events from every channel appear here: voice, email, chat and WhatsApp.
Reading the table
Section titled “Reading the table”Each row has:
- Timestamp: when the event fired, to the second.
- Event: the event type, listed below.
- Contact: the contact the event is bound to, when known.
- Conversation: the conversation the event belongs to.
- Prompt version: the version of the verification prompt at the time of the event. Useful when comparing behaviour across releases.
Clicking a row expands its detail: the result recorded with the event, the factor category and type, the scope, the audit reference, the prompt version and the event id. A result never contains the customer’s answer or the identifier a verification compared.
Event types
Section titled “Event types”| Event | What it means |
|---|---|
| Factor added | A proof was accepted, such as a correct answer or a press of Confirm it’s me on the page an email link opens. |
| Factor failed | An attempt produced an incorrect answer or a tampered token, or the customer pressed Confirm it’s me on the page an email link opens after the verification in that conversation had been declined, so it verified nothing (result not minted: approval_declined_earlier). |
| Email link sent | An email link was started for the record the customer asked about. oHallo sends an email link only to the email address on that record. |
| KBV question asked | The assistant asked a question drawn from your own records. |
| KBV question passed | The answer matched. |
| KBV question failed | The answer did not match. |
| Identity locked (per-call) | The wrong-answer allowance was used up, so the assistant stopped for this conversation. |
| Identity locked (24h) | The failed-verification limit was reached, so this customer is locked out until the lockout duration elapses. |
| ANI blocked | One number has attempted verification under too many different identities, so further attempts from it are blocked. |
| Assurance level reached | The proofs held brought the customer to identified or high-assurance. |
| Verification not configured | A tool needed a verified customer and no method on the conversation could verify them for it. The result level_unreachable means the request needs a level no method on the conversation reaches, so a teammate takes it over. |
| Verification-agent context used | oHallo read one of your tools to formulate a question. This read is bound to that specific customer and tool. |
| Operator joined the call | An operator joined a live call through the audio bridge, recorded with the assurance level at the moment they joined. |
| eid_approval_requested | A verification prompt was sent to the customer’s own MitID or BankID app. |
| eid_link_issued | A secure verification link was issued for the customer to open at their own timing. |
| eid_approval_granted | The customer approved and the scheme’s answer verified them. |
| eid_approval_denied | The customer declined in their app, or a completed verification did not match the record on file, or, after a verification link, was a login with a business identity, or the customer cancelled the login on the scheme’s own login page. After a verification link, the result says why. A decline or a verification that did not match ends app requests and verification links in that conversation. A cancelled login ends nothing: the customer can open the same link again. |
| eid_approval_expired | The scheme’s window closed without an answer, or the verification was not completed, or, after a verification link, the scheme ended its login without a result. The result says which. |
An eID event names the scheme in its audit reference, such as eid:dk_mitid.
Results on eID events
Section titled “Results on eID events”| Result | Event | What it means |
|---|---|---|
approval requested via <provider> | eid_approval_requested | Names the provider the prompt was sent through, such as approval requested via idura. |
link issued via <provider> | eid_link_issued | Names the provider the link was issued for, such as link issued via idura. |
subject_mismatch | eid_approval_denied | After a verification link, the scheme proved a different person than the record names. |
identifier_claim_absent | eid_approval_denied | After a verification link, the scheme’s answer did not carry the identifier the record is compared on. |
business_identity_refused | eid_approval_denied | After a verification link, the customer logged in at the scheme with a business identity, such as MitID Erhverv, so the verification did not verify them. |
approved at the scheme; not completed: record_link_write_failed | eid_approval_expired | The scheme approved the customer, and the verification was not completed. The customer is asked to verify again. |
approved at the scheme; not completed: approval_declined_earlier | eid_approval_expired | The scheme approved after the verification in that conversation had been declined, so nothing was verified. |
provider_error:access_denied | eid_approval_denied | After a verification link, the customer cancelled the login on the scheme’s own login page. The link stays usable until it expires, and a later row for the same link can follow. |
provider_error:<word> | eid_approval_expired | After a verification link, the scheme ended its login without a result. <word> is the error code the provider returned, such as invalid_scope, or other for a code outside the OAuth and OpenID Connect lists. The link stays usable until it expires, and a later row for the same link can follow. |
A cancelled or ended login on one link is recorded at most once in 15 minutes.
Filtering
Section titled “Filtering”The top of the page has one control: an event type dropdown that narrows the list to a single type.
To follow one customer’s experience, open the conversation, click into a turn, and read the Identity events section on the Inspect panel. The workspace list is for questions that cross conversations, such as how many lockouts happened last week.
The outcome of an eID verification is not tied to a turn, so it is listed here rather than under a turn.
Retention
Section titled “Retention”Identity events are kept for 24 months by default. The current period for your workspace is shown on the Posture tab in the Verification log row. A daily sweep deletes rows past the cutoff.
For a right-to-erasure request under GDPR Art. 17, contact your oHallo account team. See Data retention and erasure.