Workflow rules
Have a corrective action raised automatically when an inspection item fails.
A failed inspection item only becomes work once somebody reads the form and writes a corrective action. A workflow rule does that step for you: the moment a form is submitted with a failure on it, the action is already there, assigned, with a due date.
Rules live under Settings, in the Workflows area. An owner, admin or manager can add one.
Writing a rule
A rule reads as a sentence in three parts. When a form is submitted, if enough items failed, then raise a corrective action.
- 1When
Choose which forms the rule watches. Tick nothing and it watches every form, which is usually what you want to start with.
- 2If
Set how many items have to fail before the rule acts, and narrow it to particular projects if the rule is only for one site. A clean form never raises anything, whatever the rule says.
- 3Then
Choose one action for the whole form or one for each failed item, how many days it is due in, who it goes to, and which level of control it sits at.
What a rule can do
A rule can raise a corrective action, send a notification, or both. Add as many as you need; they run in the order you list them, and each one is logged separately so you can see which part worked.
- Raise a corrective action — tracked work with an owner and a due date.
- Send a notification — an email telling somebody what failed, with a link to the form. Goes to the project lead on shift, whoever filed it, or a named person, and you can add a line of your own.
A rule can only raise one corrective action, because two from one finding is a duplicate with a different due date. It can send several notifications, because telling two people is ordinary.
If a rule is set to tell the project lead and the project has no leads, or the person named has left, the run log shows it in red rather than sending the message to somebody else. One email per form, however many items failed on it.
One action, or one per finding
One action for the whole form is the simpler choice and the right one for a short inspection: it lists every failure in its description. One action per failed item is better when each finding will be fixed and verified separately, because each one links back to the exact question on the form.
If more than twenty-five items fail on one form, the rule gathers them into a single action instead, and says so on the action.
Who it goes to
The person who filed the form owns it by default. You can send it to the project lead instead, or to a named person. If a project has no lead set, the action falls back to whoever filed the form rather than being left unassigned, because an action nobody owns is one nobody chases.
Project leads are set under Settings, then Structure, when you edit a project. A continuous project often has two leads cross-shifting each other, so add all of them. The action goes to whoever your crew schedule says was on shift the day the form was filed; on days the schedule cannot answer for, it goes to the lead you marked primary.
The control level is left open
A rule does not choose a hierarchy of controls. The control level records what somebody decided after looking at the hazard — eliminate it, engineer it out, or fall back to a procedure — and at the moment a form is filed nobody has looked at it yet. So the action arrives with that question open, for whoever picks up the work to answer.
The investigation report tells an auditor what proportion of your controls are strong. An action that arrives pre-stamped with a level nobody chose would move that number using a default rather than a decision, so an undecided action is reported as undecided.
Seeing what the rules did
Below the rules is a log of every action they raised, and every one they could not, with the due date and the person each was given. Automation you cannot see the results of is automation you stop trusting, so the failures are listed alongside the successes.
A form filled offline and synced twice, or a page submitted twice on a bad connection, still produces one corrective action.
Forms that already raise something
A form that asks which unit it is about — a vehicle or equipment inspection, a trip inspection — already opens a maintenance deficiency for the equipment manager the moment any item on it fails. Point a rule at one of those and a single failed item produces two records: the deficiency and your corrective action, for two different people.
That is right for a serious defect, which deserves both the work order and a tracked action with a due date, and a lot for a routine one. The rule editor marks those forms and warns you before you save, so it is a decision rather than a surprise.
Correcting a form after it is filed
Editing a submitted form runs your rules against it again. Nothing is duplicated: an item that was already failing keeps the one action it has. An item you have newly marked as failed raises its own action, which is the point — recording a failure somebody missed should produce the work that failure deserves.
An action stays until a person closes it. Removing one because the form behind it was edited would erase the record of a finding without anybody deciding to.
Pausing and deleting
Pause a rule to stop it acting without losing how it was set up. Deleting one keeps every action it already raised, along with the record of why each was raised — an action whose explanation vanished when somebody tidied a list is one you cannot defend in an audit.
Tip. Start with one rule on one form and watch the log for a week. It is easier to widen a rule that is working than to unpick a hundred actions from one that was too broad.
Related articles
Track every fix from creation to verification.
Build by hand, scan a paper form, or generate from a description, then organize with folders.
Who signs off on completed work, and how often a fix is checked.