Workgroups: layering extra access on top of a member's role

Every member of your account has exactly one user group - their role, like "Teacher" or "Operator". That role answers who this person is in the organization. But real teams have a second question the role can't answer: what else is this person doing right now? The teacher who also runs the robotics club. The student who joined the design lab for one term. The contractor who needs three printers for six weeks.

Workgroups answer that second question. A member has one user group, but can belong to any number of workgroups at once, and each one adds permissions, printer access and allowances on top of what their user group already gives them. Nothing is replaced, and nothing is taken away.

What you'll find here

• User groups vs workgroups, side by side
• How permission layering actually works
• What a workgroup can and can't grant
• Creating a workgroup
• Giving a member a workgroup, permanently or temporarily
• Where workgroup membership comes from
• Keeping SSO and SCIM in sync
• Workgroups from school classes
• Basing one workgroup on another
• Workgroup allowances: personal and shared
• Deleting a workgroup
• Good to know

User groups vs workgroups, side by side

Both are built from the same permission system, and both can carry printer access. The difference is how many a person can have, and how much authority each is trusted with.

The short version: your user group is your job title, your workgroups are the rooms you have keys to. Changing someone's job title is a decision about authority. Handing them a key for the term is not, and it shouldn't require rebuilding your whole group structure to express it.

Why this exists

Before workgroups, a member who needed one extra thing left you with three bad options: give them a more powerful group than they should have, build a whole new group for that one combination, or say no. Accounts ended up with groups called "Teacher (with laser)" and "Student - robotics + design lab", which multiply every time a new combination appears.

Workgroups collapse that. Two workgroups and four user groups cover the same ground that would otherwise need sixteen groups, and each one stays readable.

How permission layering actually works

When SimplyPrint decides whether you can do something, it builds your effective access by combining your base role with every workgroup that is active for you right now:

• Permissions are unioned. You have a permission if your user group grants it or any active workgroup grants it. There is no ordering, no priority and no override - one "yes" anywhere is a yes.
• Printer access is unioned separately. Your reachable printers are everything your user group names, plus everything each active workgroup names - individual printers, printer groups, and printer models all merge together.
• The two lists are combined independently. This is the part worth reading twice: a permission that came from one workgroup applies on a printer that came from a different workgroup.

That last point is what makes workgroups compose instead of just stack. Concretely:

Maya's user group is Student: she can slice and queue, but not start prints, and she can only see the two classroom printers.

She's in the Robotics Club workgroup, which adds "Can print" and unlocks the club's X1-Carbons.

She's also in Design Lab, which adds no new permissions at all - it only unlocks the design-lab printers.

Maya can now start prints on the design-lab printers, even though neither workgroup granted both halves. Robotics Club supplied the permission, Design Lab supplied the printer, and her effective access is the combination.

If that isn't what you want, the fix is to scope the permission-granting workgroup to its own printers rather than to try to express "except" - which brings us to the one rule that governs everything else.

Workgroups only ever add

There is no "deny" in a workgroup. A workgroup cannot remove a permission, hide a printer, or narrow anything the member already had. Turning a permission off inside a workgroup simply means that workgroup doesn't contribute it - it does nothing to the member's user group or their other workgroups.

This is deliberate, and it's what makes workgroups safe to hand out. Adding someone to a workgroup can never break their existing access, so you never have to reason about the order they were added in, or which one "wins". Nothing wins; everything adds.

The practical consequence: if you need someone to have less, that belongs in their user group, not in a workgroup.

What a workgroup can and can't grant

A workgroup can only grant permissions from an explicit allow-list of workflow and resource permissions - printing, pausing, cancelling, the queue, the slicer tools, filament, cameras, print history, printer calibration and so on. The editor shows the exact count for your account, in the form "8 / 72 enabled".

Organization authority stays on user groups, permanently. A workgroup can never grant:

