MVP One job permissions need role-and-action tests

Translate every role name into tested actions

MVP One's official product page says the platform can define user roles and permissions down to the job level. That is a useful capability boundary, not proof that a particular permission model matches an organization's maintenance responsibilities. Labels such as technician, planner, supervisor, storeroom, contractor, reliability engineer, or administrator can conceal materially different access across sites, assets, work types, and lifecycle states.

Create a role-action matrix using actual records. For each role, test whether the user can view, create, edit, assign, approve, defer, cancel, close, reopen, export, and delete each relevant object. Include assets, work requests, work orders, procedures, readings, failure codes, labor, attachments, parts, purchase requests, warranties, costs, dashboards, and audit records. Record whether access is scoped by site, department, asset list, craft, job, shift, or employment status.

Test lifecycle states, not only menu visibility

A user who cannot see an administrative menu may still be able to change a consequential field through a mobile screen, import, API, integration, notification action, copied job plan, or bulk update. Run tests in every supported channel and at each lifecycle state. A planner may be allowed to prepare a job but not approve work release; a technician may record findings but not rewrite the approved procedure; a supervisor may verify completion but not erase the original result.

Use paired positive and negative cases. Confirm that an authorized role can complete the intended task without workarounds, then prove that a nearby role cannot perform the same action. Test cross-site records, transferred employees, temporary contractors, delegated approvals, emergency access, inactive accounts, shared devices, and restored backups. Capture the observed result and configuration version instead of relying on a screenshot of the role definition.

Follow permission effects into connected systems

The same official page describes connections with ERP, HR, BI, and other enterprise systems. An access decision in the CMMS can therefore have effects outside the CMMS. Document which identity and permission context is carried into an integration, which system remains authoritative for employee status, purchasing approval, financial posting, and reporting, and whether a service account can perform actions that an interactive user cannot.

Reconcile joiner, mover, and leaver events. When a person changes craft, site, shift, employer, or supervisory duty, record who changes access, when it becomes effective, how open assignments and approvals are handled, and what evidence shows removal in every connected system. Alerts are not remediation: a notification that reaches the right person does not prove the recipient had appropriate access, acted, or documented the resulting maintenance decision.

Keep access control separate from work approval

This control question is distinct from whether a work assignment or reusable process was approved. A permission allows a user to attempt an action; it does not establish that the work itself was authorized, correctly executed, independently verified, or safe to return to service. Preserve those operational decisions in their own records. Use the role-action matrix to demonstrate that only the intended people could create or change those records during the relevant period.

Maintenance Operations Ledger reviewed the official MVP One page on September 4, 2026. The source supports the capability descriptions above, but it does not establish any reader's configured roles, access scope, segregation of duties, identity lifecycle, integration behavior, record integrity, maintenance result, or security outcome. No recoverable post-cutoff material delta was proven, so the publication is a durable implementation test rather than current intelligence.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Maintenance Operations Ledger will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.