Guides › Start here
Sign-in & Single Sign-On Let staff sign in with your company's identity provider, and know how sessions and API keys behave. Find it: Organization > Company Profile. the Single Sign-On card Before you start: An administrator role. Your identity provider's OpenID Connect details — issuer URL, client ID and client secret. The email domain your team signs in with. Plus the time your DNS takes to publish a record.
Set up SSO You'll need admin access to your identity provider. Create an OpenID Connect application in your identity provider Use the redirect (callback) URL shown in the Single Sign-On card. Copy the issuer URL , client ID and client secret . Enter them in LeadLogiX Organization → Company Profile → Single Sign-On : the three values plus your email domain (for example yourcompany.com). Check the two fields below first. The client secret is stored encrypted and never shown again — not even to you. Publish the verification token as a DNS record on that domain SSO stays switched off until the check passes. Test with a real sign-in from the login page Sign out, enter a work email, sign in at your provider. You return signed in. First-time users are created automatically with the default role you chose. Keep one password-based admin until that round trip works An SSO configuration that half-applies can otherwise lock everybody out. And test only from the login page: creating an account another way skips the checks a genuine SSO sign-in runs, so it cannot tell you the connection works. Any provider that speaks OpenID Connect works — if it gives you an issuer URL, a client ID and a client secret. SAML is not supported ; create an OpenID Connect application alongside it — most platforms support both.
The two fields people get wrong Both fail in confusing ways. The issuer is not the page where you created the app. It is the address that publishes your provider's configuration. Paste the console URL and setup fails with a redirect error. Identity provider Issuer URL to enter Google / Google Workspace https://accounts.google.com Microsoft Entra ID https://login.microsoftonline.com/<tenant-id>/v2.0 Okta https://<your-domain>.okta.com OneLogin https://<your-subdomain>.onelogin.com/oidc/2 Anything else Ask your provider for its issuer . Adding /.well-known/openid-configuration to it should return a page of settings. The email domain is yours, not your provider's — the part after the @ in your staff addresses. On Google Workspace? Your domain is still your own Staff addresses are @yourcompany.com, so the domain is yourcompany.com , not gmail.com. Public providers like gmail.com or outlook.com are refused outright: nobody can verify ownership of them, and you would be left with a DNS record you cannot add. On Google, also set the hosted-domain restriction ( hd ) on your OAuth client to your domain. LeadLogiX already refuses a sign-in whose email domain does not match, but it is kinder to stop a personal account at Google's screen.
Turning SSO off Two different actions — the difference matters. Action What happens Use it when Disable SSO New SSO logins stop. Settings and the verified domain are kept, so switching back on is one click. Pausing — an incident, a provider migration, or testing. Remove settings Deletes the configuration and releases the domain , so it can be set up again from scratch — here or by another workspace. Starting over with a different provider or domain. Neither signs anybody out: people already signed in stay signed in until their session ends. To end sessions now, change the affected people's roles or suspend their accounts in Workspaces & Users .
Sessions How long people stay signed in. A session ends after a period with no activity — no clicking, typing or scrolling — in any open LeadLogiX tab. Shortly before, every open tab shows a countdown; activity in any one keeps the session going. Signing out in one tab signs you out in all, and each says why. Changing someone's role, resetting a password, suspending an account or suspending the workspace ends that session immediately and everywhere. LeadLogiX has no two-step verification of its own. If you require it — and for admins you should — enable it in your identity provider and connect it with SSO; everyone signing in through it inherits it.
How automation signs in Not with SSO — and not with a password. Software uses an API key , minted in Settings → API Playground and sent as an X-API-Key header. Keys belong to the workspace, not a person, so they keep working when staff change. The consent screen you see when connecting a CRM is LeadLogiX asking for access to that service — it creates no way to sign in to LeadLogiX, and the API accepts no outside account or token. You'll know it worked: Signing out and returning to the sign-in page offers your provider, and a test sign-in lands in this workspace with the role you mapped. Setup fails with a redirect error The issuer is the console page you created the app in. Use the issuer from the table above. The domain is refused It is a public provider (gmail.com, outlook.com) — enter your own domain. If it is already claimed by another workspace (one domain, one workspace), contact support rather than re-registering it. “This account has been disabled” — nobody can sign in When everyone is locked out at once it is neither SSO nor passwords: the workspace was almost always suspended over an unpaid invoice, which disables every account together. See Billing → suspended , or email . Your data is not deleted and the suspension is reversible. A personal Google account signs in and is turned away Set the hosted-domain restriction ( hd ) on your Google OAuth client. A new person signing in through SSO is not added If the workspace is suspended or scheduled for deletion, SSO sign-in is refused like every other method and first-time users are not created. The message points at without naming a reason, because it is shown before anyone has proved who they are. Why SSO works the way it does Email-and-password is the default: people are added by invitation, set their own password from the emailed link, and can reset it themselves. SSO is optional and works side by side — it does not remove password sign-in for people who have it, and anyone whose email is on your verified domain is sent to your identity provider automatically. When someone leaves and you disable them in your identity provider, they lose LeadLogiX access too. Domain verification is what stops anyone else claiming your company's email domain. A disabled configuration keeps its domain claim, deliberately — pausing should not let someone else claim your domain mid-migration. Only Remove settings releases it, so to reconfigure with a different domain, remove first. SSO decides who gets in ; roles decide what they can do . New people arrive with the default role you picked — change it from Workspaces & Users like any other member.