Skip to content

User and Role Administration

Applies to: All subscriptions

Purpose

Let an administrator map the customer's real job functions onto the available roles, answer "why can my colleague do this and I cannot" from documentation, and evidence access control at audit.

Audience

System administrators, compliance and internal audit, implementation consultants.

Prerequisites

Steps

Page Covers
Roles and Permissions The seven roles and exactly what each can do
User Lifecycle Creation, activation, change, suspension, revocation
Segregation of Duties The maker-checker model, and what relaxing it means
GSTIN Access Control Which registrations a user may work with

Three independent gates

What a user can do is decided by three separate mechanisms. Diagnosing an access problem means identifying which gate is closed, and they fail in visibly different ways.

Gate Controls Symptom when it blocks
Feature flag Whether the module exists for this GSTIN The whole screen is absent
Role permission Whether this user may perform the action The screen is present; controls are greyed out
GSTIN access Which registrations the user may see Screens load but show no data, or a smaller set than expected

An administrator who internalises this table resolves most access tickets in a minute. The three failure appearances are distinct: missing screen, greyed control, empty screen.

The role model in one paragraph

Seven roles, built around segregation of duties. One platform-level role for cross-tenant administration; one organisation-level role for configuration without transactional authority; a maker and a checker for tax operations; two logistics roles; and a read-only auditor. Preparation and commitment are deliberately held by different roles, and relaxing that is an explicit, recorded decision.

Design principles worth knowing before assigning roles

Configuration authority and transactional authority are separate. The organisation administrator can manage users, configure the ledger and manage numbering — but holds no authority to generate or cancel an IRN or an e-Way Bill. That is deliberate: the person who controls who has access should not also be able to commit transactions.

Logistics roles cannot generate IRNs. They hold the full e-Way Bill family and view-only access to IRNs for cross-checking. A dispatch team does not need, and should not have, the ability to register invoices.

The auditor role touches nothing. View and print only, across every area including administration. It is designed so that granting audit access is never a risk decision.

Some reads are available to everyone. Dashboard, notifications, analytics, upload visibility, template visibility and audit visibility are held by every role. These are informational reads within the user's own tenant that have never been role-restricted; they are kept separate from resource-specific permissions so that widening one cannot silently widen another.

Validation

Check Method Pass condition
Every user has a role Review the user list No user without one
Roles match job functions Review with the customer's process owner Each mapping is deliberate, not defaulted
Segregation is intact, or its relaxation recorded Check the setting and the change record Consistent with the customer's decision
At least two administrators Count Two or more, at different individuals
GSTIN access is minimal Review per user Users have access only to the registrations they work with
Auditors cannot change anything Sign in as an auditor and attempt an action Refused
Departed users are disabled, not deleted Review inactive accounts Disabled, with attribution intact
Access review is scheduled Operations calendar A recurring review with a named owner

Troubleshooting

Symptom Gate Action
A whole module is missing Feature flag See Feature Flags
Screen present, buttons greyed out Role permission Check the role. See Roles and Permissions
Screen present, no data GSTIN access Grant access to the relevant registrations
"Why can my colleague do this and I cannot" Role permission, usually maker versus checker Compare the two roles; this is by design if segregation is enforced
A user can do more than expected Segregation relaxed, or an over-broad role Check the setting first; it collapses maker permissions into checker permissions
Nobody can administer the system The sole administrator left or was disabled Always maintain two. Recovery otherwise requires escalation to Complifly
An auditor requests write access Misunderstanding of the role's purpose The role is deliberately zero-touch. A different role is the answer, with the control consequence understood