Permissions cascade in well-defined ways in ActiveManage. Understanding the cascade helps you configure efficiently without redundant entries and prevents the most common class of permission bug: "I granted access but the user still can't see it".
The cascade rules in one paragraph
Datastore-level permission is the baseline. Field-level permissions override the baseline only for the fields they explicitly reference. Row-level security applies on top of both — even if you have Read at the datastore level and Read on every field, row-level security still narrows which specific rows you can see. A user's effective permissions are computed by combining (union) every group they belong to.
From datastore to field
A field with no explicit field-permission row inherits the datastore-level permission for the user's groups. Only define field-level permissions where you want to differ from the default.
So if the Finance Team has Read on the Customers datastore, and there's no field-permission row for the Salary field for the Finance Team, the Finance Team can read the Salary field. Add an explicit "No Access" row to hide it for Finance specifically; leave it out to inherit Read.
From group to user
A user's effective permissions are the union of all their security groups' permissions. If any group they're in grants Read, they can read; if any group they're in grants Write, they can write.
Practical consequence: a user in both "Read-Only Staff" and "Editor" groups effectively has the Editor's combined permissions. Don't create a "Restricted Editor" group expecting it to override the broader Editor group's grants — group memberships add, they don't subtract.
The grant-only model
Without any explicit grant, the answer is no. Granting in one group is enough to allow; you don't need to repeat the grant for other groups the user is in.
Three implications:
- To restrict a user, remove them from the group that grants the access. Don't try to "deny" them in a group they're in.
- There's no precedence rule — every grant is equal. You don't need to think about "which group wins".
- Audit is simple: "this user has access because they're in this group" is always the answer. The grant-only model makes audit trails easy.
Three worked-example scenarios
Scenario 1: Adding a new role to existing groups
A user has been promoted from Sales Rep to Sales Manager. They keep their Sales Team group membership (so they continue to see their own old records) and gain the Sales Managers group (which adds visibility into the broader department). The cascade resolves to: their own records (from Sales Team rule) plus the whole department's records (from Sales Managers rule). Both unioned.
Scenario 2: Restricting a previously-permissive user
Someone moved out of a role where they had broad access and should now have narrower access. Don't add them to a "restricted" group — that won't override their existing memberships. Remove them from the group that grants the broader access. Their effective permissions drop immediately on their next request.
Scenario 3: Building hierarchical access
Three groups, each granting progressively more. "All Users" (basic read-only on everything), "Editors" (write access on most things), "Admins" (everything plus delete). Add a user to Editors, they get All Users + Editors permissions. Promote them to Admin, they get all three. No need to remove the lower groups when promoting — the union handles it cleanly.
Tip: When debugging a permission issue ("why can't this user see X?"), check the user's group memberships first, then check each group's permissions for the relevant datastore and fields. The answer is always somewhere in that chain — there's no fourth layer to forget about.