Skip to content

User Creation

Applies to: All subscriptions

Purpose

Create accounts that people can actually sign in to. The failure mode here is uninteresting and expensive: accounts created in bulk, activation emails that never arrive, and a day lost before anyone realises the cause is mail.

Audience

The system administrator, with the customer's project manager.

Prerequisites

  • Master Data Setup gate passed
  • A user list with real, individual email addresses
  • Intended role and registration access per user
  • Mail transport configured and tested

Steps

1. Prove the mail path first

Before creating anyone, trigger one message to a real mailbox and confirm it arrives in the inbox, not the spam folder.

Everything in this stage depends on it. Account activation, password reset and one-time codes all require a delivered email, and a mail failure produces no error anywhere — the accounts exist, nothing looks wrong, and the tickets say "my account does not work".

2. Create the first user and take them all the way through

Create one account. Activate it. Sign in as it. Only then create the rest.

This single step catches mail problems, address problems and activation problems before they are multiplied across forty accounts.

3. Create the remaining accounts

Field Guidance
Name As the person is known, for the audit trail
Email Individual and real. Not a shared mailbox, not an alias nobody reads
Role From Role Assignment
Registration access Only the registrations they work with

One account per person. A shared account destroys attribution, which is the property a compliance system exists to provide.

4. Create at least two administrators

Two administrators, at two different individuals, is the minimum. One administrator is a single point of failure that fails at the worst possible time: the person who could restore access is the person who is unavailable.

Do this in this stage, not later.

5. Grant registration access deliberately

Access is per registration. Grant the minimum:

Situation Access
A user at one site That site's registration only
A user covering several entities Those registrations
Group-level reporting Group-wide, as a deliberate decision
An auditor Whatever the audit scope covers

Users at a single site rarely need group-wide visibility, and access granted "to be safe" is rarely revoked.

6. Confirm each user can work

Have each user sign in and perform one real task. Do this before training, not during it — a training session that becomes an access-troubleshooting session wastes everyone's time.

Validation

Gate: this stage is complete when all of these pass.

Check Pass condition
Mail proven A message delivered to a real inbox, not spam
First account fully tested Created, activated, signed in
All accounts created Matching the agreed list
All activated Each user has signed in at least once
Individual accounts No shared accounts
Two administrators At two different individuals
Access is minimal Each user has only the registrations they need
Each user can work One real task performed successfully

The "each user has signed in" row is the one that matters. Accounts created and never activated look identical to accounts that work, right up to the morning of go-live.

Rollback

Situation Action
Accounts created with wrong details Correct them. Do not delete and recreate unless nothing has been done under the account
Access granted too broadly Reduce it; takes effect immediately
A user created in error Disable, do not delete — deletion breaks attribution if they did anything
Bulk creation with wrong roles Correct the roles; effective at next sign-in

Everything in this stage is reversible. The only irreversible act is deleting an account that has performed work.

Common mistakes

Mistake Consequence Avoid by
Creating everyone before testing mail Forty accounts nobody can activate Test with one first
Shared accounts Attribution destroyed; audit findings One account per person
Aliases or shared mailboxes as addresses Activation emails nobody reads Individual, real addresses
One administrator A lockout that needs Complifly to resolve Always two
Group-wide access by default Unnecessary exposure that is never trimmed Grant the minimum
Deleting a user in error Past actions unattributable Disable, never delete
Assuming created means working Discovering on go-live morning Have each user sign in
Creating accounts for people who have not been trained Confusion and support tickets Sequence access with training

Troubleshooting

Symptom Cause Action
Activation email never arrives Mail, wrong address, or spam filtering Test to a known-good mailbox first
The user signs in and sees nothing No registration access Grant it. Not an authentication fault
Everything is greyed out Role lacks the permissions Fix the role. See Role Assignment
A one-time code expires before arriving Relay latency exceeds its validity Reduce latency or extend the lifetime deliberately
A user cannot be created Entitlement reached See License Management
Two users share an address A shared mailbox was supplied Individual addresses only