Single Sign-On with Microsoft Entra ID

Without single sign-on, every Pactly user is one more password your organization has to provision, reset, and revoke by hand. When someone leaves, their Pactly account lingers until an admin remembers to deactivate it.

Single sign-on (SSO) hands authentication to Microsoft Entra ID (formerly Azure AD). Users sign in with their existing Microsoft credentials, accounts can be created and removed automatically, and one identity covers both the Pactly web app and the Pactly Word Plugin.

SSO settings live in the left menu under Account settings → SSO. The section is available to admins on accounts where the integrations capability is enabled.

You also need:

• Verified, locked domains. SSO applies to email domains your company has verified and locked in Account settings → Company. Verify and lock the relevant domains first, or only existing users will be able to sign in with SSO. See Verify and lock your domains.
• Access to your Azure portal, if you plan to use your own app registration (most enterprise setups do).

1. Go to Account settings → SSO.
2. Switch the toggle from SSO Disabled to SSO Enabled.
3. In Display Name, enter the text users will see on the sign-in button, for example Microsoft or your company name.
4. Click Save.

Once SSO is enabled, Pactly shows whether your verified domains are covered. If no domains are locked yet, you’ll see a reminder that only existing users can use SSO until domains are verified and locked.

Pactly connects to Entra ID through an Azure app registration. Under App Registration, you choose which one.

The simpler path. You point Pactly at your tenant and consent to Pactly’s pre-built app. No secret to manage.

1. Leave the toggle on Use Pactly’s multi-tenant app.
2. Enter your Tenant ID (the Directory (tenant) ID from the Azure portal).
3. Click Save.

If admin consent for Pactly’s app has not yet been granted in your tenant, contact support, who will provide the consent link.

Full control. You register your own app in Azure and supply its credentials. Required when your security policy mandates a self-managed app registration.

1. Switch the toggle to Use custom Azure AD app.
2. Enter the Tenant ID and Client ID from your Azure app registration.
3. Enter the Client Secret value you generated in Azure.
4. Optionally set the Client Secret Expiry Date so Pactly can warn you before it lapses (see below).
5. Click Save.

Azure client secrets expire on the date you set in the Azure portal, and SSO stops working when one lapses, locking out users on SSO-only domains until you enter a new one. Record the Client Secret Expiry Date so Pactly emails warnings at 2 months, 1 month, and 2 weeks before expiry, then rotate the secret in Azure and enter the new value before it does. The Client Secret field shows when a secret is already configured; enter a new value only when rotating it.

When you use a custom app, Pactly also shows an Azure AD Setup Guide box. It walks through adding the given_name, family_name, and email optional claims to your app’s token configuration so user names sync correctly, and lists the redirect URI your app needs (your Pactly API host followed by /oidc/callback).

Under the main SSO box, the Allow password login as fallback toggle controls whether users on your locked domains can still sign in with a Pactly password:

• Allow password login as fallback: users can choose SSO or password.
• SSO only (no password fallback): users on locked domains must use SSO; password login is disabled for them.

Found under User Provisioning, Pactly offers two ways to create and remove accounts without manual admin work. They are independent, and you can use either or both.

JIT creates a Pactly account the first time a new person signs in through SSO, so you don’t pre-create users.

1. Switch Just-In-Time provisioning to enabled.
2. Set the Default Role new users receive on first sign-in (User, Manager, Approver, Lite, Viewer, or Requester).
3. Click Save.

Everyone who signs in for the first time lands with this role, so set it to what your typical user should have. You can change individuals afterward in User management.

SCIM lets Entra ID push user changes to Pactly directly: it creates accounts when you assign the Pactly enterprise app to someone, and deactivates them when you unassign or offboard the person. This is how you make sure leavers lose Pactly access automatically.

1. Switch SCIM 2.0 provisioning to enabled.
2. Copy the SCIM Endpoint URL shown, and paste it into the provisioning settings of the Pactly enterprise application in Azure AD.
3. Click Generate Token to create a SCIM Bearer Token, then copy it into the same Azure provisioning settings.
4. Click Save.

Pactly’s sign-in is email-first: the user enters their email, and Pactly then routes them to the right method based on their domain.

If their domain is set up for SSO, Pactly routes them to the button labeled with your Display Name instead of asking for a password. When you leave Allow password login as fallback on, users on those domains can still reach a Pactly password from the SSO screen; only SSO only removes that option. The same sign-in covers the Pactly web app and the Pactly Word Plugin, which opens a Microsoft sign-in popup and returns to the add-in once authenticated.

For the end-user sign-in experience, see Signing in to Pactly.

SSO governs how people sign in. For programmatic access (API keys, webhooks), see the Pactly developer documentation. Those are configured separately and are not part of SSO.

• Verify and lock your domains
• Adding and managing users
• User roles and permissions
• Signing in to Pactly