User Groups Settings
User Groups
Section titled “User Groups”The User Groups tab is where you define the access tiers users belong to. Each group controls which modules a member can open (CRM, Production, Configuration), which devices they can access from (Desktop, Mobile App), and you can pick one group as the default that new users automatically land in.
Open the tab from App Settings → User Groups.
Table of contents
Section titled “Table of contents”- What this tab is for
- Anatomy of the page
- The Add / Edit form
- Module access
- View access
- The default group
- Reading the groups list
- Deletion rules
- How groups interact with the user Role
- Tips and best practices
What this tab is for
Section titled “What this tab is for”Use this tab to:
- Define access tiers — Planners, Floor Leads, Back Office, Read-only Managers, etc.
- Toggle module access per group — which top-level sections of the Admin Panel they can see.
- Toggle device access — desktop only, mobile only, or both.
- Pick a default group — every new user lands in this group unless explicitly assigned.
Setting up groups well means you almost never have to touch per-user permissions. You assign users to groups, and the group does the rest.
Anatomy of the page
Section titled “Anatomy of the page”The page has two stacked sections:
- Add / Edit form at the top — a bordered card that’s empty by default; populated when you click Edit on a group.
- Groups table below — every existing group, with module and view badges, user count, and Edit/Delete actions.
The Add / Edit form
Section titled “The Add / Edit form”The form sits in create mode by default — clicking Edit on a table row switches it to edit mode. Fields:
| Field | Notes |
|---|---|
| Name | Required. The group’s display name. |
| Description | Optional. A note about the group’s intent. |
| Module Access checkboxes | See Module access. |
| View Access checkboxes | See View access. |
| Set as default group for new users | A single checkbox. Only one group can be the default at a time. |
Click Save to apply. The form resets to create mode after successful save.
Module access
Section titled “Module access”Three independent checkboxes:
| Module | Grants access to… |
|---|---|
| CRM | Leads, Quotes, Tasks, and CRM Settings. |
| Production | Jobs, Orders, Production, Workstations, Departments, Employees, Job Templates, Time Tracking. |
| Configuration | App Settings (this whole area), including User Groups, Kanban Views, Webhooks, Cron Jobs, Naming, etc. |
A user whose group denies a module won’t see its sidebar entry at all — there’s no “permission denied” page, the option simply doesn’t appear.
Admins bypass module access. Users with the
adminrole can do anything regardless of their group. Module access only constrainsuserandemployeeroles. See Users.
View access
Section titled “View access”Two checkboxes:
- Desktop — can the user sign into the Admin Panel on a normal desktop browser?
- Mobile App — can the user sign into the mobile companion app?
Most users get both. Use Mobile only for shop-floor leads who don’t need desktop access; Desktop only for back-office staff who don’t carry the mobile app.
The default group
Section titled “The default group”The Set as default checkbox on the form flags this group as the one new users automatically join when they’re created without an explicit group.
Rules:
- Exactly one group can be the default at any time.
- Marking a different group as default clears the flag on the previous one.
- The default group cannot be deleted (see Deletion rules).
In the groups table, the default group is shown with a small yellow star icon next to its name.
Reading the groups list
Section titled “Reading the groups list”Each row shows:
| Column | What it shows |
|---|---|
| Name | Group name. Yellow star if it’s the default. |
| Description | Optional note (or blank). |
| Modules | A row of colored badges for CRM / Production / Configuration. Granted modules show; denied ones are absent. |
| Views | Badges for Desktop / Mobile App. |
| Users | A count icon and number showing how many users currently belong. |
| Actions | Edit (pencil) and Delete (trash). |
The Users column is the safety-check before deletion — a group with users in it can’t be deleted (see below).
Deletion rules
Section titled “Deletion rules”A group can only be deleted when:
- It is not the default group.
- It has zero assigned users.
If either condition fails, the Delete button is disabled and a tooltip explains why:
- “Cannot delete the default group.” — pick another group as default first.
- “Cannot delete group with assigned users.” — move users to a different group first.
Deletion is permanent and triggers a confirmation dialog showing the group name.
How groups interact with the user Role
Section titled “How groups interact with the user Role”Each user has both a role (set on their User record) and a group (also on their User record). They layer:
- Role defines the user’s maximum capability.
admin= everything,user= standard,employee= standard + Kiosk PIN access. - Group narrows that maximum by hiding modules and views.
For an admin user, the group is effectively ignored — they can do anything.
For a user or employee, what they see is the intersection of role and group: the role says they’re allowed in, the group says which parts.
See Users → The three roles for the role side of this picture.
Tips and best practices
Section titled “Tips and best practices”- Have at least three groups — typically Admin / Standard / Floor Lead or similar. Even small shops benefit from differentiation.
- Name groups by what they do, not by who is in them. “Planners” is better than “Jan and Anna”.
- Pick the broadest sensible default. New users shouldn’t accidentally land in a high-privilege group; pick something like “Standard” with Production access but not Configuration.
- Keep Configuration access tight. Anyone with Configuration can edit User Groups themselves — they can effectively self-promote. Limit it to admins and one or two trusted seconds.
- Mobile-only is genuinely useful. Shop-floor leads who need the mobile app for clock-in / clock-out but should never edit settings benefit from Mobile only.
- Move users before deleting groups. The two-condition rule for deletion is a safety net — if you really want to retire a group, retire it gracefully: move users elsewhere first, then delete the empty shell.
- Restrict kanban views via the group. When combined with Kanban Views, you can scope what each group sees on the Production page. Floor leads might only see their department’s view; planners see everything.
- Pair this with Users for the full picture — define groups here, then assign each user to one on the Users page.