Add enterprise setup guide #3693
Conversation
|
|
||
| A project in Statsig serves as a workspace that contains everything you and your team will create. This includes configs (e.g., feature gates, experiments, dynamic configs, layers), metrics, integrations, and more. | ||
|
|
||
| When creating a new project, you can set its type to *Open* which would allow anyone in the organization to join freely, or to *Closed* which would allow people to join only by invitation or request. |
There was a problem hiding this comment.
Maybe add something about how unless you're using SCIM, new folks will join as Member, if you have an open project
| <img src="/images/access_management_invite.png" alt="Project invite interface" /> | ||
| </Frame> | ||
|
|
||
| If you’ve successfully configured SSO, your teams can now join the Statsig organization by signing in with your identity provider. |
There was a problem hiding this comment.
Something something about how that means that they're responsible for provisioning them in their SSO provider etc / can hook into whatever requests flows etc they have there
| If you haven’t set up the SSO yet, you can invite individual members to your organization and/or project in the console. | ||
|
|
||
|
|
||
| #### Step 6: Creating Teams within the Project |
There was a problem hiding this comment.
Add something about how Teams can also have their own settings that restrict folks to only being able to review a change if they are on that team / etc (and how it intersects the permissions - e.g. if you say only team admins can do it, it's only team admins with a role that allows reviewing can do it)
| <img src="/images/access_management_team_filter.png" alt="Team filter in experiments" /> | ||
| </Frame> | ||
|
|
||
| Team becomes extremely useful as multiple teams begin to use Statsig, and it also helps the onboarding of new users as it provides a set of defaults to go off from. |
There was a problem hiding this comment.
other best practice thing we could call out here is that if you are using us via SCIM you can SICM assign teams, but otherwise the most common thing we see folks do here is federate out teams and have e.g. tech leads responsible for adding people to their corresponding teams - and combining that with the other setting saying that you have to be on a team in order to create something)
| You can also give certain roles (e.g., oncalls) the ability to self-approve or require reviews only for production environment to allow for agility when needed. | ||
|
|
||
|
|
||
| #### Configuring Target Apps for SDK keys |
There was a problem hiding this comment.
The other thing we should chime in on similarly is just how we would recommend folks set up their SDK keys in general. There is a crawl walk run here - where the initial phase is just have your different environments use their own keys -> different frontend clients using different keys (e.g. ios vs android) -> different backend services using different keys - this sets people up really really well to make use of target apps)
Description
[Include a brief summary or screenshot of your changes]
Best practice checklist
Questions?
Reach out to Brock, Tore, or Logan on Slack!