Manage users and access

User management is a Super Admin task — it sits outside the Tenant Admin scope entirely. Knowing where that line is saves time when a Tenant Admin asks why they cannot add someone to their tenant, or when a new team member cannot see the right data after signing in. If you are a Tenant Admin who needs a user added or a role changed, ask a Super Admin. See When to ask a Super Admin.

​

Access model

Darpan access is session-based. Users sign in, receive a session, and operate within the active company or active tenant available to them. Permissions are evaluated per active context, so a user can have different capabilities in different companies or tenants. Tenant permission membership is separate from tenant identity. A user’s permission level for a given tenant comes from membership records, not from a single global role applied everywhere.

​

Roles

​

Before you start

Confirm:

• You are signed in as a Super Admin.
• The user’s identifier is known.
• You know which active company or active tenant the user should access.
• You know the role to assign: Super Admin, Tenant Admin, or Tenant User.

​

Steps

1. As a Super Admin, open the server-rendered admin screens under /apps/darpan.
2. Create the user record and set the user’s identifier.
3. Grant access to the intended active company or active tenant.
4. Assign the role: Super Admin, Tenant Admin, or Tenant User.
5. Confirm the user can sign in and that the active tenant context is correct after first sign-in.

​

Expected result

The user can sign in and operate within the active company or active tenant you granted. A Tenant Admin can manage that tenant’s connections, schemas, saved runs, automations, and results. A Tenant User can view data, upload files, run reconciliation, and review output — but cannot edit tenant setup records.

​

Changing access

To change a user’s role or remove access, follow the same Super Admin path. Permissions are evaluated per active context, so removing access from one tenant does not affect the user’s access to other tenants they belong to.

​

Endpoint access per source configuration

Roles govern what a person may do. Endpoint access governs something different: which endpoints of a connected system a given source configuration is allowed to read at all. A connected system usually exposes several endpoints — orders, returns, and so on. A source configuration holds credentials that may legitimately reach only some of them, and a credential that can read more than the reconciliation needs is a wider blast radius than the job requires. Each source configuration therefore carries an explicit list of enabled endpoints:

• The catalog of available endpoints comes from the connector registry, so it reflects what the system actually offers rather than a hand-maintained list.
• The enablement is per configuration. Two configurations for the same system can enable different endpoints.
• Endpoints left out of the list are disabled, including endpoints added to the registry later. A new endpoint is never silently readable by an existing configuration — someone has to enable it.

Only the endpoints enabled here are offered when you build a run, which is why an endpoint you expect may not appear in the source picker.

​

Next step

See Auth and access for the full session and permission model, and Manage tenant settings for the tenant-level settings a Tenant Admin controls after access is granted.