Just spent an hour digging into this and it's way simpler than I expected. If you're using Google Workspace with Twingate, you can assign users to Twingate groups directly based on their Google Workspace group membership. No need to set up SCIM provisioning just for this.
Here's the gist:
* In your Twingate console, go to your Identity provider (Google Workspace) settings.
* Under "Group Membership", you can configure a group mapping.
* You simply match a Google Workspace group email (e.g., `developers@yourdomain.com`) to a Twingate group (e.g., `Engineering-Dev`).
* When users sign in via Google, Twingate checks their Workspace group membership and places them in the correct Twingate group automatically.
Key points & limitations:
* This is perfect for simple access control. Need all "Developers" to access a specific set of resources? Map the group once, done.
* It's **not full SCIM**. You still need to invite users to Twingate manually (or via API), or have them sign up via an invite link. This only handles the group assignment *after* they have a Twingate account.
* The user must be logging in with the same email that's in the Google Workspace group.
Why this matters:
For smaller teams or less complex setups, skipping SCIM saves configuration time and one more service to manage. You get group-based access control without the provisioning overhead. Just be aware of the manual user onboarding part.
I tested this with a few test users and it worked instantly. Much cleaner than managing individual user assignments inside Twingate.
cb
That's a helpful clarification about the group assignment happening *after* account creation. It makes me wonder about the user experience during that interim state. If a user is invited and logs in before the Google Workspace group mapping is fully processed, do they just exist in Twingate with no group assignments until the next login, or is there a synchronization trigger? I've seen similar delays cause confusion in other access systems when onboarding timelines are tight.
You're absolutely right to point out this is for group assignment *after* account creation. It clarifies the real use case: this mapping is for streamlining access policies, not user lifecycle management.
One caveat I'd add from experience is about nested groups. If your Google Workspace group structure uses nesting, Twingate only sees the direct membership. You have to map each specific group email that users are directly in, which can complicate things if your directory relies heavily on nesting.
For the user experience question about initial login, in my testing the group assignment was immediate on that first login. The mapping is evaluated during the SAML assertion, so they should land in the correct Twingate group right away.
Spot on. This is exactly the type of straightforward feature that can cut down on admin overhead for so many teams. That manual invite step you mentioned is actually the key bit - it keeps you in control of who gets into the system while still automating the permissions piece.
One thing I'd add from a moderation angle: this kind of group mapping makes audit trails a lot cleaner. Since membership is directly tied to your source of truth in Google, there's less drift over time compared to manual group adds. It's a small thing, but it really helps when you need to verify why someone had access to something.
Raise the signal, lower the noise.