Permit-to-Work Management

Work Approval & Authorisation is the module that decides who must sign off — and in what order — before a breakdown gets attention, a requisition gets bought, a work order proceeds, a vendor gets onboarded, or an asset gets modified. It replaces the paper chit or the WhatsApp forward with a configured chain, one per document type, that runs the same way every time.

Why Chains, Not a Single Approver Field

Most CMMS tools bolt on a single "approved by" field and call it governance. That works until a ₹5,000 requisition and a ₹5,00,000 one need different scrutiny, or until an auditor asks why a purchase lead approved something outside their role. AssetAI treats approval as a sequence of role-based steps, each with an optional amount threshold, so the chain itself carries the logic instead of relying on whoever happens to be free.

• A step is a role plus a label — "Plant Head," "Finance Lead" — not a named person, so the chain survives transfers and shift changes.
• Thresholds are checked against the document's own value, so a low-value work order never needlessly waits on a senior signature.
• Steps run one at a time, in sequence — there's no parallel sign-off to reconcile, and no ambiguity about whose turn it is.
• A document type with no real approval need can simply stay disabled; nothing forces five chains where one or two will do.

This is deliberately narrower than a full permit-to-work system. If your primary requirement is a permit number, a validity window, or a gas-test record before hazardous work begins, that sits outside this module — AssetAI's Safety Measure master list prints LOTO, PPE, and permit labels on the job sheet as a checklist, which is a different guarantee than an authorisation chain.

What the Audit Trail Actually Proves

An approval is only as credible as the record behind it, and that's where the mechanics matter more than the interface. Every action — approve or reject, by whom, in which role, at which step, with what remark, at what time — is written as its own row rather than overwriting a single status field. Nothing is lost when a document moves forward, and nothing is lost when it comes back.

• A rejection doesn't dead-end the request; it returns with remarks attached, and the steps already approved before that point remain visible in history.
• Because steps freeze onto the request at submission, a chain edited mid-month can't retroactively rewrite what an approver actually saw and signed off on weeks earlier.
• Company-scoped records mean one plant's chains, thresholds, and history are never visible from another plant's login — relevant for any group running multiple facilities under one account.
• For teams benchmarking governance against a broader standard, the same discipline that supports ISO documentation requirements applies here: a defensible answer to "who authorised this, and on what basis" without reconstructing it from memory or paper.

This is what turns approval from a formality into a record a plant head or auditor can actually stand behind — see the full module list on /features, or book a demo to walk through a chain configured for your document types.

Rolling It Out Without Freezing Operations

Configuring a chain is a one-time exercise per document type, but it shapes how every future breakdown, requisition, work order, vendor onboarding, or asset change moves through the plant. Getting the setup right — and knowing what the module is deliberately silent on — matters as much as the mechanism itself.

Setting Up a Chain: What a Plant Actually Configures

A maintenance head or plant administrator builds a chain by defining, for each of the five document types, an ordered list of steps. Each step is a role and a label, and — where relevant — an amount threshold. There is no code, no workflow engine to learn, and no need to touch every document type at once.

• Start with the document types that actually cause disputes or delays today — usually requisitions and work orders — and leave the rest disabled until there's a real need.
• Set thresholds at the value where your plant genuinely wants a different approver, not at arbitrary round numbers; a threshold that never triggers is dead weight in the chain.
• Assign steps to roles, not to people, so a transfer or a shift change never breaks an in-progress approval.
• Review chains after an audit or a near-miss on spend, not on a fixed schedule — chains should change when the risk they cover changes.

Because AssetAI freezes the applicable steps onto a request the moment it's submitted, a chain edited after that point never touches documents already mid-approval. New chains only govern new requests — which is exactly what makes the older ones trustworthy in an audit.

Where This Sits Relative to Safety Sign-Off

It's worth being explicit about scope: this module authorises spend and work order progression, not hazardous-work entry. There is no permit number, no validity window, no gas-test record, and no permit close-out here. For that layer, AssetAI attaches a Safety Measure master list — LOTO, PPE, work permit, gas test — mapped per asset and printed on the job sheet as a checklist for the crew to follow. It is a reminder, not a gate; nothing in it blocks or reroutes a document.

Plants whose primary need is a controlled permit-to-work system, with sign-offs tracked to formal safety standards such as those catalogued by ISO, should treat the Safety Measure list as a starting point and judge for themselves whether it covers their risk — the standards page lays out how AssetAI's approach lines up against common compliance expectations, and what it doesn't attempt to replace.

A Few Ways Chains Go Wrong in Practice

Most problems with approval chains come from over-fitting them to how paper used to move, rather than to how the plant actually operates.

• Building a five-step chain for every document type "to be safe" — this just recreates the old paper chit's delay, one system-generated forward at a time.
• Setting one threshold company-wide when different plants under the same company have very different spend norms; chains are configured per document type, and a company running several plants should size thresholds to each.
• Forgetting that a rejection returns the document with remarks rather than closing it — teams sometimes wait for a notification that never comes, when the requisition is actually sitting back with the requester.
• Assuming the chain enforces itself retroactively — it doesn't; only requests submitted after a chain is enabled or changed are affected.

None of this requires new infrastructure — it's a matter of matching the chain to the actual spend and risk profile of the plant, something worth working through before go-live at a demo rather than after the first disputed approval.