Support SSO / SAML login for my team

Customers want to authenticate users via SSO or SAML so they can enforce centralized identity management and single sign-on across their organization. SSO and SAML support is intended for teams that already manage employee access through an identity provider such as Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, or another SAML 2.0 provider. With single sign-on enabled, teammates sign in to Chattering through the same company-managed account they use for other work apps. That helps admins apply password rules, multi-factor authentication, account recovery, and offboarding from one place instead of maintaining separate login settings inside Chattering. Before setup, the workspace admin should confirm three things: the team has an identity provider that can create a SAML application, the admin has permission to edit Chattering workspace settings, and the company knows which email domains should be allowed to use SSO. It also helps to decide whether SSO will be optional during rollout or required for every teammate after testing. Teams with contractors or multiple brands should review the email domains carefully so the right people can still access the workspace. A typical setup starts in the identity provider. Create a new SAML application for Chattering, then copy the single sign-on URL, entity ID, and signing certificate from the provider. In Chattering, an admin would add those values to the workspace authentication settings, save the configuration, and download or copy the Chattering service provider details back into the identity provider. The provider should send at least the teammate email address as the name ID or an email attribute. If the provider supports first name and last name attributes, those can be mapped too, but the email address is the required identity anchor. After the metadata is saved on both sides, test with one admin account before requiring SSO for the whole team. Open a private browser window, visit the Chattering login page, choose the SSO option, and enter an approved work email address. The browser should redirect to the identity provider, complete the company login flow, and return to the Chattering dashboard. If the account already exists, it should land in the same workspace. If just-in-time provisioning is enabled, a new teammate can be created after the provider confirms the user. Common troubleshooting checks are straightforward. If the login returns an invalid audience or recipient error, compare the service provider entity ID and ACS URL character by character. If the user signs in but lands in the wrong place, confirm the email address in the SAML assertion matches the Chattering teammate account. If the certificate expired or was rotated in the identity provider, paste the new signing certificate into Chattering before the old one is disabled. If a teammate is removed from the company directory but can still access Chattering, confirm that SSO is required for the workspace and remove any active local access method during offboarding. Frequently asked questions: Can we keep password login during rollout? Yes, many teams prefer to test SSO with admins first, then require it once the redirect and user mapping are correct. Does SSO replace role management? No. SSO proves identity, while Chattering workspace roles still decide what a teammate can view or change. Can customers use our team SSO? No, this request is about teammate access to the Chattering dashboard, not end-customer authentication inside the chat widget. What should we send support if setup fails? Share the identity provider name, the error shown after redirect, the affected email domain, and whether the failure happens before or after the provider login screen. Those details make it much easier to spot a metadata, certificate, or attribute mapping issue.