Roles, Access & Audit Trail
Everyone sees their job — and only their job
When a breakdown report goes missing or a spares requisition gets approved by someone who technically shouldn't have that button, the question on every plant head's desk is the same: who did this, and why could they? On an Indian shop floor running contract labour alongside permanent technicians, across shifts and sometimes across plants, "everyone logs in as everyone" is not a policy — it's a liability. This page covers how AssetAI controls who can do what, and how every change gets written down in a way nobody can quietly undo.
What a permission actually controls
AssetAI's permission catalogue has 21 keys spread across 10 module groups — assets, work orders, breakdowns, service calls, requisitions, inventory, vendors, configuration, staff and reports. Each key is a verb on a module, not a field or a specific record. That's a deliberate trade-off worth stating plainly: there is no per-record or per-field permission, and there's no plant- or location-scoped permission either. If your storekeeper can approve requisitions, they can approve requisitions company-wide, not just for Unit 2. For most single-plant or single-legal-entity operations this is exactly the right amount of control; for a group with genuinely independent plant-level approval chains, it's a limit you should know before you buy.
The seven roles, and why grants are per company
AssetAI ships with seven built-in roles — Super Admin, Company Admin, Maintenance Head, Planner, Storekeeper, Technician, Employee — each with a sensible default grant list out of the box. Two of these, Super Admin and Company Admin, are locked: their permission matrix can't be edited, and like the other five built-ins, none can be renamed or deleted. That's intentional — you always have a known-good administrative role that can't be accidentally crippled.
Everything else is yours to shape. Grants are stored per company, so "Planner" at one tenant can mean full scheduling authority and at another mean read-only visibility into work orders — the same role name, a different reality, because your plant's approval chain isn't identical to the next company's. A roles manager lets an admin build custom roles and tick permissions per module group; hitting save rewrites that role's entire grant list in one transaction, so you're never left with a role half-updated. Submitted permissions are also checked against the catalogue and intersected against it — anything that isn't a real permission key gets silently discarded, so a malformed request can't grant something that doesn't exist.
A couple of housekeeping rules keep this from turning into chaos over time:
- A role that still has members assigned to it cannot be deleted — you reassign those people first.
- Permission checks short-circuit for super admins and Company Admins, meaning they always pass; everyone else needs a matching grant sitting inside their own company's role setup.
If your organisation is still deciding how granular its maintenance roles should be, the What is a CMMS primer covers where roles typically fit into the bigger picture, and /use-cases walks through how different plant types tend to split responsibility between planners, storekeepers and technicians.
The audit trail: what gets written, and what can never be erased
Every create, update and delete on a tracked model is logged with field-level before-and-after values, plus who made the change, when, and from which IP address. Logins, logouts and impersonation events are logged as well — so if a Company Admin ever needs to log in as a technician to troubleshoot an issue, that's on record too.
The part that actually matters under audit pressure is what the log can't do:
- Log rows cannot be updated or deleted through the application — the model itself blocks both operations, so the trail is immutable by construction, not just by policy.
- Passwords and tokens are explicitly excluded from logged diffs, so sensitive credentials never end up sitting in a change history.
- Audit writes are wrapped so that a logging failure never brings down the application itself — the shop floor doesn't stop because the audit layer hiccupped.
This is the honest answer to "can someone cover their tracks" — no, not through the app, because there's no delete or edit path exposed to any role, including admins.
Finding what you need in the log
A filterable log viewer lets you search by action, by user, and by free text, with results ordered newest first. It's built for the question a plant head actually asks — "show me everything Rajesh touched last Tuesday" or "who approved this PO" — not for compliance reporting at scale. There's no export, retention, or purge tooling built into the viewer today, so if your quality system needs a periodic offline export for ISO or internal audit purposes (see ISO's standards library for the kind of documentation trail auditors expect), plan on pulling that manually rather than relying on scheduled reports. Note also that this screen specifically requires the Company Admin role — it's deliberately withheld even from Super Admins, on the logic that day-to-day activity review belongs to the company running the plant, not to the platform operator.
Login security: what's there, and what isn't
Companies can optionally turn on an emailed one-time code as a second factor at login — a plain OTP, sent to the user's registered email, allowing five attempts before it fails. That's the extent of second-factor support. There's no authenticator-app or SMS-based OTP, and there's no SSO, SAML or OIDC integration, nor any IP allowlisting or network-level restriction. If your organisation has an SSO mandate or needs IP-restricted access as a security baseline, AssetAI isn't the right fit today — better to know that before deployment than after a security review flags it.
Where this fits
None of this replaces your maintenance planning or breakdown workflows — those live on their own pages under /features — but it's the layer that determines who's allowed to touch them, and gives you a paper trail when something goes wrong on the floor at 2 AM during a power cut and three people had system access at the time. For plants weighing this against manual sign-off registers or spreadsheet-based access lists, /pricing and /industries have more on how this maps to different plant sizes, and /contact is the fastest way to see the roles manager and log viewer against your own approval chain.
Getting the roles matrix right on paper is easy; getting it to survive contact with a real shift changeover is the actual test. This section is about the rollout and review habits that make the access model in /features hold up over time — not just how it works on day one.
Rolling out roles without stalling production
- Map your existing sign-off chain to the seven built-in roles before touching the roles manager — most plants find Maintenance Head, Planner and Storekeeper already match how requisitions and work orders get approved today.
- Build custom roles for the two or three job titles that don't fit — contract supervisor, shift QA lead, vendor coordinator — rather than stretching a built-in role's grants to cover people it wasn't designed for.
- Do this before go-live, not after: a role with members already attached can't be deleted, so fixing an early mistake means reassigning every technician on it first.
- Keep the matrix per company deliberately narrow at first. It's easier to add a missing permission on request than to discover in month three that a temporary hire could approve a vendor payment.
The access mistake that costs the most
The most common shortcut plants take is handing out Company Admin because it "just works" — it bypasses every permission check, so nobody has to think about grants. That convenience is exactly the risk: Company Admin and Super Admin are locked roles precisely because they skip the matrix, and every action taken under one is logged as that account, not as the person who actually clicked the button. Keep both roles to the smallest possible list of named people, and route daily approvals through Planner, Storekeeper or a custom role instead.
Two smaller traps worth flagging:
- Submitted permission sets are intersected against the catalogue on save, so a permission key from an old export or a copy-pasted config that no longer exists is silently dropped, not flagged as an error — check the saved role, not the form you submitted.
- Email OTP allows five attempts before failing. If a technician's inbox access is unreliable on the shop floor — patchy signal, shared devices, a power cut at the wrong moment — plan for that before mandating second factor company-wide.
What to actually review, not just search when something breaks
The log viewer's filters by action, user and free text serve two very different habits, and both matter:
- Reactive: when a requisition looks wrong, filter by that user and date to see the exact before-and-after values, the IP, and who approved it.
- Routine: a standing weekly pass through logins, logouts and impersonation events, done by whoever holds Company Admin, catches shared logins and after-hours access before they become a finding — the same discipline ISO quality systems expect from access review, treated as recurring rather than a one-time setup task.
The activity-log screen itself is locked to Company Admin and refused to Super Admin — so this review has to be a named person's job, not something any privileged account can casually pick up.
Where this does not fit
If your compliance mandate calls for SSO, SAML or OIDC login, or your security policy requires IP allowlisting, AssetAI doesn't provide either today — you'll need a separate identity layer alongside it. If you're evaluating this for a multi-plant group expecting approval limits to differ by location rather than by company, check /industries and /use-cases against your structure before committing, since every grant here is company-wide, not scoped to a
Roles, Access & Audit Trail FAQs
Can we create custom roles in AssetAI, or are we stuck with the seven built-in ones?
AssetAI ships with seven built-in roles and doesn't support creating brand-new custom roles from scratch; instead, you shape access by adjusting which of the 21 permission keys a role carries, or by moving a user to a different one of the seven roles. Each permission key is a verb on one of 10 module groups — assets, work orders, breakdowns, service calls, requisitions, inventory, vendors, configuration, staff and reports — so within an existing role like Planner or Storekeeper there's real room to add or remove specific capabilities without inventing a new role name. What this setup doesn't give you is a per-record or per-plant version of any role — grants apply company-wide. For most single-entity manufacturers this is enough flexibility; check the features page for the full permission catalogue before assuming you need something custom.
What exactly does AssetAI's audit trail record — logins, approvals, or every click?
The audit trail records changes to who has access to what — role assignments and permission grants — written down in a way that can't be quietly edited or removed later, rather than logging every click across the shop floor. So when a requisition approval or a missing breakdown report is disputed, a plant head can check who currently holds that permission and trace back to when it was granted, instead of relying on someone's memory. Because permissions are verbs tied to one of 10 module groups like requisitions or breakdowns, the audit trail sits at that same level — access to a module, not activity inside individual records. If your certification process needs a broader change log for every transaction, it's worth reading how AssetAI defines a CMMS before assuming that's included.
Can a Company Admin edit or delete audit trail entries to cover their tracks?
No — role and permission changes in AssetAI are written down in a way that can't be quietly edited or removed, including by a Super Admin or Company Admin. This matters because those two roles have the broadest reach in the system, and without an unchangeable record, an admin could grant a requisition-approval or staff permission to themselves or someone else and later erase the trace. Instead, every grant or role change is logged as it happens, so if a storekeeper suddenly has an inventory or vendor permission they didn't hold last month, that change stays visible after the fact rather than just showing the current state. This doesn't extend to a full change log inside modules like assets or work orders — the protected record here is specifically about access, which is covered alongside other controls on the features page.
How do we restrict access for contract labour who only work certain shifts?
AssetAI doesn't have a shift-based or time-limited permission setting — access depends on which of the seven roles a person holds and which permission keys that role carries, not on when they're clocked in. So for contract labour working specific shifts, the practical approach is assigning them a role such as Technician or Employee with only the permission keys relevant to their actual work, like logging breakdowns or updating work orders, rather than trying to restrict them by time of day. Because permission keys are company-wide verbs on module groups such as work orders or requisitions, not scoped to a shift or a single plant, the same role definition applies whether the person is contract or permanent staff. Worth checking this against your own shift and contractor structure — the use-cases page walks through how different plant setups typically assign roles.
If someone moves from technician to planner, does their old access disappear right away?
Yes — changing a user's role in AssetAI updates their permission keys immediately, so moving someone from Technician to Planner changes what they can do across modules like work orders or requisitions right away, rather than leaving old access active until someone remembers to revoke it. Because each of the 21 permission keys is a verb on one of 10 module groups, reassigning a role swaps the whole bundle of capabilities in one step instead of requiring an admin to untick permissions individually. What doesn't change automatically is anything tied to a specific plant, since grants aren't scoped that way — if the person is also transferring between units, that needs separate handling. The role change itself is captured in the audit trail, which is useful if that person's earlier access is ever questioned; see resources for related guides on setting up roles.
Can we use AssetAI's audit trail as evidence during an ISO or internal audit?
You can use AssetAI's audit trail as evidence of access control during an ISO or internal audit, since it records role and permission changes in a way that can't be quietly altered afterward. This helps with audits that ask not just whether a work order was closed, but whether the person who closed it or approved the spares requisition was actually authorized to, because the trail shows when a permission was granted and to whom, not only the current role list. It won't give you a transaction-level change log for every asset or inventory record — the audit layer sits at the access level, tied to the same 10 module groups the permission keys cover. If your certification body expects broader logging than that,
If our plant auditor asks for a report showing who approved the last emergency shutdown and when, can AssetAI generate that directly?
Yes. The audit trail captures approval workflows by user, timestamp, and asset. Export reports from the Audit Trail dashboard filtered by date range and action type. Most plants use this for compliance documentation during third-party audits or incident investigations.
See Roles, Access & Audit Trail on your own machines
A 30-minute demo on your plant, not our slides.