External Against Internal
External and internal accounts use the same machinery and want different treatment almost everywhere.
Where to find it
Architect Panel → Security:
- Disabled User Accounts — accounts closed administratively
- Blocked User Accounts — accounts banned after failed sign-ins
- Permissions — what a group grants
Architect Panel → Configuration:
- Site Settings — registration and login settings
Where they differ
| Internal | External | |
|---|---|---|
| Created by | An administrator, usually | Themselves, usually |
| Default access | Role-based, meaningful | Minimal, earned by verification |
| Sign-in route | Directory or single sign-on | Local or social |
| Leaver process | Exists | Rarely |
| Support | An internal desk | You, by e-mail |
| Frequency of use | Daily | Occasionally |
Separate default groups
The most important consequence. Accounts arriving by different routes should not land in the same place — somebody an administrator created has been vouched for; somebody who filled in a form has not.
Separate sign-in expectations
Staff behind single sign-on get your organisation's policy applied automatically. External users need their own arrangements — and forcing a second factor on a member of the public who signs in twice a year has a real cost in abandonment that it does not have for staff.
Match the control to the value of what the account can reach.
Support is asymmetric
A member of staff who cannot sign in asks a colleague. An external user who cannot sign in either contacts you or gives up — and most give up, silently.
That means self-service recovery matters far more externally, and a lock-out you would tolerate internally is lost business or an unmet need.
Lifecycle
Staff accounts end when somebody leaves. External accounts have no natural end, so they accumulate — and each holds personal data you are responsible for. Decide a dormancy policy, and apply it.
Do not let them share a group
An easy mistake with serious consequences: a group granting something internal, containing external accounts because somebody added a broad default. Keep the two populations' groups distinct enough that this cannot happen by accident.
Review them separately
They have different risk profiles and different failure modes. An access review that treats them as one population will under-scrutinise the external side, which is the larger and less governed of the two.
Worked example
An organisation runs staff accounts through single sign-on with a second factor and role-based groups, and external accounts self-registered into a minimal group with verification to upgrade. Group naming keeps the populations obviously distinct, and external dormancy is reviewed annually with a warning before disabling.
Recommendations
- Separate default groups per arrival route.
- Match sign-in friction to what the account can reach.
- Invest in self-service recovery for external users.
- Review the two populations separately.