User Lifecycle¶
Applies to: All subscriptions
Purpose¶
Give administrators a repeatable procedure for every stage of a user's life in the system, and highlight the two decisions that cause real damage when got wrong: deleting instead of disabling, and running with one administrator.
Audience¶
System administrators, compliance and internal audit.
Prerequisites¶
- Roles and Permissions
- GSTIN Access Control
- Mail transport working — account activation depends entirely on it
Steps¶
1. Create¶
| Field | Guidance |
|---|---|
| Name | As the person is known, for the audit trail |
| An address the person actually reads. Activation depends on it | |
| System Role | Mapped from the job function, not the job title |
| Approval Role | Only for people who sign off in an approval workflow. Leave unassigned otherwise |
| GSTIN access | Only the registrations they work with |
Create accounts for individuals. A shared account destroys attribution, which is the property a compliance system exists to provide.
Setting up an approver¶
An approver needs both role fields, and neither alone produces an error — the account is created, the person signs in, and nothing ever reaches them.
| Set | To |
|---|---|
| System Role | Approver for someone who signs off but does not process; Tax Controller for finance staff who do both |
| Approval Role | The level they occupy — Finance Manager, Finance Controller, Business Head, CFO and so on |
Assign each approval role your matrix uses to at least two people. A level with a single holder stops every document routed through it the moment that person is unavailable, with no alert. See Segregation of Duties.
2. Activate¶
The user receives an email and completes activation. If mail is not working, this stage fails silently — the account exists, the user never receives anything, and the ticket says "my account does not work".
Confirm the first account activates end to end before creating the rest.
3. Operate¶
Nothing to do. Access is decided by the three gates: feature flag, role, GSTIN access.
4. Change role¶
Update the role. It takes effect on the user's next sign-in.
Before changing, check what the new role loses as well as what it gains. Moving someone from Tax Controller to Org Admin removes all transactional authority — which may be exactly right, or may leave a workflow with nobody able to commit it.
The approval role is a separate field and changing the system role does not touch it. Two consequences:
- Moving an approver to a non-approving system role leaves their approval role in place. Documents keep routing to them and they can no longer act. Clear the approval role at the same time.
- Moving someone into an approving system role does not give them a level. They still need an approval role assigned before anything reaches them.
Only a Super Admin can assign the super_admin role. An org administrator attempting it is refused, because that role reaches across tenant boundaries.
5. Change GSTIN access¶
Add or remove registrations. Removal takes effect immediately for new queries; a user viewing a screen may need to reload.
6. Suspend¶
For temporary removal — extended leave, an investigation, a security concern. Disable the account. Reversing it restores access with the same identity and history.
7. Revoke on departure¶
Disable the account. Do not delete it.
Deleting breaks the attribution of past actions. A compliance system must be able to say who registered a particular invoice three years ago, and a deleted account makes that unanswerable. Disabling removes all access while preserving the record.
| Step | Detail |
|---|---|
| Disable the account | Immediately on departure |
| Check for sole ownership | Were they the only administrator? The only checker for a GSTIN? The only holder of an approval role? |
| Reassign their approval level | If they held an approval role no one else does, every document routed to that level stalls silently |
| Reassign notification recipients | If any alert was addressed to them personally |
| Review their integration credentials | Any machine credential they issued, if it is tied to them |
| Record the date | For the access review |
8. Review access periodically¶
| Question | Action if the answer is unsatisfactory |
|---|---|
| Does everyone still need their access? | Remove what is no longer needed |
| Has anyone left without being disabled? | Disable immediately and investigate the process gap |
| Are the roles still right after reorganisation? | Update them |
| Is GSTIN access still minimal? | Trim it |
| Are there at least two administrators? | Add one |
| Does every approval role the matrix uses have at least two holders? | Assign it to a second person |
| Does anyone hold an approval role but no system role that can approve? | Fix or clear it — they are in the chain and cannot act |
| Are there more super admins than necessary? | Reduce |
Always maintain two administrators¶
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. Recovery then requires escalation to Complifly.
Two administrators, at different individuals, is the minimum. Verify it at every access review.
Validation¶
| Check | Method | Pass condition |
|---|---|---|
| A new account activates | Create one and complete activation | Activation email arrives and sign-in succeeds |
| The role is right | Sign in as the user and attempt their normal work | Everything they need is available; nothing more |
| GSTIN access is right | Check what data they see | Only the intended registrations |
| Suspension works | Disable an account and attempt sign-in | Refused |
| An approver can actually approve | Sign in as them, open a document pending at their level | Approve and Reject are present and succeed |
| Every approval level has a holder | Compare the approval matrix against the user list | No level in use is unstaffed |
| Reinstatement works | Re-enable and sign in | Restored, with history intact |
| Departed users are disabled | Compare the user list against the customer's leaver records | No active account for a departed person |
| Attribution survives | Inspect an audit entry for a disabled user | Still attributed correctly |
| Two administrators exist | Count | Two or more |
| Access review happens | Operations calendar and evidence | Performed on schedule, with outcomes recorded |
| No shared accounts | Review the user list | Every account maps to one person |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| A new user never receives their activation email | Mail failure, wrong address, or spam filtering | Check mail delivery first. See Email and Notifications |
| A user signs in but sees nothing | No GSTIN access | Grant access. Not an authentication fault |
| A user signs in but everything is greyed out | Role lacks the permissions | Fix the role |
| Past actions can no longer be attributed | The account was deleted rather than disabled | Disable, never delete. Attribution may not be recoverable |
| Nobody can administer the system | The sole administrator is unavailable | Maintain two. Recovery otherwise requires escalation to Complifly |
| A workflow stalls after a role change | The person who could commit no longer can | Check what the new role lost, not only what it gained |
| Alerts stop being acted on | They were addressed to an individual who has left | Use distribution lists for every alert recipient |
| A departed employee still has access | No leaver process linking to Complifly | Add Complifly to the customer's leaver checklist |
| Several people share an account | Convenience during implementation | Split into individual accounts. Shared accounts destroy attribution |
| Access has accumulated over years | No periodic review | Start one now, then run it on a schedule |
Related Articles¶
- Roles and Permissions — choosing the role
- GSTIN Access Control — choosing the registrations
- User Authentication — how sign-in works
- User Creation — bulk creation during implementation
- Monthly Checks — where the access review sits