Approvals that mean something afterwards
An approval record has one job: to be readable in two years by somebody who was not there. That rules out a boolean, and it rules out any design where covering for a colleague means logging in as them.
What it is, and what it is not
An approval is a signed statement by a named person about a specific object at a specific revision, with a recorded meaning and a moment attached. It is a task in a workflow instance, not a field on the object being approved.
It is not a yes/no flag. Five meanings are recorded — approved, rejected, abstained, delegated, escalated — because collapsing them loses exactly the information an auditor asks for. Somebody who abstained because they were not qualified to judge is a different record from somebody who approved, and both are different from somebody whose task was escalated past them.
It is also not a signature image. An electronic signature here is an authenticated act by an identified user, bound to the object revision and recorded in the audit chain. A picture of a signature on a PDF is a picture.
The mechanism: delegation is first-class
This is where most systems create their own worst problem. If delegation is hard, people share credentials — not out of carelessness, but because a change is blocked on a Friday and the approver is on a plane.
So delegation is explicit: an approver nominates a delegate for a period, the delegate's approvals are recorded as the delegate acting for the approver, and both names are on the record. Out-of-office reassignment works the same way. Nobody has to log in as anybody, and the record stays true.
Escalation does not silently reassign. A task unanswered past its timer escalates — the manager is notified, the task stays open and assigned to the original approver, and the escalation is itself a recorded meaning. That preserves the distinction between *approved by the manager after escalation* and *approved by the reviewer*, which are different facts.
An approval binds to the revision it approved. If the object changes afterwards, the approval does not travel — it belongs to the state that was signed for, which is what makes a released revision defensible.
The failure it prevents
A change is waiting on a manufacturing review. The reviewer is on leave. Their colleague, who genuinely knows the answer, is asked over a call and says it is fine. Somebody records the approval under the reviewer's login because that is the only way to unblock the change.
Nothing bad happens, and the change was correct. Eighteen months later an auditor asks who approved it, and the answer names a person who was in another country and has no memory of it. Every other approval in the system is now worth less, because the mechanism that produced this one produced all of them.
The fix is not a policy telling people not to share logins. It is making the honest path faster than the dishonest one: a delegation takes ten seconds and produces a record with both names on it.
How it meets the rest of the product
Approvals run on the workflow engine, so parallel and sequential approval routes, conditions, timers and rework all come from one engine rather than a change-specific implementation. Quality records, document releases and supplier onboarding use the same machinery.
Routing conditions are deterministic expressions over object attributes and relationships — does this change affect a released part, does it touch a plant, is the cost impact above a threshold. No model decides who approves anything, because an approval route nobody can reproduce is an approval route nobody can defend.
Agents can participate as task performers where you allow it — preparing a draft, attaching an analysis — and those actions are audited with the agent named. An agent cannot be an approver at any tier.
Every approval lands in the hash-chained audit trail with the actor, the meaning, the object revision and the moment. Writes without an attributed actor are refused, so an approval with no owner is not a thing that can exist.
How it meets your ERP
Approval is where the release boundary sits. A change publishes to your ERP when it releases, and it releases when its approvals complete — so the ERP never sees a structure that has not been through the route your configuration defines.
That ordering is worth stating because the alternative is common: a PLM that publishes on save and treats approval as a status recorded afterwards. In that arrangement the ERP holds structures nobody signed for, and the approval record documents a decision the planning run already acted on.
The approval record itself does not go to your ERP. What crosses is the released structure and its effectivity; who signed for it is engineering history, and copying it into a system with no revision model to attach it to would produce a second, weaker record of the same fact.
Where the boundary is
This is not a qualified electronic signature under eIDAS, and it is not 21 CFR Part 11 compliant. Both are achievable on this foundation — authenticated acts, immutable records, a verifiable chain — but neither has been validated, and claiming otherwise on a public page would be the kind of statement somebody relies on.
It also does not manage external signatures. A customer or supplier countersigning a document happens in a signing tool, and the executed document comes back into the vault as a controlled artefact with its own revision.
Facts
| Recorded meanings | Approved · rejected · abstained · delegated · escalated |
| Bound to | The object at the revision signed for |
| Delegation | First-class — both names on the record |
| Escalation | Notifies, keeps the task assigned, records itself |
| Routing | Deterministic conditions — no model decides |
| Agents | May perform tasks; may never approve |
| Audit | Hash-chained; unattributed approvals cannot exist |
| Not claimed | eIDAS qualified signature · 21 CFR Part 11 |
Frequently asked
Why record five meanings instead of approve or reject?
Because collapsing them loses what an auditor asks for. Somebody who abstained as unqualified to judge is a different record from somebody who approved, and both differ from somebody whose task was escalated past them. A boolean cannot express any of that.
What happens when an approver is away?
They nominate a delegate for a period, and the delegate's approvals are recorded as the delegate acting for them, with both names on the record. The point is making the honest path faster than the dishonest one, because otherwise people share logins.
Does escalation reassign the task?
No. The manager is notified, the task stays open and assigned to the original approver, and the escalation is itself a recorded meaning. That preserves the difference between approved by the manager after escalation and approved by the reviewer, which are different facts.
Can an agent approve a change?
No, at any permission tier. Agents can perform tasks where you allow it — preparing a draft, attaching an analysis — and those are audited with the agent named as actor. Approval is a human act with a signature and a recorded meaning behind it.
Does an approval survive a later edit?
No, and it should not. An approval binds to the object at the revision it approved. If the object changes, the approval does not travel with it — it belongs to the state that was signed for, which is precisely what makes a released revision defensible.
Is this 21 CFR Part 11 compliant?
No, and we will not claim it. The foundation is there — authenticated acts, immutable records, a verifiable hash chain — but it has not been validated, and a compliance claim on a public page is the kind of statement somebody relies on when they should not.
Can customers countersign documents?
Not here. External signature workflows belong in a signing tool, and the executed document returns to the vault as a controlled artefact with its own revision. Building a second signing product inside a PLM would be doing a specialised job badly.