Outcomes and Integration
A HYPR Affirm verification flow ends with an outcome: the action that fires when the verification ends. The Verified Outcome fires when the requester is approved, and the Unverified Outcome fires when the verification fails or is denied. A verified outcome can carry the 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: the approver approves, or HYPR (automated approval) approves because every step passed. One outcome per workflow.
- Unverified Outcome: what happens when the verification fails or is denied. One outcome per workflow.
Outcomes are independent of the workflow's verification steps. The same set of verification steps can drive different outcomes. For example, one workflow can issue an Entra TAP, another can redirect to a custom URL and a third can 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
The following table lists the six verified outcome types and the IdP setup each one needs.
| 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. You configure it entirely 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. The pass lasts 60 to 480 minutes; for a lifetime outside that range, an Outcome API Call customization can create the pass directly. | Entra ID Temporary Access Pass (TAP) for HYPR Affirm: TAP policy and 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 and 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; configured entirely in the workflow editor |
| Display verification result to the end user | Shows the verification result directly to the requester at the end of the flow. The optional Verification Confirmation ID display shows a six-digit verification ID for help desk follow-up. | No external IdP; configured entirely in the workflow editor |
The Entra-based outcomes (TAP and Verified ID) share a common prerequisite: an Entra ID application registration with the right Microsoft Graph permissions. Entra ID Application Setup for HYPR Affirm documents this shared setup, and each Entra outcome page links to the relevant section of it.
Unverified Outcomes
The following table lists the two unverified outcome types.
| 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. The optional Verification Confirmation ID display shows a six-digit verification ID for help desk follow-up. |
Unverified outcomes need no external IdP setup. Affirm either redirects the denied requester to a destination you control or shows the result in the flow.
The Unverified Outcome applies at the end of the flow. A step whose own failure outcome is Deny Verification or Redirect to URL ends the flow at that step instead; see Injectable Outcomes and Retry Limits.
Choosing an Outcome
Use the following table to match the purpose of a verification to an outcome.
| If the verification's purpose is… | Use this outcome |
|---|---|
| Employee onboarding, when the requester has no credentials yet | Entra TAP, Device Manager redirect or Okta password reset (depending on directory) |
| Account recovery for a locked-out employee | Entra TAP or 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 and Relying Party sign-in)
- Verification Flows: conceptual fit between flows and outcomes