A security group is a named collection of users that the platform treats as a unit for access-control purposes. Rather than granting permissions to individual users one at a time, you grant them to groups and then add users into those groups. The math behind that single decision saves a vast amount of administrative effort once your user count grows beyond a handful.
Every permission in ActiveManage — to read a datastore, edit a field, see a page, run a row-level action — is granted to one or more security groups. A user's effective permissions are the union of every group they belong to. That's how you model real-world role hierarchies inside the platform without writing any custom code.
Built-in groups that ship with every install
The platform ships with five security groups already configured. You can't delete them (the platform relies on them internally) but you can add and remove users freely:
- All Anonymous Visitors — virtual group; any unauthenticated visitor is treated as a member. Permissions granted here apply to public-facing pages and forms. Use it carefully: anything you grant to this group is effectively public.
- All Users — every authenticated user is automatically a member. Use this group for permissions that anyone logged in should have, like reading their own profile or seeing the public help section.
- Restricted Accounts — accounts in this group have limited access. Useful for trial users, accounts pending verification, or recovering accounts that have been temporarily limited.
- Store Owners — vendor accounts in the Carts system. Members get vendor-management capabilities (listing products, fulfilling orders, viewing their own sales reports).
- Super Administrator — full platform access. Treat membership of this group as carefully as root access on a server.
Custom groups for your application
Beyond the built-ins, create as many groups as your application's role model needs. There's no practical limit — most installs have somewhere between 5 and 50 custom groups.
Three example role models from real applications:
Example 1: Internal business app
A typical internal app might have groups for each function plus role tier: Finance Team (Read), Finance Team (Write), HR Team, Sales Team, Engineering Team, Customer Success. Each business function has read and write tiers so junior staff can see but not edit.
Example 2: Multi-tenant SaaS
For a SaaS product with customer organisations: Customer Admins, Customer Users, Customer Read-Only, plus internal groups for your own staff (Support, Engineering, Account Management). The customer-side groups govern what a tenant's own users can do within their tenant.
Example 3: Marketplace
For a multi-vendor marketplace: All Vendors, Verified Vendors, Pending Verification, Tier 1 / 2 / 3 (by sales volume), Customers, Customer Service. Tiered groups let you grant escalating capabilities as vendors mature.
Union, not intersection
Here's the most important behavioural rule about groups: a user's effective permissions are the union of all their group memberships. If any group they're in grants Read on a datastore, they can read it — even if other groups they're in are silent on that table.
That means there's no "deny" concept. Permissions are grant-only. To restrict a user, remove them from the group that grants the access. Don't try to add them to a "denied" group — that's not how the model works.
Note: The grant-only model is intentional. It makes audit trails much cleaner — "this user has access because they're in this group" is a clear answer, where deny-overrides would require chasing through every group to confirm none of them deny.