> ## Documentation Index
> Fetch the complete documentation index at: https://docs.assetgullak.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Roles & Permissions
> Who can do what in AssetGullak — the five roles, how scope works, and the full permission matrix.
## Overview
Every person you invite to AssetGullak gets **one role** and a **scope** — the part of your company they're allowed to see and act on.
There are five roles. **Owner is always company-wide** — there's exactly one per company, set automatically for whoever signs up, and it isn't something you invite someone into. Every other role — **Admin, IT Admin, IT Operator, Auditor** — has its scope chosen *independently of which role it is*: when you invite someone, you pick their role and separately choose whether they're **company-wide** or tied to a specific **location** or **department**. Two Admins at the same company can have entirely different scopes.
If you only remember one thing from this page: **the role decides *what* someone can do, and the scope — chosen at invite time, for every role except Owner — decides *where* they can do it.** Assuming a role name implies a fixed scope is the most common source of "why can't I see this device" confusion.
Setting up your team for the first time? The [Inviting your team](/getting-started/inviting-your-team) guide walks through assigning roles as you send invites. This page is the reference to come back to later.
***
## The five roles at a glance
| Role | Who it's for | Scope |
| --------------- | --------------------------------------------------------------------- | ---------------------- |
| **Owner** | The account holder — set automatically at signup | Always company-wide |
| **Admin** | A trusted deputy who runs day-to-day operations | Company-wide or scoped |
| **IT Admin** | Manages IT for one office, site, or department (or the whole company) | Company-wide or scoped |
| **IT Operator** | Handles routine device/asset work day-to-day | Company-wide or scoped |
| **Auditor** | Reviews activity and compliance — read-only | Company-wide or scoped |
A company can have any number of people in each role. There's no limit tied to your plan — role assignment is free; it's **devices** and **users** that count against your subscription's limits.
***
## What "scoped" actually means
This is the part worth reading carefully, because it's easy to assume a role name tells you the whole story. It doesn't — **scope is a separate choice made at invite time**, not a fixed property of the role.
**Owner is the one exception: always company-wide**, automatically, with no assignment needed — every location, every department, everything.
**Every other role — Admin, IT Admin, IT Operator, Auditor — is either company-wide or scoped, decided when they're invited** (and changeable later). Company-wide means the same as it does for Owner: no restrictions. Scoped means the person is tied to one or more specific locations and/or departments. Once scoped:
* They can only **see** devices, assets, and employees inside their assigned location(s)/department(s) — everything outside that scope simply doesn't appear in their dashboard, lists, or search results.
* They can only **act** (update a device, run a command, change an asset's status) within that same scope.
* If they try to reach something outside their scope directly — say, by guessing a URL — the request is denied the same way it would be for someone outside your company entirely.
A scoped user can be assigned to **more than one** location or department at once — for example, an IT Admin covering both your Gurgaon and Pune offices. Their scope is the union of everything they're assigned to.
This is also why **Enrollment Keys** matter for scoped roles: a key generated by an IT Admin scoped to "Gurgaon Office" will automatically place any device enrolled with it into that location — they can't generate a key for a location they don't have access to.
***
## Permission matrix
The full breakdown, grouped by area. **Read** generally means "can view," **Create/Update/Delete** are self-explanatory. Owner always applies company-wide. For every other role, whether a permission applies company-wide or only within an assigned scope depends on how that person was invited — see [What "scoped" actually means](#what-scoped-actually-means) above.
### Company & Organization
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| -------------------------------- | :---: | :---: | :------: | :---------: | :-----: |
| View company profile | ✅ | ✅ | — | — | — |
| Update company profile | ✅ | — | — | — | — |
| View locations | ✅ | ✅ | ✅ | ✅ | ✅ |
| Create/update/delete locations | ✅ | ✅ | — | — | — |
| View departments | ✅ | ✅ | ✅ | ✅ | ✅ |
| Create/update/delete departments | ✅ | ✅ | — | — | — |
### Users
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| -------------------------- | :---: | :---: | :------: | :---------: | :-----: |
| View users | ✅ | ✅ | ✅ | — | — |
| Create/update/delete users | ✅ | ✅ | — | — | — |
Only Owner and Admin can invite new team members, change someone's role, or remove a user. IT Admin can see the team list but not modify it.
### Enrollment Keys
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| ---------------------------------- | :---: | :---: | :------: | :---------: | :-----: |
| Create/view/delete enrollment keys | ✅ | ✅ | ✅ | — | — |
IT Admin can generate enrollment keys. If they were invited scoped to a location/department, keys they generate are scoped the same way — they can't generate a key for a location they don't have access to. An IT Admin invited as company-wide has no such restriction.
### Devices
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| -------------------------------------- | :---: | :---: | :------: | :---------: | :-----: |
| View devices | ✅ | ✅ | ✅ | ✅ | ✅ |
| Update device (rename, reassign, etc.) | ✅ | ✅ | ✅ | ✅ | — |
| Delete device | ✅ | ✅ | — | — | — |
### Assets
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| ------------------------------------ | :---: | :---: | :------: | :---------: | :-----: |
| View assets | ✅ | ✅ | ✅ | ✅ | ✅ |
| Create assets | ✅ | ✅ | ✅ | — | — |
| Update assets (incl. status changes) | ✅ | ✅ | ✅ | ✅ | — |
| Delete assets | ✅ | ✅ | — | — | — |
Asset **status updates** — marking something Faulty, In Maintenance, Retired, and so on — fall under "update," so both IT Admin and IT Operator can make these transitions. See [Asset Lifecycle](/features/assets) for what each status means.
### Employees
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| ----------------------- | :---: | :---: | :------: | :---------: | :-----: |
| View employees | ✅ | ✅ | ✅ | ✅ | ✅ |
| Create/update employees | ✅ | ✅ | ✅ | — | — |
| Delete employees | ✅ | ✅ | — | — | — |
### Policies
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| ----------------------------- | :---: | :---: | :------: | :---------: | :-----: |
| View policies | ✅ | ✅ | ✅ | ✅ | ✅ |
| Create/update/delete policies | ✅ | ✅ | ✅ | — | — |
IT Admin can create and manage policies, but only ones targeting their own scope — see [Policies & Compliance](/core-concepts/policies) for how policy targeting works.
### Commands
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| -------------------- | :---: | :---: | :------: | :---------: | :-----: |
| View command history | ✅ | ✅ | ✅ | ✅ | ✅ |
| Issue commands | ✅ | ✅ | ✅ | ✅ | — |
See the note below — issuing commands and running **scripts** are not the same permission.
### Events, Logs & Audit
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| ------------------------------- | :---: | :---: | :------: | :---------: | :-----: |
| View device/asset event history | ✅ | ✅ | ✅ | ✅ | ✅ |
| View audit log | ✅ | ✅ | — | — | ✅ |
Audit log access is deliberately restricted: Owner, Admin, and Auditor can see it; IT Admin and IT Operator cannot. If you need an IT Admin to review audit history, that's an Admin-level decision to grant separately — audit visibility isn't something a scope adjustment can unlock.
### Subscription & Billing
| Permission | Owner | Admin | IT Admin | IT Operator | Auditor |
| ---------------------------------- | :---: | :---: | :------: | :---------: | :-----: |
| View subscription & billing | ✅ | ✅ | — | — | — |
| Change plan, renew, update billing | ✅ | — | — | — | — |
Only the Owner can make billing changes. Admin can view subscription details (useful for checking device limits) but can't modify anything billing-related.
***
## A note on Remote Commands
Look closely at the Commands section above and you'll notice **IT Operator can issue commands** — restart a device, collect logs, refresh inventory. That's intentional: these are routine, low-risk actions that make up most day-to-day IT work.
**Running a custom script is different, and more restricted.** Only Owner, Admin, and IT Admin can run scripts on a device. IT Operator is deliberately excluded, even though they can issue every other command type.
This isn't a bug or a missing permission — it's a safety boundary. A script can do anything a person sitting at that machine could do, so we keep it to the three roles most likely to be trusted with unrestricted access. If someone in an IT Operator role needs to run a script, an Admin or IT Admin will need to do it, or their role adjusted.
See [Remote Commands](/features/commands) for what each command type actually does.
***
## Assigning roles when you invite someone
Click **+ Invite user**. Only Owner and Admin see this button.
The role dropdown shows a one-line description of what that role can do as you select it.
Pick **Company-wide**, **Location**, or **Department** — this choice appears for every role. Selecting Location or Department lets you pick which one(s) they're tied to.
They'll receive an email with a link to set up their account. Their role and scope are active as soon as they accept — check **Users → Invitations** to see anything still pending.
***
## Changing someone's role later
Only **Owner** and **Admin** can change an existing user's role or their scope — go to **Users** in the sidebar, find the person, and use the **⋯** menu on their row.
Changing someone's role takes effect immediately — there's no need for them to log out and back in.
Every role change is recorded in the audit log, including who made the change and what the role was before and after.
***
## FAQ
Not at the same time. Each user has exactly one role. If someone needs broader access, the fix is usually their **scope**, not a second role — give them a company-wide scope, or add another location/department to their existing scope, from **Users** in the sidebar.
Yes — scope is chosen independently of role for everyone except Owner. An Admin can be company-wide or scoped to a single location, exactly like an IT Admin can. Check the person's row on the **Users** page — it shows both their role and their scope, e.g. "IT Admin · Company-wide" or "IT Operator · Finance."
Check their scope on the **Users** page — this isn't about their role, it's about what location(s)/department(s) they were assigned when invited (or edited later). If they need visibility into another office, an Owner or Admin can add that location to their scope, or switch them to company-wide.
This is intentional, not a missing permission — see [the note above](#a-note-on-remote-commands). Scripts can do anything a person at the keyboard could do, so we restrict them to Owner, Admin, and IT Admin.
If a scoped user's last remaining location or department is removed, they effectively lose access to everything until a new scope is assigned — they aren't automatically promoted to company-wide. An Owner or Admin will need to assign them a new scope.
No — Auditor is strictly read-only, including for audit logs themselves. They can view everything within their scope (company-wide or assigned location/department) but cannot create, update, or delete anything, and cannot issue commands.