Creating a security group is the fast part — the form is short and there's only one required field. The harder decisions are what to name the group and how it'll fit into your overall role model. Get those right at creation time and you'll save yourself the awkward future renaming.
The mechanics
From the Admin Panel sidebar, click User Groups. The list of existing groups appears. Click New User Group in the top-right corner. Fill in the form:
- Group Name — descriptive name shown wherever this group is referenced. Required.
- Description — optional but recommended. A one-line note explaining what the group is for and who should be in it.
- Default group on registration — toggle (rare) that adds new self-registered users into this group automatically. Most installs handle this via the global Default Security Groups Site Setting instead.
Save. The group is created immediately and you can start adding users and granting permissions.
Naming conventions that scale
Names matter more than you might think. Three principles to follow:
1. Use role-based names, not person-based
Good: "Finance Team", "Engineering Leads". Bad: "Alice's Team", "Bob's Permissions". Person-based names rot the moment Alice or Bob leaves or changes role.
2. Be specific about scope
Good: "Finance Team (Read)", "Finance Team (Write)". Bad: "Finance Team" (when you secretly mean "Finance Team with write access but not delete"). Names that hide their full meaning lead to permission mistakes.
3. Avoid abbreviations and acronyms
Future-you (or a colleague new to the system) won't remember what "CSAOPS-T2" means. "Customer Success Operations Tier 2" is verbose but unambiguous.
Three real example group sets
Example 1: A 20-person SaaS startup
Customer Success Team, Engineering Team, Sales Team, Executive Team, All Employees, External Contractors. Five role-based groups for staff, one catch-all, and one for contractors with limited access.
Example 2: A 500-person enterprise app
Department prefix + tier: "Finance/Senior", "Finance/Junior", "HR/Senior", "HR/Junior", "Sales/Manager", "Sales/Rep", and so on. About 30 groups in total. Permissions are layered: junior groups grant a subset of senior groups.
Example 3: A B2C consumer app
Just three custom groups: Free Users, Paid Users, Cancelled Users. Plus the built-in All Users and Restricted Accounts. Membership in Paid Users is automated based on subscription state.
Adding the group to your permissions matrix
Once the group exists, the real work begins: figuring out which datastores, fields, pages, and actions it should have access to. Open the group from the User Groups list and use the Permissions tab — see the next article for the details. Plan to allocate at least 30 minutes per new group when you first set up your application's permission model.
Tip: Once your application's role model is settled, document it. A simple spreadsheet listing every group, what it's for, who's in it, and what major permissions it has, lives well alongside the platform itself and becomes the source of truth for future admins.