Single sign-on (SSO)

Enterprise adds single sign-on for every team member. You choose it under Settings → Subscription & invoices like the other plans. First verify a company domain under Settings → Access management. Without a verified domain you get the message “Verify a company domain before choosing Enterprise”.

Until a connection is on, everyone keeps signing in with the e-mail link, a passkey, or Google, Apple and Microsoft.

Changes on Settings → Access management only work within 2 hours after you sign in, and only from your own login: not while a reseller or our support works in your account. See Changes that ask you to sign in again.

Verify a domain

1. Open Settings → Access management. This tab is there for admins, also without Enterprise: you claim a domain before you choose Enterprise.
2. Enter the company domain, for example example.com, and choose Add domain. The domain gets the status Waiting for DNS.
3. Create a DNS TXT record on that domain, or on _yarla.example.com, with the value yarla-verify= and the token shown on the page.
4. Choose Check DNS. If the check does not find the record yet, wait a few minutes and try again. When it works, the status is Verified.
5. Under Settings → Subscription & invoices, choose Enterprise.

Public inboxes such as gmail.com cannot be claimed. A domain belongs to a company only once its DNS check passes: a claim that is still waiting for DNS at another company does not block yours, and whoever passes the check first gets the domain. After that, no other company can verify it. A claim that has waited for DNS for 30 days lapses; add the domain again to continue.

Connect the identity provider

A company can keep several connections, up to ten. Choose New connection and pick the service under Provider. The list covers Microsoft Entra, Okta, OneLogin, Ping Identity, Auth0, JumpCloud and Keycloak, each with SAML or OpenID Connect, and Google Workspace, AD FS, Duo and AWS IAM Identity Center with SAML. Anything else is Custom SAML or Custom OpenID Connect. The name is filled in from that choice.

