Users & roles

This is where an Org Admin manages who has access and what they can do. For the underlying concepts, read Roles & permissions basics first.

The user directory

The Settings → Users screen lists every user in your organisation with their name, email, mobile, role, department, designation, status and last login.

Search by name or email.
Filter by status (active / pending activation / inactive), role or department.
It is your entry point for inviting, editing, deactivating and changing roles.

Only Org Admins can open it, and it only ever shows your own organisation’s users.

Invite a user

New people join by invitation, there is no public sign-up.

Choose Invite user.
Enter their name, email, mobile, department, designation and role. A role is required: no user is created without one.
Send. The email is checked for a valid format and must be unique within your organisation; the mobile is validated too.
The person receives a standard invite and activates their own account by setting a password. Until they do, they show as pending activation.

Invite links are single-use and valid for 48 hours. Resending an invite invalidates the previous link. Invites are audit-logged.

Edit a user

Open a user to update their name, mobile, department, designation and role.

Email is read-only: it identifies the account. If an email is wrong, re-invite under the correct address.
A role change takes effect on the user’s next session (or next login).
If two admins edit the same user at once, the stale save is rejected with a prompt to refresh.
Changes record the previous and new value per field.

Deactivate or reactivate a user

When someone leaves, deactivate their account rather than deleting it, so history stays intact.

Deactivation blocks their sign-in immediately and signs them out of every device.
Reactivating restores access with no new invite needed.
The last remaining admin cannot be deactivated: you get a clear error.
Status changes are audited with the actor and a reason.

Assigning structure and role

When you create or edit a user you assign their department, designation, branch and role in one place. Department, designation and branch are optional but make filtering and reporting easier; the role is what grants access. See Organisation structure for the masters behind these choices. Two rules always hold: a user always keeps at least one role, and the last admin cannot lose their admin role.

For any user, an Org Admin can review their login history: each attempt’s time, device, browser, IP and outcome (success, failure or locked), plus password-change events. Filter by user, date range or outcome. The view is read-only and covers your organisation only. This is useful for investigating suspicious activity.

Managing roles and permissions

Beyond the starter roles, Org Admins can shape access precisely.

Create and edit roles

Create a custom role with a name and description to match a job function. A new role starts with no permissions and grants nothing until you add some.
Edit a role’s name, description or permissions any time.
A role that is assigned to users cannot be deleted until those users are moved to another role.
System roles (Admin, Viewer, Customer portal) can’t be renamed or deleted, but you can clone them.

Clone a role

Start from a close match instead of from scratch: clone any role (predefined or custom) into a new, independent custom role. The clone takes a snapshot of the source’s permissions and scope at that moment, later changes to the source do not flow into the clone. Give the clone a new unique name.

Grant permissions

Use the permission grid: your enabled modules down one side, the six actions (view, create, edit, delete, approve, export) across the top, and tick what each role may do. Modules are grouped into collapsible sections, and a module-level “select all” toggle flips every action for a role at once. Unticked means no access, so deny-by-default is visible at a glance. Export is granted separately from view. System roles show read-only with a “Clone to edit” option. Saving updates access and records an audit entry.

Managing roles and permissions is itself permission-gated: a user without role- or user-management rights can’t create roles, grant permissions or assign roles, not even to themselves, so no one can quietly widen their own access.

Role templates library

Import a role from Villva’s curated template library (for example “warehouse picker” or “finance read-only”) as a starting point. Importing copies the template into a new custom role of your own; your organisation is never linked to the template, and templates only include permissions for modules you are entitled to.

Bulk-assign roles from a CSV

Onboarding many people or handling a reorg? Upload a CSV of email and role rows. Villva previews and validates each row (the email and role must exist, no self-targeting, and the last-admin guard is respected) and shows per-row errors before you commit. The commit runs in the background; a bad row is isolated so the rest still go through. Every assignment is audited.

Time-bounded (auto-expiring) roles

Give temporary access, a contractor, a covering manager, an audit consultant, a role with an expiry date. When it expires the user automatically reverts to their prior role. They are notified 24 hours before and on expiry, you can revoke early, and the last-admin guard still applies.

Deny a single permission

Need one exception without rebuilding a role? Add a per-user deny for a specific permission. An explicit deny wins over the role’s grant, so you can block one action for one person cleanly. Deny entries are audited with a reason.

Restrict which records a user sees (data scope)

Module permissions say which modules; data scope narrows which records, by department, region or assignment. A scoped user sees only their matching rows in lists and searches, and opening an out-of-scope record returns “not found”. Clearing a user’s scope (making them unrestricted) is an explicit, audited action, and takes effect on their next action. Org Admins are typically unscoped and see everything in the organisation.

Mask sensitive fields

Sensitive fields (bank details, credit limit, financial values, salary) can be masked from roles that lack permission, on screen, in lists and in exports alike, and made read-only so those roles can’t change them. Admins see and edit everything by default.

Check and preview access

Use the “what can this user do” inspector to see a person’s roles, effective permissions, data scope and which sensitive fields they can see versus masked. It reflects the live rules.
Before saving a permission change, run the impact preview to see exactly which users would gain or lose access, a dry run that never saves anything.

Extra confirmation on sensitive actions

Some high-impact actions, granting an admin role, deactivating many users at once, exporting all data, changing payment routing, ask the person to re-confirm with a fresh authenticator-app code, even when they’re already signed in. This applies to everyone, including admins. See Extra confirmation for sensitive actions.

You can restrict sign-in so people can only reach Villva ERP from your approved office internet connections: useful if you want staff to use the system only from the workplace.

Enter the list of allowed network addresses. Leaving the list empty means no restriction (the default), anyone with a valid login can sign in from anywhere.
Requests from outside the approved networks are refused early, with a generic “can’t sign in from here” message that gives nothing away.
If the list you enter would lock out your own current connection, Villva warns you and asks you to confirm before saving, so you don’t accidentally shut yourself out.
The same restriction also applies to external customer-portal access.
Only an Org Admin can manage the list, and every change is recorded (who changed it, and what changed).

You don’t need to know these addresses yourself, ask your IT person for your office’s internet (IP) addresses and enter those.

Roles & permissions audit

Every role and permission change, role create/edit/delete, grant/revoke, assignment, scope change, field-masking change, writes an append-only audit entry with the actor, target, before-and-after values and time. Org Admins can view and filter their organisation’s roles-and-permissions audit (by user, role, resource, action or date) and pull up a user’s role history as a timeline. These entries can never be edited or deleted, and you only ever see your own organisation’s.