Outcomes and Integration
A HYPR Affirm verification flow ends with an outcome — the action that fires when the requester successfully passes the verification. Outcomes carry the verification's result into a downstream system so the verification drives a concrete change for the requester.
This page explains what outcomes are, the six outcome types HYPR Affirm supports, and where each one's identity-provider setup lives. For the per-outcome configuration in the workflow editor itself, see Verified Outcome and Unverified Outcome under Step Configuration.
How outcomes work
Every verification flow defines two terminal outcome states:
- Verified Outcome — what happens when the verification succeeds (all required steps pass, the approver attests). One outcome per workflow.
- Unverified Outcome — what happens when the verification fails or is denied. One outcome per workflow.
Outcomes are independent from the workflow's verification steps. The same verification step composition can drive different outcomes — one workflow may issue an Entra TAP, another may redirect to a custom URL, another may simply display the result on screen.
When an outcome carries a hand-off to an external identity provider, two things must be in place:
- The IdP integration is configured in HYPR Control Center. Each IdP (Entra ID, Okta) requires a one-time integration setup that gives HYPR the credentials and permissions to call the IdP's APIs.
- The workflow's outcome is set to the IdP-handoff option in the workflow editor. This is the per-workflow selection that says "when this flow succeeds, do this against the IdP."
For the integration setup steps, follow the corresponding integration page in HYPR Affirm Integrations. Each integration page covers the IdP-side prerequisites, the HYPR-side integration setup, and how to validate the configuration end-to-end.
Verified outcomes
| Outcome | What it does | IdP setup |
|---|---|---|
| Redirect to Device Manager to register a new login method | Sends the verified requester to HYPR Device Manager to register a new authentication device. | No external IdP — built into HYPR. Configuration is fully in the workflow editor. |
| Issue a Microsoft Entra ID Temporary Access Pass (TAP) | Issues an Entra TAP to the verified requester so they can register passwordless methods or complete first-time sign-in. | Entra ID Temporary Access Pass (TAP) for HYPR Affirm — TAP policy + Entra app registration |
| Issue a Microsoft Verified ID Verifiable Credential | Issues an Entra Verified ID credential to the verified requester. The credential lives in Microsoft Authenticator and can be reused as identity evidence in future flows. | Entra Verified ID for HYPR Affirm — credential definition + Entra app registration |
| Redirect to an Okta password reset page | Sends the verified requester to the Okta self-service password reset page. | Okta Password Reset for HYPR Affirm — Okta password-policy configuration |
| Redirect to URL | Sends the verified requester to a custom URL. Useful when the workflow is embedded in an external application that handles its own post-verification logic. | No external IdP — fully workflow-editor configured |
| Display verification result to the end user | Shows the verification result directly to the requester at the end of the flow. Optional Verification Confirmation ID display surfaces the flow ID for support follow-up. | No external IdP — fully workflow-editor configured |
For Entra-based outcomes (TAP, Verified ID), both share a common prerequisite: an Entra ID application registration with the right Microsoft Graph permissions. The shared setup is documented once at Entra ID Application Setup for HYPR Affirm. Each Entra outcome page links to the relevant section of the app setup.
Unverified outcomes
| Outcome | What it does |
|---|---|
| Redirect to URL | Sends the denied requester to a custom URL — for example, a help page, a contact-support form, or a fallback re-verification path. |
| Display verification result to the end user | Shows the denial directly to the requester. Optional Verification Confirmation ID display surfaces the flow ID for support follow-up. |
Unverified outcomes do not require external IdP setup — the denied requester is either redirected to a destination you control, or shown the result in-flow.
Choosing an outcome
| If the verification's purpose is… | Use this outcome |
|---|---|
| Onboarding a new employee who has no credentials yet | Entra TAP, Device Manager redirect, or Okta password reset (depending on directory) |
| Recovering an existing employee who's locked out | Entra TAP, Okta password reset |
| Step-up verification before a sensitive action (and the calling app handles the post-verification step) | Redirect to URL (with the verification flow ID propagated for correlation) |
| Helpdesk-initiated verification with no downstream system change | Display verification result to the end user |
| Issuing a portable, reusable identity credential | Entra Verified ID |
Related
- Verified Outcome — workflow-editor view of the six verified outcome types
- Unverified Outcome — workflow-editor view of the two unverified outcome types
- HYPR Affirm Integrations — index of all Affirm integrations (verification steps, outcomes, Helpdesk authentication, Relying Party sign-in)
- Verification Flows — conceptual fit between flows and outcomes