External Accounts

External Accounts

External accounts belong to customers, members, applicants or partners — people outside your organisation using your application.

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 → Security:

• User Verification — establishing something about them
• Record Access Roles — restricting them to their own records

The assumptions that do not carry across

Almost everything you can rely on for staff is untrue externally:

• You cannot train them. The interface has to explain itself.
• You cannot reach them reliably to fix a problem.
• They use the system rarely, so they forget how it works between visits.
• You do not control their device, browser or connection.
• They have no support desk — you are it.

An interface that works for staff who use it daily can be unusable for somebody visiting twice a year.

They must see only their own records

The security requirement that defines external access. Row-level access is what enforces it, and it needs to be right before anybody external signs in — not adjusted afterwards.

Test it as a real external account, with more than one such account, and confirm one cannot reach the other's data.

Volume is not under your control

Anybody may register. Plan for junk sign-ups, for people creating duplicate accounts because they forgot the first, and for accounts that are never used again.

Expect them to forget

Somebody using your portal annually will not remember their password, whether they had an account, or which e-mail address they used. Make recovery obvious and forgiving — and consider whether a sign-in is needed at all for what they are doing.

Design for infrequent use

No jargon, no assumed context, obvious next steps, and a clear statement of what happens after they submit something. Staff-facing terseness reads as opaque to somebody who has never seen it.

Accessibility matters more here

You do not know who your external users are. Some will use screen readers, some will need large text, some will be on old devices and poor connections. For a public service that is a legal consideration as well as a practical one.

Their data is their data

External accounts usually mean holding personal data about members of the public, which brings retention, subject access and disclosure obligations. Decide those before launch rather than when the first request arrives.

Worked example

A council portal restricts residents to their own cases through record access roles, tested with two accounts to confirm neither could reach the other. The interface avoids internal terminology, states what happens after submission, and was tested with a screen reader before launch.

Recommendations

• Enforce row-level access before anybody external signs in.
• Test with two external accounts, not one.
• Design for somebody who visits twice a year.
• Settle retention and subject access before launch.

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

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.