• Managing users - inviting, deleting, changing someone's group
• Managing user groups and workgroups themselves
• Managing the subscription, billing or invoices
• Managing API keys, webhooks or custom fields
• Editing organisation or registration settings
• Viewing the audit log, or exporting data
• Access & security settings
• Exemption from IP restrictions or device approval

You will usually never miss these. They are the permissions that decide how the account is run, and the whole point of a workgroup is that handing someone a key for a term shouldn't quietly make them an administrator. If a person genuinely needs one of these, that's a statement about their role, so it belongs in their user group.

Two more boundaries worth knowing:

• "Access all printers" is a user-group-only setting. A workgroup can only ever add the specific printers, printer groups and printer models it names. A workgroup cannot silently open the whole farm.
• New permissions start out user-group-only. When we ship a new permission, it isn't automatically assignable by a workgroup - somebody reviews whether it's safe to hand out that way first. So the allow-list grows deliberately, not by accident.

Creating a workgroup

1. Open Settings → Organization and find the Base roles & workgroups card.
2. Switch to the Workgroups tab and click Create workgroup.
3. Give it a name and a short description. The description is what other admins will read when they're deciding whether to put someone in it, so say what it's for, not what it contains.
4. Under Additive permissions, turn on what this workgroup should contribute. Leave everything else off - remember that off means "doesn't contribute", not "denies".
5. Under Printers unlocked by this workgroup, pick the printers, printer models or printer groups it should open up. Leave it empty if the workgroup is purely about permissions.
6. Optionally add allowances (see below).
7. Save.

Each workgroup in the list shows its permission count, printer targets, and whether it has SSO mappings, allowances or a permission base - so you can audit the whole picture without opening each one.

Giving a member a workgroup, permanently or temporarily

1. Open the Users page and find the member.
2. In their row actions, choose Manage workgroups.
3. Tick the workgroups they should be in.
4. For each one, optionally set:
5. • Active from - leave empty to start immediately, or pick a future date to schedule the access.
   • Expires after - leave empty for no expiry, or pick a date and it revokes itself.
5. Click Save workgroups.

Each row shows an Active or Inactive badge, so a workgroup that's scheduled for next month, or one whose term has ended, is obvious at a glance. An inactive workgroup contributes exactly nothing - no permissions, no printers, no allowance - and starts contributing again the moment its window opens, with no further action from you.

To do this for a lot of people at once, select the members in the Users table and use the bulk Set workgroups action, which can add, remove or replace workgroups for up to 500 members and takes the same shared dates.

You can also assign workgroups at invite time - on an email invite or a shareable join link - so people arrive already in the right ones.

Where workgroup membership comes from

A workgroup membership can be asserted by several different authorities, and each one holds its own independent claim:

This matters more than it looks. Because the claims are independent, removing one never removes another. If a student is in the Robotics Club workgroup both because your identity provider says so and because a teacher added them by hand, then dropping them from the IdP group leaves the teacher's grant standing - and they keep the access. The dialog shows every claim on a membership and which source each came from, so you can see exactly why someone has what they have.

The reverse is also true, and is the usual "why did this come back?" answer: manually removing an access that SSO or a class asserts will simply be re-asserted the next time that source syncs. To remove it for good, remove it at the source.

Keeping SSO and SCIM in sync

Workgroups have full single sign-on support, and they're where SSO gets genuinely expressive.

• Open a workgroup and add one or more SSO mapped groups - the group names or IDs your identity provider asserts.
• On every sign-in, SimplyPrint reconciles that connection's claims: every workgroup whose mapping matches a group the user is currently in is granted, and any this connection previously granted but no longer matches is dropped.
• Your identity provider stays the source of truth, with no scheduled job and no manual cleanup.

The important difference from user groups: SSO assigns exactly one user group, but as many workgroups as match. So your IdP can express "this person is a Teacher" and "this person is in the robotics group, the laser-trained group and the department admins" in one assertion - which is usually impossible to model with a single role.

