Team Management & SSO

Overview

Sulus uses Role-Based Access Control (RBAC) to manage what each member of your organization can do. You assign a role when you invite a member to your organization, and that role determines what parts of the dashboard and API they can view or change.

Three roles are available:

The Editor role is recommended for developers, since it gives full build and test access without exposing billing or member management.

Roles are assigned when you invite a member to your organization — there is no separate step to set permissions afterward beyond changing the member's assigned role. Sulus does not support SCIM provisioning: each user creates their own Sulus account when they sign up, and your organization's admin then invites that user into your organization and assigns their role.

For teams running multiple environments (for example DEV/UAT/PROD), the recommended approach is to use separate organizations per environment (e.g. acme-dev, acme-uat, acme-prod) and apply least-privilege RBAC across them:

• Developers — write access to dev, read access to uat, no direct prod writes
• CI/CD service principals — one per organization, used for automated deployments
• Production — changes only via CI/CD pipelines, not direct user writes

SSO is an enterprise-only feature that lets your team authenticate through your existing identity provider instead of managing separate Sulus credentials. Sulus works with any identity provider (IdP) that supports either of the following protocols:

• SAML 2.0
• OpenID Connect (OIDC)

This includes popular providers such as Google Workspace, Microsoft Entra ID (formerly Azure AD), and Okta. Once SSO is enabled for your organization, Sulus provides your IT administrator with a secure link to configure your identity provider's credentials in the SSO admin panel.

RBAC works alongside SSO — permissions remain managed within Sulus even when sign-in is handled by your IdP. Because Sulus does not support SCIM provisioning, users still create their own account and are then invited into your organization with a role, exactly as described above.

SSO is part of Sulus's enterprise plans, which can also include unlimited concurrency, higher rate limits, a HIPAA BAA, SOC 2 (Type II) certification, and SLA commitments. To enable SSO for your organization, contact the Sulus team at [email protected], since this is a manual, sales-assisted setup rather than a self-serve dashboard toggle.

• Roles are assigned at invite time; there are only three roles (Admin, Editor, Viewer) and no custom/granular permission sets.
• Only Admins can manage Org Settings, Billing, Members, and API Keys.
• SCIM is not supported — team members always self-register an account before being invited.
• SSO handles authentication only; authorization (what a member can do once signed in) is still governed entirely by RBAC.

In summary, Sulus keeps team access simple with three roles assigned at invite time, while enterprise organizations can layer SSO on top for identity-provider-based sign-in without changing how permissions are managed.