User Accounts (External)

External user accounts are the accounts your customers, members or end-users sign in with — distinct from internal staff accounts. ActiveManage keeps the two populations cleanly separated so that customer features (self-service registration, simplified profile pages, public-facing branding) don't leak into the staff experience.

How External Accounts Differ

• Different sign-in page: External users hit a public-friendly login URL (e.g. /login) while staff use /staff-login. The two pages can have entirely different branding.
• Different security groups: External users default to a customer-oriented group with no admin permissions.
• Self-service registration: External users can typically sign themselves up; staff are created by administrators.
• Different password policies: External password rules can be more lenient (e.g. 8 characters minimum) than internal (e.g. 14 characters + complexity).

Where External Accounts Are Stored

Both internal and external accounts live in the .users table. A flag distinguishes them, and you can also use the scope column to segment customer accounts by tenant or organisation.

Example Configurations

• Marketplace: Two roles inside external — Buyer and Seller. Buyers register freely; Sellers go through an application flow.
• Membership site: External accounts are tied to subscription packages. Login is gated by an active subscription check.
• Healthcare portal: Patients are external; clinicians are internal. Different identity providers (email/password for patients, Azure AD for clinicians).
• B2B SaaS: Customer organisations have their own scoped external user lists. One client's users cannot see another's.

Note: Promoting an external user to internal staff is a deliberate manual step. The platform refuses to merge accounts automatically because permissions could be elevated unintentionally.

Internal (staff) and external (customer) accounts share an underlying users table, but their behaviour, defaults and access scope diverge in important ways. This article summarises every meaningful difference so you can decide where each new user belongs.

The Differences in Detail

• Sign-in URL: Internal at /staff or your admin subdomain; external at the public root / or /login.
• Registration: Internal accounts are created by an administrator. External accounts can self-register (when enabled), receive an invitation, or be imported in bulk.
• Default security group: Internal defaults to “Staff (Basic)”; external defaults to “Customer”.
• Password rules: Internal typically enforces longer minimum length, complexity and rotation. External rules are configurable but tend to be lighter to reduce friction.
• 2FA: Internal often mandatory by group policy. External is opt-in or required only for sensitive sections.
• Idle timeout: Internal sessions expire faster (e.g. 30 minutes) than external (e.g. 4 hours) by default.
• Visible menus: Internal users see the Architect Panel and back-office menus; external users see only the customer-facing app.

Worked Examples

• Marketplace example: A buyer registers, receives a welcome email and is dropped into the catalogue. Internally an admin clicks “New staff” and chooses a role. The two flows never overlap.
• Mistake to avoid: Tagging an external user with an internal group inadvertently exposes admin menus to that customer. Always double-check group assignment when bulk-importing.
• Promotion scenario: A customer is hired. Create a brand-new internal account for them rather than converting the external one — keeps the customer's order history attached to the right identity.
• Hybrid scenario: Partner integrators get a “Partner” group with limited internal access — still flagged as internal but with explicitly granted menus only.