This message was deleted.

Hi there, I'm the employee in charge of Pulumi's internal IdP 😃 I can tell you that for our own cloud org, we use a mix of SCIM teams and local teams. That's because the teams in our IdP are pretty coarse grained and mostly auto-generated based on other systems. For teams that don't match up with those lines, it just works out in our case that there's less friction to delegating Team admins in the Pulumi Cloud than it is trying to keep all the bespoke team memberships managed via the IdP. But obviously, like you said, this depends a lot on your policies and how administration is devolved throughout your org. Feels hard to give definitive guidance, because everyone's situation is so unique.

Hi @icy-accountant-52329, thanks for the reply! 😃 That’s some nice insight, thanks for sharing! Agreed, I think it’s very dependent on institutional mandates or preferences, but I do see some great use cases and reasons for each strategy. I would even dare say that a hybrid strategy like that has more pros. One key aspect is exactly what you mentioned, the delegation of Team memberships to Team admins and not having to deal with IdP directly. What’s also great about this is that access to the Pulumi Org is still governed by that initial SCIM group, as members need to be in a SCIM group before being added to any other Team, so SAML SSO authentication is still required by enabling SCIM. Seems like the idea of deciding to create a new local Team is, or may be primarily governed by, some bespoke group of individuals working on “X” possibly from different SCIM Teams that may not necessarily work in the same group/department…or something like that. It’s an interesting “problem” to think about and seems like there is no “standard best practice” as it’s all possible, and unique to each Org 🤔 …a personal decision. Thanks for listening my thought dump, and thanks again for your feedback!