Sandbox, configuration and HaloPSA integration

This page covers three things an Identity Verification administrator uses after setup. The Sandbox rehearses a verification without bothering a real caller. The Configuration tab holds the organisation-wide settings. The HaloPSA integration decides what verification writes to tickets and lets HaloPSA start a verification.

Before you start: the Identity Verification module is on and you are signed in as an Administrator or an Identity Verification Admin. White-label partner accounts cannot open these screens. In the sidebar, select Analytics & Reporting → Identity Verification. The Sandbox and Configuration tabs sit in the tab strip under the statistics.

Rehearse a verification in the Sandbox

The simulation runs your real policy chain, your real verification log and your real ticket write-back. It does not call Microsoft and it does not contact the caller, so nothing is sent to anyone's phone or mailbox. Only the part that talks to Microsoft is replaced.

1. Open the Sandbox tab. The Lifecycle simulation tab inside it is selected.
2. In Set up the call, choose the Client. Its settings, its partner profile and your organisation's configuration decide the policy. Enter the Caller's email and the Caller's display name.
3. Optionally choose the Mode the technician asks for. The default, Inherit (let the policy chain decide), follows the policy. A technician's choice can raise assurance but never lower it, so choose one that would lower it and watch the trace say so.
4. Leave Halo ticket (optional) blank to keep the run inside QuantumOps. If you enter a ticket number, the rehearsal writes a real note and real custom field values to that HaloPSA ticket. See what is written to tickets.
5. Tick the checkboxes under Simulate the awkward cases to rehearse a caller with no directory object id, no Microsoft Authenticator registered or no Verified ID credential. Tick Ask for Face Check (Microsoft Entra Verified ID only) to rehearse Face Check.
6. Set the Challenge lifetime (seconds), from 15 to 900, and select Start verification.
7. Read How the policy resolved. It shows the tenant default, the partner profile, the client override, the effective floor and whether Face Check is on, then the chosen mode, the assurance and a numbered resolution trace. When nothing can reach the floor, the reason appears in red.
8. Check What the technician sees. For Authenticator step-up it shows the safety notice, the masked address and Re-send to the address on file. For Verified ID it shows where the QR code would be.
9. In Drive the caller's side, select a button to play the caller: Caller opened it, Caller approved, Caller denied, Someone else completed it, Weak factor only (SMS), Revoked credential, Provider error, Let it time out or Technician cancels. Each one feeds the real adjudication a single callback, and the adjudication decides the outcome.
10. Read Adjudicated outcome. It reads back the saved result: the outcome, the proven subject, the mode, the assurance, the ticket and the error code, with the Ticket note that would be written and a timeline.
11. Select New run to start again.

Two sequences are worth trying. Cancel first and then approve: the late completion is recorded as Late after cancel and is never written to the ticket. Approve twice: the second callback is recorded and not adjudicated again.

Rehearsals appear in the verification log with the source SandboxTest. They take their place in the tamper-evident chain, so they are kept, not deleted. They never appear on a technician's validity badge, and they do not use up a real caller's hourly allowance.

Test a live Verified ID credential

The Live credential test (Mode A) tab calls Microsoft for real. Use it once the simulation looks right, to prove that the Azure side of Verified ID works.

1. Enter the Test email address and a Display name, then select Issue test credential.
2. Scan the QR code with Microsoft Authenticator, or select Open in Authenticator or Copy link. The status line shows when the credential arrives. Use the refresh button to check.
3. Under Present it, optionally tick Ask for Face Check, then select Start verification. Scan the second QR code. The page shows Identity verified. when it works.
4. Under Clean up, select Revoke test credential. The verification log rows stay, because removing one would make the chain read as tampered.

Run one real verification before you rely on it

The sandbox and the preflight checks prove the plumbing. Only a real run proves the experience. Before technicians depend on the feature, pick a client with identity verification on and a colleague you can phone. Start a verification from the panel as described in Verifying a caller, and confirm the colleague receives the request and finishes it.

Review the Configuration tab

The Configuration tab holds the organisation-wide settings in cards. The banner above the tabs shows Identity Verification Active or Identity Verification Paused, and its switch pauses and resumes Identity Verification for your organisation.

Set the HaloPSA fields

1. In Halo Integration, switch Halo Integration on (Update Halo tickets with verification results). It starts on.
2. Enter the id of the HaloPSA custom field for each value you want stored: Status Field ID, Timestamp Field ID, Method Field ID and Confidence Field ID. A field you leave empty is not written.
3. Select the check mark next to Status Field ID. It saves all four ids and the screen confirms Halo field IDs saved.

