Configure SSO for Connect App & Portal
Coordinate Connect and your identity-provider admin so employees can use their company identity in both surfaces.
Prerequisites
Gather the organization and identity-provider details below before requesting or configuring SSO. Confirm the active account, organization, and permission level before editing settings or comparing reported values. Refresh the relevant view after each change and check that the expected user or group remains selected. Document dates, identifiers, and visible status messages when the result differs from the expected account state.
- A Connect enterprise organization and an organization administrator.
- An administrator for your identity provider.
- Your verified company email domain.
- A small group of test users, including one standard member and one administrator.
- A recovery sign-in method retained until the rollout is validated.
Request SSO activation
SSO must be enabled for the organization before employees can use their work identity to access Connect. Document dates, identifiers, and visible status messages when the result differs from the expected account state. These details prevent changes from being applied in the wrong context. Confirm the active account, organization, and permission level before editing settings or comparing reported values.
- Contact Connect from your organization account and request SSO for the desktop app and Portal.
- Provide the company name, verified email domain, preferred identity provider, admin contact, and intended rollout date.
- Agree on the sign-in identifier and whether access should be restricted to provisioned organization members.
Connect will provide the configuration values needed by your identity-provider administrator. Exchange metadata, certificates, client secrets, or similar credentials only through the secure method agreed with Connect support.
Configure the identity provider
The exact fields depend on the protocol and identity provider selected for your organization. Use the values supplied for your Connect tenant rather than copying values from another deployment. These details prevent changes from being applied in the wrong context. Confirm the active account, organization, and permission level before editing settings or comparing reported values.
| Confirm | Why it matters |
|---|---|
| Unique app registration | Separates Connect access, certificates, and audit events from unrelated services. |
| Correct sign-in identifier | Usually the employee's work email; it must match the Connect member record. |
| Assigned pilot users | Prevents an organization-wide rollout before login and role mapping are verified. |
| Current signing certificate or secret | Avoids failed assertions and unexpected expiry. |
| Access policy exceptions | MFA, device-compliance, or location rules must allow the Connect app flow. |
Complete Connect-side activation
After the identity-provider configuration is ready, send the requested non-secret identifiers and complete the secure exchange with Connect. Activation associates the verified domain and organization with the SSO connection. These details prevent changes from being applied in the wrong context. Confirm the active account, organization, and permission level before editing settings or comparing reported values.
Log in
Welcome back. Your conversations are waiting.
Faithful Connect sign-in simulation: the SSO control becomes usable only after organization activation.
Test the app and Portal
Validate both access points with a small test group before making SSO available to the full organization. Confirm the active account, organization, and permission level before editing settings or comparing reported values. Refresh the relevant view after each change and check that the expected user or group remains selected.
- Use a private browser window or a signed-out Connect session to avoid reusing an old identity-provider session.
- Enter a pilot user's work email and complete the identity-provider flow.
- Confirm the user opens Connect with the correct organization and role.
- Open the Portal and verify the same account can access only the expected tools.
- Test sign-out, reauthentication, MFA, and one intentionally unassigned user.
Roll out to the organization
Expand access gradually so your team can confirm account assignment, sign-in behavior, and support ownership at each stage. Confirm the active account, organization, and permission level before editing settings or comparing reported values. Refresh the relevant view after each change and check that the expected user or group remains selected.
- Assign users in controlled groups.
- Tell users to sign in with their exact company email address.
- Share the expected identity-provider prompt and MFA behavior.
- Monitor failed sign-ins during the first rollout window.
- Schedule certificate or secret expiry ownership before handoff is complete.
Common sign-in issues
Start with the checks below when authentication fails, redirects unexpectedly, or does not recognize the organization account. Refresh the relevant view after each change and check that the expected user or group remains selected. Document dates, identifiers, and visible status messages when the result differs from the expected account state.
| Symptom | Check |
|---|---|
| SSO control is disabled | Organization activation is not complete for this account or build. |
| User is not recognized | Email/domain mismatch, user not assigned, or missing Connect organization membership. |
| Identity provider rejects the request | App registration values, callback values, conditional access, or expired signing material. |
| App works but Portal does not | Test the same email, role, and fresh session in both surfaces; then contact Connect support with the timestamp. |
Frequently asked questions
These answers cover the most common decisions before an organization enables SSO for its users. Keep a recovery sign-in method and a small pilot group available until both the desktop app and Portal have been validated. Record the email, organization, identity-provider response, and timestamp when a sign-in result differs from expectations.
Why is the SSO button disabled?
The organization has not yet been enabled for SSO on that account or Connect build. Ask an organization administrator to confirm activation with Connect before instructing users to select the disabled control.
Who needs to configure SSO?
A Connect organization administrator and an administrator for the selected identity provider should coordinate the setup. Use only the tenant-specific values supplied through the agreed secure channel; do not copy callback URLs, identifiers, or signing material from another deployment.
When can we remove the recovery sign-in method?
Keep it until at least two administrators have successfully tested the desktop app, the Portal, sign-out, reauthentication, and MFA. Removing the fallback too early can lock the organization out while assignment or certificate issues are still being corrected.
Why does SSO work in the app but not in the Portal?
Retest with the same work email in a fresh signed-out session and confirm that the account has the expected organization membership and role. If the results still differ, send support the timestamp, identity-provider response, account email, and affected access point without sending secrets.
Support
Need help? Get in touch with our Support Team for assistance. Include the calling application, operating system, selected microphone and speaker, translation direction, and the exact step that failed. A short description of the expected result and what happened instead helps the team respond more quickly.