Everything the connection didn't assert is left alone: a manual grant, a class grant or an Academy grant on the same workgroup is untouched by an SSO sync. And if a member moves from just-in-time SSO to SCIM provisioning (or back), ownership of the claim moves with them instead of leaving a stale duplicate behind.

Workgroups from school classes

On School accounts, a class can grant workgroups to everyone on its roster. Put the workgroups on the class once, and every student in it holds them for as long as they're in the class.

These grants are derived, not copied - they're computed from the roster and the class dates each time access is checked. Adding a student to a class gives them the class's workgroups immediately, removing them takes it away immediately, and there is no sync step that can drift or be forgotten. The class's start date and the student's own end date bound the grant automatically.

Basing one workgroup on another

When you build a workgroup, you can pick another workgroup as its permission base. That copies that workgroup's permissions in as a starting point, and you're then free to change anything you like - the copy is yours.

It is a copy, not a live link. Editing the original later does not silently reach into everything derived from it. Instead, when you edit a workgroup that others are based on, SimplyPrint offers to push the change down to them, so you stay in control of when that happens. The card shows both directions - "Based on X" and "Base for N workgroups" - so the relationships stay visible.

Only permissions are copied. Memberships, printer access, SSO mappings and allowances are never inherited, and a workgroup can't be based on itself or form a loop.

Workgroup allowances: personal and shared

If your account uses quotas and limits, a workgroup can carry allowances too, in two distinct shapes:

• Personal - every member of the workgroup gets this much each. "Everyone in Robotics Club gets an extra 2 kg a term."
• Shared - the whole workgroup draws from one pool. "The robotics club has 20 kg between them this term." Every active member's usage comes out of the same bucket, so it runs out for everybody at once.

When someone gets the same kind of personal allowance from their user group and one or more workgroups, an account-wide setting decides how those combine:

• Add contributions together - a 1 kg student allowance plus a 2 kg robotics allowance gives them 3 kg.
• Use the highest contribution - the same two allowances give them 2 kg.

You can also set optional per-user caps by allowance type and material, applied after the merge - so ten 1 kg workgroups can still be capped at 5 kg per person. Shared pools are always kept separate from this merge, because a pool belongs to the workgroup rather than to any one member.

Shared cost pools can additionally act as an enforced prepaid balance, which is the usual shape for a department or a club with its own budget.

Workgroups deliberately don't carry user-group-level safety policy - fixed per-job limits, balance exemptions and similar stay on the user group, so a workgroup can top someone up but never quietly disable a guard rail.

Deleting a workgroup

Deleting a workgroup removes it from every member, class and invitation that used it. Those members keep their user group and every other workgroup - only this one's contribution disappears.

Two things to expect:

• A workgroup that others used as their permission base can be deleted normally. Because the base was only ever copied in, those workgroups keep every permission they were given - all that disappears is the link recording where it came from.
• A workgroup that has allowance history is archived rather than erased, so past usage and reporting stay intact. It stops granting access immediately either way.

Good to know

• Workgroups count toward your plan's roles-and-workgroups limit, together with user groups. Accounts already over a newly introduced limit are grandfathered.
• The account owner is unaffected. Owners already have full access, so workgroups have nothing to add for them.
• Managing a member's workgroups needs both "Can change user rank" and "Manage user groups", and you can only do it for members whose user group you're allowed to manage - the same seniority rule that governs user groups. The account owner can't be managed this way.
• Changes take effect immediately. There's no cache to wait out and no need for the member to sign out and back in.
• Nothing about your existing setup changes by enabling workgroups. A member with no workgroups behaves exactly as they always did.

Related articles

• User groups and permissions: what each one controls
• Managing your users: the Users page
• How to invite users to your account
• Give a member temporary access
• SAML single sign-on: user groups, group mapping, and teacher mapping
• The quotas & limits feature

Updated on: 20/08/2026