Set the mail profile for campaigns

1. In Email (SMTP) Settings, fill in SMTP Host, Port, Use SSL/TLS, Username, From Address and From Display Name. The card says these settings are the default for all campaigns.
2. Select Save SMTP Settings. The button is disabled until a host is entered. The screen confirms SMTP settings saved successfully.
3. Select Test Connection. It reports SMTP connection settings appear valid. Send a test email to verify fully. The test checks the values you entered and does not send a test message, so confirm delivery with a campaign to a mailbox you control.

A campaign sends through this profile while Use Global SMTP Settings is ticked, which is the default, and otherwise uses the profile entered for that campaign. A mail server that needs a username and password must be entered for each campaign instead. Issuance campaigns explain how the profile is used.

Change the Azure connection

1. In Azure Configuration, the tenant id, the application id and the client secret are masked. Select Edit to change them.
2. Read the warning: Changing these values may break your Identity Verification integration. Change Azure Tenant ID, Application (Client) ID or DID Authority as needed. Leave Client Secret blank to keep the existing secret. Enter a value only when you want to replace it.
3. To check the values, enter the secret and select Test Connection. If the secret field is empty the screen asks you to enter it first.
4. Select Save Azure Settings. The screen confirms Azure configuration updated successfully. Select Cancel to leave without saving.

Reset an incomplete setup

The Reset button is in the Setup Incomplete banner above the tabs, not on the Configuration tab. The banner appears when setup was not completed, and it offers Complete Setup and Reset. Reset asks you to confirm in a browser dialog. It deactivates the configuration and does not delete it. Identity Verification is then off for your organisation until you finish the setup wizard again. The wizard opens with your current values filled in, and completing it reactivates the same configuration. Client settings, credentials, campaigns and the verification log are all kept.

See what is written to HaloPSA tickets

When the Halo Integration switch is on and a verification is linked to a HaloPSA ticket, QuantumOps writes the following. The switch controls the outcome note and the custom fields. See also What QuantumOps writes into HaloPSA.

A completion that arrives after the technician cancelled is never written to a ticket. A sandbox run against a real ticket number writes the same things, with a banner reading SIMULATION — NOTHING WAS PROVEN on the note and a matching prefix in the method field, so nobody reads it as a real verification.

The notes are posted as notes that HaloPSA hides from the end user, and their outcome reads Interactive Guide Action. When a client's Verified ID request is delivered by e-mail, HaloPSA sends it to the caller as an e-mail action on the ticket, which the caller can see. Check your HaloPSA visibility rules for who can read these actions. A client can also be set not to post its verifications to its tickets. The Identity Verification screens do not have a field for that setting, so see Getting help if you need it changed.

Start a verification from a HaloPSA webhook

A webhook lets HaloPSA ask QuantumOps to start a verification for a ticket. You set the webhook up in HaloPSA. Its address and signature are the parts that come from QuantumOps.

1. In HaloPSA, create a webhook that sends a POST to /api/verifiedid/halo/webhook on your QuantumOps address.
2. Include the ticket's id as ticketId, its type as ticketTypeId and the caller's e-mail address as userEmail in the JSON body. The e-mail address is only a hint. It must match the contact on the ticket.
3. Sign every request with the instance's webhook secret and send the signature in the Halo-Signature header. TechPulse sets up the secret for your instance, so ask them for it or to confirm it is in place. A request with no signature, a wrong signature or no secret on the instance is refused and nothing starts.

A verification starts only when all of these are true:

• The ticket's client has identity verification on.
• The ticket's type is one the client requires verification for. The Identity Verification screens do not have a field for the list of ticket types, so see Getting help to have it set.
• The caller resolves to a single account in the client's directory.
• The caller holds an active Verified ID credential. If not, nothing starts and the reply suggests issuing one, as described in Issuing credentials and supervised overrides.

A client that verifies callers only with Authenticator step-up has no need for credentials, so its callers normally hold none and a webhook does not start a verification for them. Technicians start those from the panel or the extension, as described in Verifying a caller.

A webhook never reuses an earlier verification, so every start sends a new challenge. The method is the one the client's policy picks, and the result is written back to the ticket like any other verification. When nothing starts, the reply to HaloPSA says why, for example that the ticket type does not require verification.

Related

• Identity verification is the overview of the two modes and the assurance floor.
• Setting up identity verification covers the setup wizard and the checks before go-live.
• What QuantumOps writes into HaloPSA lists everything QuantumOps can add to a ticket.
• Verifying a caller is the technician's side of a real verification.