When a new user registers, they need a security group — the group determines what they can see and do. Configuring sensible defaults means new users land in the right place automatically without admin intervention.
Default by Registration Source
- Public form: The default for self-service signups. Usually the lowest-privilege customer group.
- Invite from staff: Inherits whatever group the inviter selected on the invite form.
- Invite from admin: Defaults to a staff group; admin can override per-invite.
- SSO (Azure / Google / SAML): Mapped from a claim/attribute coming from the identity provider.
- API: Whatever the calling endpoint specifies — usually defaults to a “API-created customer” group.
Configuring
- Open Site Settings → Users → Registration → Default groups.
- For each source, pick the default group.
- For SSO sources, define the attribute → group mapping table.
- Optionally enable “Multiple group assignment” so users can belong to several groups out of the box.
Worked Examples
- SaaS marketplace: Public form → Buyer; invite from existing seller → Seller (same org); admin invite → Staff.
- B2B platform with admin/user split: Each tenant has its own “tenant_admin” and “tenant_user” groups. Default is tenant_user.
- Healthcare: Public registration disabled; clinicians come in via SSO mapped to “Clinician” group; patients come in via invite from clinic admin.
- Educational platform: Domain-restricted to school. Student domain → Student group; teacher domain → Teacher group.
Note: Always audit group assignments after a default-group change. Going from “staff” to “customer” as a default could leave the previous batch of registrants over-privileged if not migrated.