User Accounts

Every person who logs in to your ActiveManage instance has a user account. Accounts hold credentials, profile fields, security group memberships, 2FA configuration, and audit history. The platform's user management is built around a single users table that serves both your internal admin staff and your external end users — the difference between them is membership in different security groups, not a different storage location.

What a user account stores

The standard set of fields on every user account:

• Email address — typically also the username, if email-as-username is on (the platform default).
• Hashed password — using bcrypt or Argon2id depending on PHP version. Passwords are never stored in plain text.
• Names — first name, last name, display name.
• Contact details — phone number for SMS 2FA, optional postal address.
• Profile picture — uploaded image shown across the platform wherever the user is identified.
• Custom user fields — any additional columns you've added via Custom User Information Fields.
• Security group memberships — the user's effective permissions come from the union of these.
• Login history — last login timestamp, last login IP, password-change history.
• 2FA configuration — TOTP secret, SMS phone number, registered devices.
• Tenant assignment — for multi-tenant installs, which tenant the user belongs to.

Two flavours of account

Functionally there's one users table, but in practice you'll think of accounts in two groups:

Internal accounts

Your admin and staff users — people who log into the admin panel at /am.admin/ and configure the platform or use it for internal operations. Typically members of staff-specific security groups (Admins, Engineering, Sales, etc.). Often require 2FA.

External accounts

Your end users — customers, partners, public visitors who log in to your application's user-facing pages. Typically members of just the All Users group plus role-specific external groups (Customer, Subscriber, Partner). 2FA is often optional for these accounts.

The accounts share the same underlying record structure; what differs is which security groups they're in and what permissions those groups grant.

Where they're managed

From the Admin Panel sidebar, click All Users. The list shows every user account with columns for name, email, last login, and a few action buttons. Search by name or email; filter by group, login activity, or any custom user field.

For a specific user, click into their row to see their full profile — all the stored fields, their group memberships, their login history, and admin-only actions like reset password and disable account.

Three real-world account configurations

Example 1: B2B SaaS — admins and customer users

Internal accounts: 5 admins (in Super Administrator and Engineering groups). External accounts: 500 customer users (in All Users + Customer Admins or Customer Users). 2FA forced for admins, optional for customer users.

Example 2: Internal-only business app

500 internal accounts across multiple departments. No external accounts. Heavy use of department-specific groups. 2FA forced for finance and HR groups, optional for others.

Example 3: Public consumer app

10 admin accounts. 50,000 external consumer accounts (in All Users only). Email-as-username on. 2FA optional. Heavy use of self-registration with default group assignment.

From the All Users list, click New User in the top right. The new-user form opens with the standard set of fields plus any Custom User Information Fields you've added.

Required fields

• Email address — will be the username if email-as-username is on (the default).
• Initial password — sets the user's first password. Either pick one yourself, generate a random one (if your platform's UI provides a button), or use the "send setup email" option that has the user pick their own.
• Security group(s) the user should belong to — at minimum All Users.

Optional fields

Name, phone number, profile picture, and any custom user fields you've added — department, employee ID, dietary preferences, whatever's relevant to your application.

The setup-email approach

Rather than picking a password yourself, the more common pattern is to send the new user a setup email containing a one-time link to set their own password. This avoids you knowing their password (which is a security improvement) and lets the user pick something memorable.

Toggle the "Send setup email" option on the new-user form. The platform will:

1. Create the account with a random unguessable password.
2. Generate a setup link with a time-limited token.
3. Send the link via the configured New User Registration Email Template.
4. When the user clicks the link, they're prompted to set their password.

Welcome email

If Send New User Registration E-mail (Admin Created) is enabled in Site Settings, the user gets a welcome email immediately on creation — including their login link and (depending on configuration) either their initial password or a setup link. The exact template is configurable.

If this setting is disabled, you'll need to communicate the credentials to the user out-of-band (in person, via Slack, via a separate email you write yourself).

Three real-world creation flows

Flow 1: New employee onboarding

HR creates the account with the employee's email, department, and initial security groups. "Send setup email" is on — the employee picks their own password from the email link. They're added to the relevant department group and given Browse permissions on the customer table on day one.

Flow 2: B2B customer admin provisioning

Customer success creates the account for a new customer's admin user. Picks initial password manually ("Welcome2026!") and communicates it via a secure channel. Customer admin is added to the Customer Admins group; they then log in, change their password, and start adding their own team via self-service.

Flow 3: Quick demo account

Sales creates a demo account for an evaluating prospect. Sets password to a known demo value ("DemoUser2026"). Adds to the Restricted Accounts group to limit what the prospect can do. Account is auto-disabled after 30 days via a scheduled Task.

Tip: Even when you set an initial password manually, the new user should change it on first login. Some installs configure the password as one-time so the platform forces a change. Combine with required-2FA-on-first-login for stronger onboarding.

