Zoho People and Microsoft Azure AD Integration: Single Sign-On and Employee Provisioning

Organisations running Zoho People for HR management and Microsoft Azure AD (now Microsoft Entra ID) for identity frequently maintain two separate user directories. New hires get created manually in both systems, department changes require duplicate updates, and offboarding leaves orphan accounts that pose security risks. A proper Zoho People Azure AD integration eliminates this gap through SAML-based single sign-on and automated user provisioning, giving IT teams one source of truth for employee identity. This guide walks through the complete technical setup: SAML SSO configuration, SCIM-based provisioning, attribute mapping for departments and roles, auto-deprovisioning on termination, multi-entity handling, and contractor access patterns. Whether you manage 50 employees or 5,000 across multiple subsidiaries, the steps here apply to production environments.

Why Integrate Zoho People with Azure AD

Most mid-market companies already use Azure AD (Entra ID) as their central identity provider for Microsoft 365, VPN access, and SaaS applications. Adding Zoho People to that identity fabric brings three measurable benefits.

First, employees get single sign-on access to Zoho People through their existing Microsoft credentials. No separate password to remember, no password reset tickets for IT. The average organisation sees a 40-60% reduction in password-related support tickets after enabling SSO across their SaaS portfolio.

Second, automated provisioning means new hires appear in Zoho People the moment their Azure AD account is created. Department, manager, job title, and location attributes sync automatically. When someone transfers teams or changes roles, those updates flow through without manual HR data entry.

Third, deprovisioning closes the security loop. When an employee’s Azure AD account is disabled or deleted, their Zoho People access is revoked automatically. No more ex-employee accounts sitting active in your HR system weeks after termination. For organisations subject to SOC 2, ISO 27001, or similar compliance frameworks, this automated lifecycle management is often a requirement, not an option.

Zoho People Azure AD Integration: SAML SSO Configuration

SAML 2.0 is the protocol that connects Azure AD as the Identity Provider (IdP) to Zoho People as the Service Provider (SP). The setup involves configuration in both the Azure portal and Zoho Accounts.

Step 1: Register Zoho People in Azure AD

Open the Microsoft Entra admin center, navigate to Enterprise Applications, and click New Application. Search for “Zoho” in the gallery, or create a custom application if you need a dedicated entry for Zoho People specifically. Name it clearly, for example “Zoho People Production”, so it is distinguishable from other Zoho apps you may add later.

Once created, go to the application’s Single sign-on section and select SAML as the method. Azure AD will display the Basic SAML Configuration panel where you will need the Entity ID and Reply URL from Zoho.

Step 2: Configure SAML in Zoho Accounts

Sign in to Zoho Accounts as an organisation administrator. Navigate to Security, then SAML Authentication, and click Setup Now. Select the Zoho service as “People” (or “All Services” if you want SSO across your entire Zoho suite). Enter the following details from your Azure AD application:

• Sign-In URL: the Login URL from Azure AD’s SAML configuration
• Logout URL: the Logout URL from Azure AD
• Signing Certificate: upload the Base64 certificate downloaded from the Azure AD SAML Signing Certificate section

After saving, Zoho Accounts generates a metadata XML file. Download this file.

Step 3: Upload Metadata to Azure AD

Back in Azure AD, click “Upload metadata file” in the Basic SAML Configuration panel and upload the XML from Zoho. The Entity ID and Reply URL fields populate automatically. Verify that the Entity ID matches your Zoho domain (zoho.com or zoho.in depending on your data centre). Save the configuration.

Step 4: User Assignment and Testing

Navigate to Users and Groups in the enterprise application and assign the users or groups who should access Zoho People through SSO. Start with a test user. Open an incognito browser, navigate to people.zoho.com, and select “Sign in with SAML”. The browser should redirect to the Microsoft login page, authenticate, and return to Zoho People. Both SP-initiated (starting from Zoho) and IdP-initiated (starting from the Azure My Apps portal) flows should work after configuration.

SCIM-Based User Provisioning Setup

SSO handles authentication, but provisioning handles the user lifecycle: create, update, and delete. For Zoho People, the provisioning path depends on your Zoho subscription tier.

