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.