For public-facing apps that need users to sign themselves up, enable self-registration in Site Settings. The self-registration form sits on your login page (or a dedicated sign-up page) and gives anonymous visitors a path to create their own account.

Registration mode

Three options under Site Settings → User Account & Login → User Registration Mode:

Disable all account creations

The strictest mode. Even admins can't create accounts through the standard form. Useful for installs where accounts come exclusively from an external identity provider (SSO) or an API-driven provisioning system.

Only admins can create accounts

Admins create accounts via the New User flow; no public sign-up. Suitable for internal apps where you control who has access.

Anyone can register an account

Self-serve sign-up. The login page shows a "Don't have an account? Sign up" link. Anyone (including anonymous visitors) can register themselves.

Default security groups

When a user self-registers, they're automatically added to the security groups configured under Site Settings → User Account & Login → Default Security Groups. Set these so new sign-ups have appropriate (but limited) access from the moment they register.

Typical configurations:

• Consumer app: All Users + Free Tier.
• B2B free trial: All Users + Trial Customer + Restricted Accounts (limited until they upgrade).
• Public knowledge base: All Users (read-only access to articles).

Welcome email

The Send New User Registration E-mail (Self-registration) setting controls whether self-registered users get a welcome email, and which template is used.

Standard welcome emails include:

• A greeting and confirmation of the account creation.
• The user's email (so they know what they signed up with).
• A link back to the login page.
• Optional: their initial setup steps, branded onboarding content, links to help.

Validation on registration

The registration form validates:

• Email is unique (no duplicate accounts).
• Email is in valid format.
• Password meets length/complexity requirements (if configured).
• Any required custom user fields are filled in.
• The user has accepted any terms or privacy notice (if you've added a Tickbox field for it).

Anti-spam measures

Public registration is a spam target. Three layers of defence to consider:

1. reCAPTCHA on the registration form

v2 Checkbox, v2 Invisible, or v3 — block automated registration attempts. Requires reCAPTCHA keys configured in Site Settings.

2. Email verification

The platform can send a verification email and require the user to click a link before their account is fully activated. Spam accounts that use fake emails never receive the link and stay un-verified.

3. Manual approval queue

For very sensitive apps, configure the registration to require admin approval before the account becomes active. New registrations go into a Pending Approval queue; admins review and accept or reject.

Admins can reset any user's password without knowing the current one. This is separate from the user-initiated password reset flow (which requires email access) and is always available regardless of the Enable Password Resets Site Setting.

Admin-initiated password resets are essential for:

• Users who've forgotten their password and either can't access their email or don't want to wait for a reset link.
• Users whose email has been compromised — admins can reset the password and re-secure the account.
• Account recovery after a long absence (annual leave, sabbatical, etc.) where the user can't remember what they used.
• Bulk operations on accounts that need to be reset for policy reasons.

How to do it

From the All Users list, click into the user. Their profile opens. There's a Reset Password button in the profile actions. Click it and you get two choices:

Option 1: Set a new password manually

You type a new password directly. The user can then log in with that password and (typically) change it themselves after first login.

Pros: instant — no waiting for emails to arrive. Cons: you know their password, which is a security concern; you have to communicate it to them somehow.

Option 2: Send the user a password-reset email

The platform generates a one-time reset link with a time-limited token and emails it to the user. They click through and pick their own password.

Pros: you never know their password; reset is self-service from there. Cons: relies on email delivery; user has to wait.

Audit trail

Every admin-initiated password reset is recorded in the audit log — who reset, whose password, when, and which option was used. Useful for compliance and for incident review ("who reset the CFO's password last Tuesday?").

The audit entry is visible from the user's profile under the History tab. It's also surfaced in the platform's main audit log for cross-user investigation.

Force change on next login

Optionally mark the new password as temporary. The platform then forces the user to pick a new password the first time they log in. This is the recommended pattern for admin-set passwords because:

• You don't end up with the admin and the user both knowing the password long-term.
• The user is more likely to pick something they'll remember if they choose it themselves.
• It's a clear signal to the user that the credentials they have are temporary.

Three real-world reset scenarios

Scenario 1: User locked out and can't access email

Admin resets the password manually, communicates the new password via phone, marks it as one-time. User logs in, sets their own password, continues.

Scenario 2: User's email was compromised (they tell you they think someone has access)

Admin resets the password manually (so the attacker can't intercept a reset email), invalidates all active sessions for the user, requires 2FA setup on next login.

Scenario 3: Annual security review found weak passwords

Admin runs a bulk reset Task that sets every affected user's password to one-time-temporary and emails them the reset link. Users pick new (stronger) passwords on next login.

Warning: Be very careful about who has admin reset privileges. The combination "can reset anyone's password" + "can log in as that user afterwards" is effectively account takeover. Keep the count of users with reset permissions small, audit it quarterly, and force 2FA on admin accounts.