User Groups

This guide will get you started on how to manage User Groups in Doppler.

📷

Requires an upgraded subscription

This feature is standard on our Enterprise plan or can be added on to an existing Team plan. Explore pricing or book a demo for more details.

User Groups provide the fine-grained access controls required by large and enterprise organizations for managing Project ACLs at scale.

User Group allows you to better apply the principle of least privilege by limiting the default workplace user access level for all users and only elevating access per project as required.

Combined with our Enterprise SCIM 2.0 support, users and groups memberships are managed and provisioned from your Identify Provider (IDP). This allows you to define precise grouping based on ActiveDirectory/LDAP membership attributes, or other mapping configurations specific to your IDP such as Application > Role mapping.

Requirements

• Enterprise subscription

Management

Groups are managed via the Doppler dashboard with the exception of SCIM (Enterprise required) where they are provisioned based on mappings from your IDP.

Below is a table showing how Users and Groups are managed based on your SSO method.

Dashboard Created Groups

Email SSO and SAML require Groups to be created manually via the Doppler dashboard.

For team/project-based groups (e.g. Frontend), we recommend setting the Project Access level to Collaborator whereas role-based groups that work cross-functionally (e.g. DevOps) are a better fit for Admin level access.

Project Access

Granting Project access to Groups is the same as users. Click on the Members button from the Project overview page, then select which Group(s) to add to the Project.

Default Project Role

A default project role can optionally be assigned to a group. Whenever the group is added to a project, the group will automatically get this role. You can override it per-project or leave it as the workplace's default role.

SCIM

SCIM is the ideal method for managing Doppler Groups as it automates the provisioning and membership mapping based on assignment rules configured in your IDP.

Once the Groups are provisioned in Doppler, workplace owners and admins can then edit the project access levels for each group.

Group Mapping and Provisioning

Every organization has its unique way of managing users and groups (e.g. AD, LDAP, or built-in IDP user management) so we're not able to offer a single guide that caters to every setup.

Consult the SCIM Groups mapping documentation for your IDP to learn which strategy will work best, e.g. Group membership based on regex matching of AD/LDAP field values or using the built-in Roles functionality of your IDP.

Or alternatively, reach out via in-product support and we can help guide you towards the best solution.

📘

The SCIM Access Level defines both the default Workplace and Group membership access levels. We recommend keeping this at Collaborator.

Implementation Advice

While each organization’s approach to Group management will likely differ, here is some general implementation advice to keep in mind.

Configure Workplace Logging Services

We recommend configuring Workplace Activity Logs in order to capture any User and Group-related events that occur in Doppler. This is especially important for tracking Doppler-specific user management activities that won't be captured by your IDP (e.g. Groups management when using SAML).

Collaborator for Default Access Level

We recommend keeping the default access level as Collaborator so access to environments is given on a group-by-group basis.

Projects Access for Groups and Individual Users

While it’s best to utilize Groups as much as possible for bulk Project access management, adding individual users to a Project is an option to keep in mind when the Group mapping from your IDP is not flexible enough, or if a user needs temporary access to a Project.

If using SCIM however, we recommend adding a user-specific mapping within your IDP in order to keep your IDP the source of truth which also ensures your IDP audit log captures every access level change.

Limit workplace admins by using a Group with Admin Access

As a Workplace level Admin has edit access to every project, we recommend using Groups with Admin permissions that can be selectively applied to projects as needed.

FAQs

How should I structure groups/roles? By job role group, team/department, project groupings?

Generally, a mix of teams (e.g. frontend) and role-based groups (e.g. QA, DevOps) is recommended.

For example: