Company SSO
Connect a verified company domain to a SAML identity provider
Company SSO lets allowed employees join/sign in through the workspace's SAML provider. It supports a configured company domain, proof of DNS ownership, provider metadata, a test sign-in and explicit activation. Password and Google sign-in remain available; this flow does not enforce SSO-only authentication.
Requirements
You need a Semogram account as workspace Owner, access to the company domain's DNS and administration access to its SAML identity provider. The deployment must support the configured SSO provider integration. Administrator role alone does not manage Company SSO.
Have your own testing identity assigned to the SAML application. The owner test can grant the verified company identity your existing workspace ownership/permissions while the original account retains access for recovery.
Example company setup
For a company using example.com, open Settings → Company SSO and follow the numbered steps:
- Enter example.com as Company domain and save it.
- Add the displayed TXT record
_semogram-sso.example.comwith the exact displayedsemogram-sso=<verification token>value. Select Verify DNS record after propagation. Do not substitute the illustrative token. - In the identity provider create a custom SAML application using the ACS URL and Entity ID / Audience displayed by Semogram. Configure Name ID as primary email with
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. - Assign your test account in the provider and download its metadata XML.
- Upload the fresh metadata XML (maximum 256 KB) and save the connection.
- Select Test sign-in and retain ownership. Complete provider sign-in and verify the test-passed state on return.
- Select Activate Company SSO after the successful test.
- Add each allowed Employee email in Member access. An employee must also be assigned in the provider and use the supported Company SSO sign-in flow.
Copy the deployment's displayed provider endpoints; do not construct them from an example host. Cloudflare-assisted DNS setup is available only when the deployment/provider template supports it; manual TXT verification remains the explicit path.
Access and membership
New permitted employees join as Member. A company-domain email alone is not an authorization grant. Review their custom read and write-policy permissions after joining.
Removing an email from Allowed employees prevents future joins but keeps existing workspace membership. Disabling new SSO sign-ins does not revoke existing membership, delete service keys or remove earlier data. Review those controls separately when access must change.
Maintenance and troubleshooting
| Problem | Check |
|---|---|
| Owner access denied | Current workspace and owner identity |
| Record not found | Exact TXT name and DNS propagation |
| Value mismatch | Complete token value, not just the domain |
| Test fails | ACS/Audience, Name ID format, assignment and current metadata |
| Employee cannot join | Active connection, exact allowed email and provider assignment |
| Certificate rotates | Disable as required by the settings workflow, upload fresh metadata, test and reactivate |
The configured domain is read-only once saved. Review the UI's connection removal/reconfiguration flow for a domain change. Retain an owner recovery identity before changing the provider.
SSO setup is a signed-in owner workflow; no public API-key or MCP connection-creation action is exposed. An assistant can help review settings and DNS instructions, but must not invent an SSO mutation tool.