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
/staffor 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.