Single sign-on
Let members — and optionally requesters — sign in through your identity provider.
Settings → Single sign-on
Single sign-on (SAML or OpenID Connect) — lets members sign in through your identity provider (Okta, Microsoft Entra ID, Google Workspace, etc.) instead of an email/password; optionally lets the people who raise tickets sign in to the portal with it too, and keeps them in step with your directory. Owner/Admin only.
What it does — and doesn't — do
SSO signs a member in by matching the email your IdP asserts against a member of this organization. By default it does not create accounts — someone with no membership here is rejected, not silently added. Turn on Create accounts on first sign-in to let anyone your IdP admits join as a Member, within your plan's seats. It only ever creates a brand-new account: someone who already has an account (in another workspace, say) is invited instead, and a member you deactivated is never brought back. Members with two-factor authentication are still asked for their code.
Setting it up
- Pick your Identity provider and Protocol first — the field names below change to match your provider's own words, and the Setup in … card lists its steps.
- OpenID Connect — register the redirect URI shown on this page with your IdP, then enter its issuer URL, Client ID and Client secret. The issuer must serve
/.well-known/openid-configuration. - SAML — register the ACS URL and SP entity ID shown on this page with your IdP — or give it the SP metadata URL if it can import one — then fill in the three IdP fields below.
- Share the sign-in link with your team, or have them choose Sign in with SSO and enter this workspace's URL name.
- IdP entity ID / issuer (SAML) — your IdP's own identifier for this app integration.
- IdP SSO URL — where your IdP receives login requests (sometimes called the "Sign-on URL" or "SSO endpoint").
- IdP signing certificate — the public certificate (PEM format) your IdP uses to sign assertions, so this app can verify they're genuine.
- Email attribute name (Email claim for OpenID Connect) — which attribute in the assertion, or claim in the token, carries the user's email. Defaults to
email; check your IdP's attribute mapping if sign-in fails with a missing-attribute error.
The portal: sign in with your company account
With an OpenID Connect connection, Let them sign in to the portal with it adds a “Sign in with your company account” button to your self-service portal. Anyone your provider verifies goes straight to their own requests; a record is created for them on their first sign-in. No seat is used and nothing changes at your provider — it returns through the same redirect URI. SAML connections do not offer it yet.
Directory sync for the people who raise tickets
- A second SCIM integration, separate from member provisioning: set it up as its own app in your provider with the tenant URL and token from its card. It never uses seats.
- It keeps name, email, job title, phone and work address (as the site), plus the enterprise attributes department, division (your third grouping), organisation (company), employee number and manager.
- Someone already on file with the same email is updated, not duplicated. New department, site, division and company values join your lists.
- No directory? Import people from a spreadsheet instead, from the list of people (the Import button).
When someone leaves
- When the directory deactivates or removes someone, their record is marked Inactive. Their tickets stay; their portal link stops working, they cannot sign in to the portal, and they are skipped as an approving manager.
- When someone who has left raises a new request — accept it labelled “Departed customer” (the default), accept it as normal, or refuse it. Replies on their own tickets and tickets your team raises always go through.
- When someone who has left still has devices — choose a project, and a ticket listing each device they hold (with serial numbers, linked to them all) opens there.