Inheritance

A permission group can build on another. The child gets everything the parent has, plus whatever is added to it — so common rights are defined once instead of copied into every group that needs them.

Why use it

Without inheritance, five role groups that all need basic read access each carry their own copy of those keys. Adding a sixth basic right means editing five groups and missing one.

With inheritance, a Base group holds the common rights and every role inherits from it. Adding a right to Base gives it to all of them at once.

Setting it up

Select a group and use the Inheritance section to choose what it builds on.

A workable arrangement for most sites:

Base                     read access everyone needs
├── Operator             + day-to-day floor actions
│   └── Supervisor       + acknowledge, override, report
├── Analyst              + query, aggregate, export
└── Administrator        + user and permission management

Each level adds; nothing takes away.

Inheritance only adds

There is no way for a child group to remove something its parent grants. If a role needs less than the base, the base is too broad — move the extra rights out of it into the groups that actually need them.

That constraint is what keeps inheritance readable. A hierarchy where a child could subtract would require reading the whole chain to know what someone holds.

Keep the chain short

Deep chains are hard to reason about. Two or three levels is usually enough, and beyond that it becomes difficult to answer "why does this person have that right?" without tracing several groups.

If you find yourself needing depth, consider assigning two groups to a user instead — rights are the union of everything assigned, so composition often expresses what a deep hierarchy was trying to.

Changing a parent affects every child

Editing a group that others inherit from changes all of them, and everyone holding any of them. Check which groups inherit before editing something near the root.

The failure mode to avoid: adding a convenient right to Base because one role needs it, thereby granting it to everybody.

Seeing the effect

The group's own key list shows what it contributes. To see what a person ends up with, use The Security and Access Report, which resolves inheritance and reports the effective result — the thing an access review actually needs.

What is recorded

Changing inheritance is audited under the permissions administration type, like any other change to a permission group. See Reading the Audit Trail.