Sign-in
- Microsoft Entra
- Work-account authentication; Microsoft passwords remain with Microsoft.
- Evidize
- Verifies the returned identity and the approved user’s explicit identity binding.
For IT and security reviewers
Use Microsoft sign-in. Control access to hiring records.
Let approved employees authenticate with their Microsoft work accounts, then apply Evidize’s organization and role controls to product access.
Setup guidance is available below. Self-service onboarding is in controlled rollout; confirm availability before scheduling a change.
- 01 · Microsoft EntraAuthenticate the work account
Apply your assigned, configured Microsoft sign-in policies.
- 02 · EvidizeCheck the approved user and role
Validate the organization, linked identity, and product access.
- 03 · Hiring workspaceOpen the authorized records
Keep access within the signed-in person’s permissions.
Separate controls, clear owners
Which system controls what?
Microsoft verifies the employee’s work identity. Evidize then decides whether that linked user can access the organization and requested product records.
| Control | Microsoft Entra | Evidize |
|---|---|---|
| Sign-in | Work-account authentication; Microsoft passwords remain with Microsoft. | Verifies the returned identity and the approved user’s explicit identity binding. |
| MFA and access policies | MFA, Conditional Access, and application assignment where licensed, configured, and assigned. | Does not configure the customer’s Microsoft policies. Enforces its own user, organization, role, and session checks. |
| Product permissions | Microsoft administrator status does not assign an Evidize administrator role. | Organization administrators provision approved users and assign Evidize roles. |
| Integration access | Identity-only consent for employee SSO. | Outlook scheduling and candidate check-in are separate workflows. |
MFA and access policies
- Microsoft Entra
- MFA, Conditional Access, and application assignment where licensed, configured, and assigned.
- Evidize
- Does not configure the customer’s Microsoft policies. Enforces its own user, organization, role, and session checks.
Product permissions
- Microsoft Entra
- Microsoft administrator status does not assign an Evidize administrator role.
- Evidize
- Organization administrators provision approved users and assign Evidize roles.
Integration access
- Microsoft Entra
- Identity-only consent for employee SSO.
- Evidize
- Outlook scheduling and candidate check-in are separate workflows.
Pilot before enforcement
Choose your sign-in approach and prepare the people who own it.
Confirm onboarding availability with Evidize. Enabled organizations can retain permitted password access alongside Microsoft SSO or require Microsoft SSO after a successful administrator pilot.
01 · Prepare
Identify both administrators
You need an active Evidize organization administrator and a supported Microsoft tenant administrator. Confirm the tenant, approved users, product roles, and recovery contact.
02 · Link
Provision approved users
Verify the Microsoft administrator, review identity-only consent, and link existing members using Tenant ID and user Object ID. Matching email addresses are insufficient.
03 · Test
Pilot, then activate
Test the administrator’s own linked Microsoft sign-in and an approved standard user. Require SSO only after mappings, access, and recovery are ready.
Rollout boundaries: one Microsoft tenant per Evidize organization and one Evidize organization per
tenant in each environment. Personal Microsoft accounts and automatic account creation are not supported.
User lifecycle
Manage access when people join, change roles, and leave.
Joining
Provision the Evidize account, assign its product role, and link the Microsoft identity. Assign the enterprise application in Microsoft if your tenant requires it.
Changing roles
Review the person’s Evidize role and responsibilities. An Entra group change does not automatically update product permissions.
Leaving
Deactivate the person in Evidize and remove or disable Microsoft access. Microsoft and Evidize session lifetimes are separate.
Plan explicit lifecycle management. SSO does not include general SCIM provisioning, group-to-role
synchronization, or just-in-time user creation. Revoking Microsoft access alone is not a promise of instant universal
logout.
Review without a sales call
Share the details with your IT and privacy reviewers.
SSO setup and recovery
Administrator requirements, identity mapping, pilot steps, enforcement, and recovery responsibilities.
Open the setup guideMicrosoft and candidate privacy
Review Microsoft integration access and the separate candidate-data and check-in boundaries.
Read the privacy detailsHiring records and reporting
Understand the supported evidence, audit activity, and authorized reporting workflow.
Explore governanceBefore you decide
Resolve the access questions before rollout.
Can we require Microsoft sign-in?
Yes. Customer self-service onboarding is in controlled rollout. Confirm availability first. An enabled organization administrator provisions and links approved users, tests their own Microsoft sign-in, and can activate SSO with or without requiring it. Complete the pilot and arrange recovery before enforcement.
Does consent automatically create Evidize accounts?
No. Users must exist in Evidize and be explicitly linked to the correct Microsoft Tenant ID and user Object ID. Microsoft consent or application assignment does not create product accounts or assign product roles. General SCIM, group-to-role synchronization, and just-in-time account creation are not supported.
Does Microsoft sign-in give Evidize access to the mailbox?
No. Employee sign-in uses identity information. The Outlook appointment workflow is a separate integration. Candidate check-in is also separate from employee SSO.
Will revoking a Microsoft session immediately end every Evidize session?
Microsoft and Evidize have separate session lifetimes. Microsoft revocation or policy changes do not necessarily end already-issued Evidize sessions immediately. Deactivate the user in Evidize as well as removing Microsoft access; an in-flight request may complete before revocation takes effect.
Map your requirements
Review the access model with your technical team.
Walk through Microsoft authentication, Evidize roles, provisioning, session boundaries, and the rollout path. Share your requirements if useful; a prepared example is available.