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.