Permissions decide who can do what in ActiveManage. Every action — reading a datastore row, editing a field, deleting a record, accessing a page, calling an API endpoint — is permission-controlled. Get the permission model right and your application is secure by construction; get it wrong and you'll have data leaks, unauthorised changes, and very awkward incident reports.
The permission model in one sentence
Permissions are granted to security groups (not to individual users), and a user's effective permissions are the union of every group they belong to. There's no deny mechanism — permissions are grant-only.
Three implications of that single rule:
- You can add a user to multiple groups and they get the union. Useful for layering roles.
- You can't "deny" a permission by adding someone to a restricted group; you remove them from the granting group.
- Audit is straightforward: "this user has access because they're in this group" is always the answer.
Three levels of granularity
The platform supports three increasingly fine-grained permission scopes:
Datastore-level
The broadest control. Decides whether a security group can read, write, edit, or delete rows on a whole table. Most permissions you configure will be at this level — "the Finance Team can read the orders table", "the Sales Team can write to the customers table".
Field-level
Narrows access within a datastore the user can otherwise see. Useful when different roles need different columns from the same table. For example: HR sees salary fields, line managers see role and start date, everyone sees name and email. Field permissions configure those exceptions.
Row-level
Restricts which specific rows a user can see or modify, even within a table they otherwise have access to. Typical use: "users can see only rows they created", "managers can see only rows from their department", "customers can see only their own orders".
Default-deny
Without an explicit grant, the answer is no. You don't need to "deny" things — anything you haven't explicitly allowed is implicitly forbidden. That's deliberate: it's much harder to accidentally over-share data when the default is locked-down.
Three example permission models
Example 1: Simple internal app
Two groups: Staff (can read/write the main tables), Admins (can also delete and manage users). Permissions are mostly at datastore level. Quick to set up, suitable for low-stakes applications.
Example 2: Multi-department business app
Per-department groups, each granted read/write only on tables relevant to their function. Field-level restrictions for sensitive columns (salary, performance ratings, customer card details). Row-level security on shared tables (each department sees their own customers).
Example 3: Customer-facing portal
Datastore-level grants for customers are limited (read-only on most things). Heavy use of row-level security to restrict customers to seeing their own data. Field-level on customer profiles to allow self-edit of some fields but not others.
Where you configure permissions
Permissions are configured per-datastore and per-resource:
- Datastore-level: Architect Panel → Datastores → click the Permissions button on a datastore.
- Field-level: Same screen, the Field Permissions tab.
- Row-level: Toggle Row-Level Security on the datastore's main settings, then configure rules under Permissions.
- Page / route permissions: On the Page Builder page or Friendly URL definition.
- API permissions: On the API Client configuration.
Tip: Start with datastore-level only. Add field-level and row-level rules only where they're genuinely needed — over-engineering the permission model up-front leads to a tangled mess that's hard to debug. Add complexity as concrete requirements emerge.