Provisioning Through Zoho One or Zoho Directory

If your organisation uses Zoho One (which includes Zoho People), Microsoft provides a native SCIM provisioning connector in the Azure AD app gallery. This connector uses the System for Cross-domain Identity Management (SCIM) 2.0 protocol to automatically sync users and groups from Azure AD into Zoho. The Microsoft Entra provisioning service handles the sync cycle approximately every 40 minutes after the initial full sync.

To configure this, go to the Zoho enterprise application in Azure AD, select Provisioning, set the mode to Automatic, and enter the Zoho SCIM endpoint URL and API token. The SCIM endpoint is available from your Zoho Directory admin panel under Provisioning settings. The API token authenticates Azure AD’s provisioning requests.

Provisioning for Standalone Zoho People

If you run Zoho People as a standalone product without Zoho One, native SCIM provisioning is not directly available in the Azure AD gallery. In this scenario, you have three options:

• Use the Zoho People Office 365 sync feature (Settings > Integrations > Office 365) which provides basic user sync from Azure AD
• Deploy a third-party provisioning bridge such as Aquera or RoboMQ Hire2Retire, which connect Zoho People’s API to Azure AD’s provisioning engine
• Build a custom Azure Function that reads from Azure AD’s provisioning API and writes to the Zoho People REST API, using Azure Key Vault for credential storage

For most organisations, the Office 365 sync feature covers the essentials. It imports users from your Azure AD tenant into Zoho People, mapping email, name, and department. For full lifecycle automation including deprovisioning, the third-party bridges or custom function approach is more complete.

Attribute Mapping: Department, Role, and Manager

Getting users into Zoho People is only half the job. The real value comes from mapping Azure AD attributes to the correct Zoho People fields so employee records are complete on day one. Here is a standard mapping table for the most common attributes:

A few implementation notes on attribute mapping. Department names must match exactly between Azure AD and Zoho People. If Azure AD has “Engineering” but Zoho People expects “Product Engineering”, the sync will either fail or create a mismatched record. Audit both systems and standardise naming before enabling provisioning. The same applies to location and designation fields.

For the manager attribute, the manager’s Zoho People account must exist before the direct report is provisioned. If you are doing a bulk initial sync, process managers first, then their reports. Most provisioning engines handle this through dependency ordering, but verify this with a test batch.

Role mapping requires special attention. Azure AD application roles (configured in the enterprise app’s App Roles section) can map to Zoho People permission roles. This determines whether a provisioned user gets Employee, Manager, or Admin access in Zoho People’s HR management console. Configure this mapping in the provisioning attribute mapping section to avoid granting excessive permissions.

Auto-Deprovisioning on Employee Offboarding

The security case for integration rests heavily on what happens when someone leaves. Without automation, the typical offboarding gap between disabling an Azure AD account and removing Zoho People access is 3-14 days, depending on how quickly HR and IT coordinate. Automated deprovisioning closes this to minutes.

How Deprovisioning Works

When a user account is disabled or deleted in Azure AD, the provisioning service detects the change during its next sync cycle (within 40 minutes for SCIM-based provisioning). The action taken in Zoho People depends on your deprovisioning configuration:

• Soft delete: the Zoho People account is deactivated but retained, preserving the employee’s historical data for compliance and payroll compliance purposes
• Hard delete: the account is removed entirely from Zoho People (not recommended for HR systems where historical records matter)

For most organisations, soft delete is the correct approach. The employee’s leave records, performance reviews, and documents remain intact in Zoho People for audit trails, but they can no longer log in or access any data. Their SSO session is also invalidated immediately once Azure AD disables the account, regardless of the provisioning cycle timing.

Handling Deprovisioning Edge Cases

Employees on long-term leave present a common edge case. Their Azure AD accounts may be disabled for security during extended absence, but they should not be fully deprovisioned from Zoho People. Use a scoping filter in your provisioning configuration to exclude users with specific attributes (for example, an extensionAttribute marking them as “on leave”) from deprovisioning actions.

