Everything in your workspace hangs off three things: your organization, the workgroups inside it, and the access profile each workgroup carries. A workgroup is whatever your organization actually routes work to — a position somebody staffs (“AOG Desk”, “MCC”), an operational team (“Line Maintenance”, “Technical Records”), or a shift or crew (“Night Shift”). People join workgroups, and that is where their access comes from.
The four pieces
Your organization
The company itself. Stations, aircraft, contacts and people all sit inside it, and nothing crosses to another organization unless you send it there.
Access profile
A named bundle of permissions. It is not attached to a person: it is attached to a workgroup, and reaches people through it.
Workgroup
A position that outlives whoever is filling it: somewhere to be reached at, a team or crew to be routed to, or both. One person in it is normal, and so is thirty. Renaming one is free, and archiving is how you retire it — workgroups are never deleted.
Member
Somebody with a sign-in. A member belongs to one or more workgroups, and holds whatever those workgroups’ access profiles add up to.
How a person’s access is worked out
-
Start from every workgroup the member is in
Archived workgroups and archived memberships do not count — an archive is history, not a live grant.
-
Add their access profiles together
Take the access profile each of those workgroups carries and add them all up. A member in three workgroups holds everything all three grant.
-
Add anything granted to that person directly
A grant written against one member, as an exception.
-
Remove anything denied to that person directly
A denial always wins — including over a permission a second workgroup granted.
That is the whole rule. Apart from the organization’s owners, there is nowhere else access can come from, which is why “why can this person do that” always has one answer.
A worked example
Dilek is in two workgroups:
| Workgroup | Access profile | Grants |
|---|---|---|
| CGN MCC | Maintenance Control | View stations, search providers, send messages |
| Case Officers | Inbound Service | View stations, manage stations, send messages |
Added together, Dilek can view stations, manage stations, search providers and send messages — “manage stations” comes from Case Officers alone, and one workgroup granting it is enough.
Dilek’s manager then adds one exception: manage stations — denied.
Dilek can now view stations, search providers and send messages. The denial removed a permission that a workgroup genuinely granted, which is what a denial is for. Taking Dilek out of Case Officers would have removed “send messages” too; the exception was the narrower tool, and that is the test for when to reach for one.
Worth knowing
-
Owners sit outside all of this.
An owner holds every permission by being an owner — no workgroup, no access profile, no exception — and is not listed with the team. Owners are set up by AOG HUB; contact support to change them. The organization always keeps at least one, which is what stops it locking itself out.
-
A workgroup can grant nothing, and that is normal.
Leave the access profile empty and the workgroup still exists — it can be messaged, routed to and listed in the directory. Most contact workgroups want exactly that: no portal access at all.
-
Administrator cannot be partly taken away.
An access profile holding Administrator grants everything, and a “deny” exception on somebody who has it does nothing. To restrict somebody, take them out of the workgroup that grants it rather than denying permissions one at a time. Only an owner can hand Administrator on, and anyone else managing access can hand on only the permissions they hold themselves.
-
Exceptions are the exception.
A permission granted or denied to one person is invisible from the workgroup they are in, so the more you use them the harder your setup is to read. Change the workgroup when the change is about the job — if three people need the same exception, you are missing a workgroup.
-
Build it in order.
Access profiles first, then workgroups, then people — a member cannot be created without a workgroup to join, and a workgroup grants nothing until it carries an access profile.
Why not just give people roles?
Because then “why can this person do that” has as many answers as there are people.
Access hanging off the workgroup means the answer is always the same shape: these workgroups, carrying these access profiles, plus any exception written against the person. You can read somebody’s access off the workgroups list without opening their profile, and changing what a job can do is one edit rather than one edit per person doing it.
Where you do each of these
- Administration → Access profiles Name a bundle of permissions, and pick what is in it.
- Administration → Workgroups Create a workgroup, give it an access profile, and choose who is in it.
- Administration → Users Invite colleagues, put them in workgroups, and add an exception only if one person genuinely needs one.