SAML. Paste the Metadata URL (it must start with https://). Below the field you see the usual URL for the provider you picked. In the identity provider, set the reply address to the address on this page, shown while the form is open. It ends with /saml2/idpresponse.

OpenID Connect. Paste the Issuer (it must start with https://), the Client id and the Client secret. The secret is not shown again after saving. If you leave the field empty under Edit, the stored secret stays. In the identity provider, set the redirect URI to the same address as the reply address, but ending with /oauth2/idpresponse.

The provider must send the e-mail address in the attribute email and the name in name. Under Groups attribute, enter the attribute or claim that carries the group names. The default is groups.

Use this connection for single sign-on is already on for a new connection. Untick it while the provider is not ready yet. Then choose Save: this form does not save automatically.

When a connection is on, the sign-in page sends an address on a verified domain straight to the provider after the e-mail address is entered, even when single sign-on is not required. When more than one is on, the team member picks one there. The connection marked Default is only a marker in the list in the dashboard. Make default moves it.

Team members start on the sign-in page. Starting from the provider's portal does not complete the sign-in. If someone already has an account with the same address, made with the e-mail link or an invitation, their first sign-in through the provider ends with “Sign-in was cancelled or rejected. Please try again.” The account is then linked and the next attempt works. An account that was started with Google, Apple or Microsoft is not linked; the team member is still recognised by the address. An address that already belongs to another company's account is never linked or moved: that sign-in ends with “This address belongs to another account”. The person first leaves that account (or its admin removes them), then signs in again.

Under Sign-in rules, on the same page, changes save automatically. Choose what happens when a company-domain address that is not on the team yet signs in through the provider for the first time: Create an account automatically (the default) or Invite only. With the second, that person sees the same message until you have invited them, and a first sign-in with Google, Apple or Microsoft on the domain does not create an account either. New accounts get the Role for new accounts, by default Viewer.

Require single sign-on for verified domains is available after a domain is verified and a connection is on. Those addresses then cannot use the e-mail link or a passkey, and a sign-in with Google, Apple or Microsoft is refused, also for a login that already existed but is not on the team yet. Invited team members with another address can still use the e-mail link. If you invite an address on a verified domain while this is on, you see “Sign in with your company identity provider”. The team member has still been added and shows in the list after you reload the page, but no invitation e-mail goes out: they sign in through the provider. Under Emergency e-mail addresses, enter up to three addresses, separated by commas, that can still use the e-mail link or a passkey. For an address on a verified domain, each use is written to the audit log. An address on another domain falls outside this rule anyway, and its sign-ins are not logged.

Under Map groups to roles, map up to twenty group names to Admin, Editor or Viewer, with one rule per group. The first rule that matches applies. Capitals do not matter. For an account created by a first sign-in through the provider, the role is worked out again at every sign-in through the provider: if the provider sends groups with no matching rule, the team member gets the Role for new accounts. If the provider sends no groups, the role stays. An account that already existed and was linked (invited, created through SCIM, or already signing in another way) is not included: its role stays as set under Settings → Team, or follows the SCIM groups below. Ask the provider to send only those group names, not every group in the directory. The last admin is never demoted.

SCIM

Under SCIM on Settings → Access management, create a token with Create token. The token is shown once, so copy it right away. The identity provider calls /scim/v2/Users and /scim/v2/Groups on your dashboard's address with Authorization: Bearer scim_….

Creating a user adds a team member with the Role for new accounts. userName must be the e-mail address, on one of your verified domains (any other address is refused), and no invitation is sent. Setting active to false disables the team member. A disabled team member cannot open the dashboard and shows as Deactivated under Settings → Team. Deleting a user in SCIM also disables the team member. To do that yourself, use Deactivate under Settings → Team. Removing someone from the team is only possible there, with Remove. The only active admin cannot be deactivated or deleted over SCIM: the provider gets a 409 answer. Make another team member admin first. Users created, deactivated or reactivated over SCIM, and role changes from SCIM groups, are written to the audit log.

Group members get the role from Map groups to roles. They only come through when the provider sends them with POST or PUT on /scim/v2/Groups. A PATCH with Operations does not change the members of a group.

Security rules

Each rule under Security rules starts off. Changes save automatically.

• End sessions after this many hours is a number of hours from sign-in, from 1 to 720. Empty means no limit.
• Require a second factor in the dashboard sends a team member to My account → Security until an authenticator app, passkey or hardware key is set up. A text-message code does not count.
• Accept MFA already done at the company provider skips that second factor for people whose account was created by a first sign-in through the company provider. Tick it if the identity provider already requires MFA. Someone with a linked account (invited, created through SCIM, or already signing in another way) must still set up the second factor, and so must anyone who signs in with the e-mail link, for example with an emergency address.
• Allowed dashboard IP ranges limits the dashboard to those ranges: one CIDR per line, up to 50. Empty means every address. An IPv6 address only matches when it is listed on its own, not through a range. Add your own address, because outside the list you cannot open the dashboard, even as an admin. Webhooks, the chat widget and phone calls stay open.
• Also limit API keys to these IP ranges applies the same list to requests that use an API key. Without this tick they are not included.

The Audit log at the bottom of the page lists the latest 20 sign-ins and admin changes, including the IP address when it is known. Download CSV gives up to 500. Both go back as far as the number of days under Keep conversations (days) on Settings → Business. A sign-in through the provider with a linked account is not listed. A refused sign-in (an address that belongs to another company's account), a role change from provider groups or SCIM groups, and a change to the security rules, with the rules that changed, are listed.

If you enter an Audit webhook URL under Security rules, it must be an https:// address; any other address is not saved. Each event then goes to that address as a POST with JSON (id, businessId, at, action, actor, summary, ip). That request is signed with X-Yarla-Signature, using the same webhook secret as other webhooks (Settings → Connections under Webhook secret). Webhooks explains how to check it. A request that takes longer than 3 seconds is cut off, and a failed request is not retried; the entry stays in the audit log.

Conditional access, device compliance and risk checks stay in the identity provider. Signing out here ends the session in this app. It does not end the session at the identity provider.

When you leave Enterprise or a payment is open

When you switch to a cheaper plan, you first see what stops and confirm it. At the renewal date (or when a cancelled subscription ends), Require single sign-on for verified domains and the security rules are turned off and the SCIM tokens are revoked. Everyone signs in again with the e-mail link, a passkey, or Google, Apple and Microsoft, and keeps their account. Signing in through the provider stops for everyone, also for team members who have done so before: they use the e-mail link with the same address. The connections stay saved, inactive, under Settings → Access management: they come back when you choose Enterprise again and open that page, and you can delete them. The audit log stays readable. Admins and the billing contact get an e-mail listing what changed. See Subscription & invoices.

While a payment is open (past due or paused), nothing becomes less strict: single sign-on, the security rules, SCIM and deactivated members keep applying. You can change them again once the invoice is paid.