Another edge case is employee rehires. When a previously terminated employee returns, the provisioning engine may attempt to create a new account rather than reactivate the old one. Configure your matching rules to use Employee ID as the primary matching attribute rather than email, since email addresses may be recycled. This ensures the rehired employee’s historical records in Zoho People are linked correctly.

Multi-Entity and Subsidiary Handling

Organisations with multiple legal entities, subsidiaries, or business units need additional configuration to ensure employees land in the correct Zoho People entity.

In Azure AD, the companyName attribute typically identifies which entity an employee belongs to. Map this to Zoho People’s Company field. If your Zoho People instance uses separate departments per entity (for example, “ACME Corp – Engineering” vs “ACME UK – Engineering”), create a transformation rule in the provisioning attribute mapping that concatenates the company name with the department.

For organisations using Zoho People’s multi-company module, each legal entity has its own set of leave policies, payroll configurations, and approval workflows. The provisioning mapping must include the entity identifier so that new employees are assigned to the correct company from the start. Without this, employees may inherit the wrong leave policies or report to the wrong approval chain.

For Zoho services spanning multiple products, consider using Zoho Directory as the central provisioning target. Azure AD provisions into Zoho Directory, which then distributes users across Zoho People, Zoho CRM, Zoho Projects, and other apps based on directory rules. This hub-and-spoke model avoids configuring separate provisioning connectors for each Zoho application.

Contractor and External User Access

Contractors, consultants, and temporary workers need Zoho People access for time tracking and project management but should not have the same identity lifecycle as full-time employees.

In Azure AD, external users (B2B guests) have a different account type than members. Create a separate enterprise application or a scoping group for contractors. This allows you to:

• Apply a different attribute mapping that sets the Zoho People employment type to “Contractor” automatically
• Set an expiry date on their Azure AD account so access is revoked automatically when their contract ends
• Exclude them from full HR workflows like performance reviews and leave management
• Apply Conditional Access policies requiring multi-factor authentication for contractor SSO sessions

For contractors who do not have Azure AD accounts at all (for example, freelancers using personal email), Zoho People’s native invitation flow is the better path. They receive a Zoho-native login rather than SSO, and their access is managed directly within Zoho People’s user administration.

Testing the SSO and Provisioning Flow

Before rolling the integration out to your entire organisation, run a structured test with 5-10 users across different departments and roles. Here is a checklist that covers the critical paths:

1. SP-initiated SSO: navigate to people.zoho.com, click “Sign in with SAML”, verify redirect to Microsoft login and successful return
2. IdP-initiated SSO: go to myapps.microsoft.com, click the Zoho People tile, verify direct access without additional login
3. New user provisioning: create a test user in Azure AD with department, title, and manager attributes, then verify the account appears in Zoho People within one sync cycle
4. Attribute update: change the test user’s department in Azure AD and verify it updates in Zoho People
5. Deprovisioning: disable the test user in Azure AD and verify their Zoho People account is deactivated
6. Reactivation: re-enable the test user and verify access is restored with historical data intact
7. Conditional Access: if applicable, test that MFA is required and Conditional Access policies are enforced during SSO

Document any attribute mismatches during testing. The most common issues are department name mismatches, missing manager accounts (manager must be provisioned before direct reports), and timezone or date format differences between Azure AD and Zoho People. Resolve these before scaling to the full user population.

For organisations using Zoho Flow, you can build an automation that monitors provisioning errors and sends alerts to a Slack channel or email group. The Zoho People webhook trigger fires on user creation events, which you can use to verify successful provisioning and flag any records with missing attributes.

For a full overview of all available options, explore our complete guide to Zoho integrations.

A well-configured Zoho People and Azure AD integration removes the manual work from employee lifecycle management while closing security gaps that audit teams flag. Start with SAML SSO to give employees single-click access, then layer on automated provisioning and deprovisioning to keep both systems in sync. Test thoroughly with a small group before scaling, and standardise your attribute naming across both systems to avoid sync mismatches. For multi-entity organisations, use Zoho Directory as the provisioning hub to distribute users across your entire Zoho suite from a single Azure AD configuration.