Security Groups

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.

Creating a security group is the fast part — the form is short and there's only one required field. The harder decisions are what to name the group and how it'll fit into your overall role model. Get those right at creation time and you'll save yourself the awkward future renaming.

The mechanics

From the Admin Panel sidebar, click User Groups. The list of existing groups appears. Click New User Group in the top-right corner. Fill in the form:

• Group Name — descriptive name shown wherever this group is referenced. Required.
• Description — optional but recommended. A one-line note explaining what the group is for and who should be in it.
• Default group on registration — toggle (rare) that adds new self-registered users into this group automatically. Most installs handle this via the global Default Security Groups Site Setting instead.

Save. The group is created immediately and you can start adding users and granting permissions.

Naming conventions that scale

Names matter more than you might think. Three principles to follow:

1. Use role-based names, not person-based

Good: "Finance Team", "Engineering Leads". Bad: "Alice's Team", "Bob's Permissions". Person-based names rot the moment Alice or Bob leaves or changes role.

2. Be specific about scope

Good: "Finance Team (Read)", "Finance Team (Write)". Bad: "Finance Team" (when you secretly mean "Finance Team with write access but not delete"). Names that hide their full meaning lead to permission mistakes.

3. Avoid abbreviations and acronyms

Future-you (or a colleague new to the system) won't remember what "CSAOPS-T2" means. "Customer Success Operations Tier 2" is verbose but unambiguous.

Three real example group sets

Example 1: A 20-person SaaS startup

Customer Success Team, Engineering Team, Sales Team, Executive Team, All Employees, External Contractors. Five role-based groups for staff, one catch-all, and one for contractors with limited access.

Example 2: A 500-person enterprise app

Department prefix + tier: "Finance/Senior", "Finance/Junior", "HR/Senior", "HR/Junior", "Sales/Manager", "Sales/Rep", and so on. About 30 groups in total. Permissions are layered: junior groups grant a subset of senior groups.

Example 3: A B2C consumer app

Just three custom groups: Free Users, Paid Users, Cancelled Users. Plus the built-in All Users and Restricted Accounts. Membership in Paid Users is automated based on subscription state.

Adding the group to your permissions matrix

Once the group exists, the real work begins: figuring out which datastores, fields, pages, and actions it should have access to. Open the group from the User Groups list and use the Permissions tab — see the next article for the details. Plan to allocate at least 30 minutes per new group when you first set up your application's permission model.

Tip: Once your application's role model is settled, document it. A simple spreadsheet listing every group, what it's for, who's in it, and what major permissions it has, lives well alongside the platform itself and becomes the source of truth for future admins.

Adding users to security groups is how you actually make permissions take effect for individuals. The platform offers three different paths to do this, each suitable for different scenarios. Knowing which to reach for in which situation saves a lot of clicking.

Path 1: From the group's edit screen

The most common path when you're building out a new group or filling its membership in bulk. Open the User Groups list, click into the group, then go to the Members tab. Click Add User, search for the user (the picker uses type-ahead against name and email), select them, and they're added immediately.

Best for: setting up a brand-new group, or filling in a group's first batch of members.

Path 2: From the user's profile

When you're working with one specific user — onboarding a new hire, promoting someone, adjusting one person's access — start from their profile instead. Open the All Users list, click into the user, scroll to the Security Groups section, and click Add Group.

Best for: managing one user's full set of group memberships in one place.

Path 3: Automatically on registration

For self-registered users, the platform can auto-add them to chosen groups via two settings:

• Site Settings → User Account & Login → Default Security Groups — applies to every self-registration. Typically you'd include "All Users" plus any baseline role-specific group.
• Group-level "default on registration" toggle — alternative to the global setting if you need finer-grained control.

Best for: any flow where new users should land in a known starting role without admin intervention.

Bulk operations

For installs with many users, doing this one-at-a-time is impractical. Three bulk options:

1. CSV import via the User Groups admin

Upload a CSV with email addresses (one per row). Every matched user is added to the group. Useful for migrating from an existing system or for a one-off bulk reorganisation.

2. Rule-based auto-assignment

For ongoing rules ("every user with email ending @acme.com goes in Acme Customer"), set up a Task that runs nightly and assigns matching users to the right groups. The Task code is custom PHP but the pattern is straightforward.

3. API

For external systems that need to keep the platform's group memberships in sync with their own user management (HR system, identity provider), the API exposes group-membership endpoints — POST a user ID and a group ID to add, DELETE to remove.

Removing users

Removing is the inverse of adding. From either the group's Members tab or the user's profile, click Remove next to the membership. The removal takes effect immediately — the user's effective permissions are recalculated on their next request.

Warning: Removing a user from a group that grants admin permissions takes effect immediately and could log them out of admin pages mid-action. If you're rotating someone out of an admin role, do it during a quiet period or have them log out first to avoid surprise behaviour.

Every ActiveManage instance ships with five security groups that the platform itself relies on internally. You can rename them and add/remove users, but you can't delete them — the platform expects them to exist and references them in places you can't easily change.

Understanding what each one is for prevents an entire class of permission confusion. Don't repurpose them; create your own custom groups alongside if you need different role semantics.

All Anonymous Visitors

A virtual group. Any unauthenticated visitor (someone hitting a page without being logged in) is treated as a member. Permissions granted to this group apply to public-facing pages and forms.

What you typically grant: Read access to the marketing pages, Read access to public help articles, Write access to public Level-1 User Input Views (so anonymous users can submit contact forms). Be deliberate — anything you grant here is effectively public.

Three patterns that come up:

• Public website pages — Read on the relevant Page Builder pages.
• Public contact form — Write on the relevant UIV's underlying datastore.
• Public catalogue — Read on the products datastore (with row-level security excluding anything not flagged as public).

All Users

Every authenticated user is automatically in this group. There's no way to remove someone from it; if they're logged in, they're a member.

What you typically grant: Read on their own user record, Read/Write on their own preference fields, Read on universally-shared resources (announcements, common reference data, the help docs).

Restricted Accounts

Members of this group have limited access. Use cases:

• Trial users (limited access until they upgrade).
• Accounts pending verification (limited until email or identity is verified).
• Recovering accounts (limited after suspicious activity, until manually reviewed).
• Demo accounts (limited so they can't accidentally affect real data).

The platform doesn't grant any specific restrictions automatically — you configure what "restricted" means by granting (or, more often, not granting) specific permissions to this group.

Store Owners

The platform's built-in group for vendor accounts in the Carts system. Members get vendor-management capabilities: listing products in their own catalogue, fulfilling orders for items they sell, viewing their own sales reports.

For non-marketplace installs that don't use Carts as a multi-vendor system, this group exists but won't be referenced — leave it empty.

Super Administrator

Full access to everything. Members of this group bypass all permission checks. Treat membership of this group as carefully as root access on a server.

Best practices for Super Administrator membership:

• Keep it small. The platform's audit log shows who did what; that's only useful if there's a small enough number of people in this group that suspicious action narrows down to a few individuals.
• Use 2FA without exception. Compromise of a Super Admin account is catastrophic. Force 2FA for everyone in this group via the relevant group setting.
• Audit regularly. Review the membership of this group monthly. People change roles, leave companies — Super Admin membership outlives the reason it was originally granted.
• Personal accounts only. Don't have shared "admin" accounts; one Super Administrator account per person, traceable in the audit log.

Warning: Never delete the built-in groups. The platform's own code references them by name in several places — removing them will cause unpredictable failures. If you don't use one (e.g. Store Owners on a non-marketplace install), just leave it empty.