Intelex Compliance Tracker: three workflows, no way back

That is the whole shipped state machine. Two stages for an audit, one each for a task and a monitoring, five buttons in total, and not a single transition that moves a record backwards. A Compliance Audit that leaves Draft cannot return to it by any button. A monitoring has nowhere to go except done.

If your environment has a reject, a send-back or a reassign on any of these, somebody built it, and the section on customizations near the end is about why that matters.

The audit closes on a count, and the count can drift

The Compliance Audit workflow is where the shipped logic is densest, and where the traps are.

The Draft stage carries one button, Submit, whose entire flow is a transition to Schedule Audit. It validates nothing. A button named Submit that submits nothing is the first of several places where the label and the behavior part company.

Schedule Audit carries Complete Audit, and that button runs two checks in order. The first requires General Observations and Results to be filled. The second is the interesting one: it compares a number stored on the audit, the count of requirements it covers, against a live count of the audit's child requirement rows that have been given a status. Only if the two are equal does the workflow complete.

Read that again with a real audit in mind. The stored count is set when the requirements are attached. The Schedule Audit stage is also the only place in the shipped configuration that grants Delete on child records, to the person responsible and their supervisor. Delete a child row at that stage and the stored count no longer matches the live count. Every remaining row can carry a status and the audit will still refuse to close, indefinitely, with the message:

Please assign Status for all related Requirement Monitoring records.

Two things about that message are worth knowing before it sends you down the wrong corridor. The rows it is counting are the audit's requirement rows, not Requirement Monitoring records, which are a different object with their own workflow. And the first check's message, "Please enter Completion Date, General Observations and Results," names three fields while the condition tests two. Completion Date is never checked. An audit closes with it empty, and a user who has left only General Observations blank is told to fill in all three.

The task closes on a denylist

The Compliance Task workflow has one stage, Open, and one shipped button, Complete Action. Its guard is written as a refusal rather than a requirement: the button errors if Completion Status is "In Progress" or "New", and otherwise proceeds. The error text says the status "is not set to Completed", which is not what the condition tests.

The practical consequence arrives the day somebody adds a value to the Completion Status list. "On Hold", say, or "Deferred". Neither is on the denylist, so a task carrying either one closes cleanly, while the error message goes on asserting that only Completed will do. An allowlist would have failed safe. A denylist fails open, silently, and nothing on screen tells you which one you have.

Two smaller things on the same button. Completed By and Completion Date must both be filled, which is enforced here rather than by marking the fields required, so the fields look optional right up until the click. And when the task closes, the notification goes to whoever created it. The person who did the work receives nothing.

Closing also sets a separate yes-or-no field to mark the task complete, in addition to setting the workflow status. Two sources of truth for the same fact, which a report will eventually disagree about.

The monitoring has one stage and its guard is unreadable

Compliance Monitoring is a single stage, Under Review, whose status is named Assessment, and a single button, Assessment Completed. The button requires a Status and a Monitoring Date before the record can close, according to its own error message.

Whether that check actually runs before completion, or after it, cannot be settled from the configuration screen. In the configuration capture the completion step renders above the condition that is supposed to guard it, and the branch that should hold the completion is empty. Either the screen rendering has hoisted the nested step out of its branch, which is the sane reading, or the guard is inert and monitorings close with an empty status. Test it in your own environment before you rely on it, and do not take either version on trust.

This is also the only one of the three workflows with comments enabled at the workflow level. Audits and tasks have them off.

Three names for one object, and two words for done

Two naming problems run through the module and will cost a new administrator an afternoon each.

The monitoring record is called Compliance Monitorings in the menu, Compliance Monitoring on its workflow and on a section of its own create screen, and Requirement Monitoring as the object and in the title of the create screen. The error message on the audit borrows the name too, for rows that are not monitorings at all. Search the object list for the menu name and you will not find it.

Then the terminal statuses. A task ends at Closed. An audit ends at Completed. A monitoring ends at Completed. A closed task additionally carries its own Completion Status field, so its header reads "Closed (Completed)": the workflow status and the record's field side by side, saying the same thing in different words. Any report across all three record types needs both values or it undercounts.

The legal registry gives you bulk update for two flags and not the third

The reference material for this module says there is no mass update for Compliance Status, which is true and incomplete. The My Legal Registry inventory toolbar carries four bulk actions:

Clear Reassess | Set Applicable | Set Not Applicable | Set Reassess

So Applicability Status and the Reassess flag can be set across a filtered selection in one click. Compliance Status cannot, from this view: no column, no button. It is set on each record. For a registry that reports its row count as "1 - 100 of Many" rather than as a number, which this one does, that is the difference between an afternoon and a week.

One small thing about that toolbar. Clear Reassess sits to the left of Set Reassess. They are adjacent, they differ by one word, and one of them undoes the other across everything you have selected.

The Applicability Status values in use are Applicable, Not Applicable and To Be Assessed. The last of those is what a requirement arrives with when it comes in through a profile rather than being attached directly. A fresh registry fed from a content gateway therefore opens as a wall of To Be Assessed rows, and the four bulk buttons are how you get through it.

What the platform makes you decide first

Some of these are ordinary platform rules that happen to matter here. Others are specific to the module.

• Nothing takes effect until the workflow is published. Both the audit and

the monitoring workflow schemas carry the banner "This workflow has pending changes. It will need to be published before they take effect." Editing a button and forgetting to publish is the commonest reason a change appears to do nothing.

• Statuses exist before stages. Every stage requires a Status, and statuses

are a separately managed list with their own Create link. You cannot save a stage without one.

• Recurrence is where the due dates come from. The Draft and Schedule Audit

stages and the Under Review stage all resolve their due date from the start date of the record's recurring series. A record with no series has nothing to resolve and no due date. The task stage is the exception, taking its due date from a plain field on the record.

• Actions on create is off for two of the three. The audit and monitoring

workflows do not fire action handlers when a record is created. Only the task workflow does. Anything you expect to happen at creation on an audit will not.

• Trigger conditions only see the record's own fields. The helper text on

every button says so. Cross-object logic goes in the flow, which is exactly what the audit's child count does.

• Person Responsible is resolved four different ways across five stages.

Some stages point at a specific field, some at a field expression, and the two behave differently when the underlying value changes. Match the pattern of the stage you are copying rather than the one you last edited.

On the recurrence rule itself, which the reference material says reschedules a monitoring on its recurrence date even if the prior one is incomplete: the Recurrence section on all three workflow schemas was empty in the environment observed. The screens confirm the mechanism exists and that monitorings are the recurrence-bearing object, with a Frequency defaulting to One Time and an End Date on the create screen. These screens neither confirm nor refute the timing claim, and nothing will without a live series.

Who can close what, as shipped, is not uniform

The reference material states that only the person responsible or their supervisor can close a monitoring, task or audit. On the audit and monitoring stages that is exactly what the stage security says: custom permissions, two principals, edit and workflow action, nobody else.

The shipped task stage uses standard permissions with no custom rows. Whether that is how it left the vendor or how it was left afterwards is not provable from a screen, so take the narrower claim: in an environment you have not audited, the restriction may hold for audits and monitorings and not for tasks. Look at the stage security on all three before you tell an auditor who can close things.

What configured environments commonly add

Everything above is the shipped layer, identified by its creation record. Almost no environment runs it bare. The patterns below recur across configured environments, and they are described as patterns rather than defaults: what to expect when you open an unfamiliar environment, not what the platform guarantees.

A legal registry record carries more than the inventory shows. At the location level a requirement typically holds:

• its link to the global requirement, the regulatory domain and the jurisdiction
• the New and Repealed flags, with change notes and a version number
• a summary in more than one language, with a link to the source
• the supporting documents, meaning the records the rule requires the site to keep
• the applicability status and comments
• the task templates and task definitions, each with an action required, a next

date, a frequency and an end date, from which the actual tasks are generated

Tasks recur through their definition. When a task is updated, the workflow due date syncs and the next occurrence is created from the task definition's frequency. That is the recurrence mechanism the shipped screens could not show, and it explains the empty Recurrence section: the recurrence lives on the definition, not on the workflow.

Reminders run on the Event Service. Three scheduled notifications are the common set. Due today, to the person responsible and their supervisor. Overdue, to the same two. And an upcoming reminder ahead of the due date, to the person responsible alone. None of these is a workflow action. They run on a schedule with nobody clicking anything, which is why they keep working after the person who configured them has left.

Tasks get a way back. The usual pattern is an Open stage with Complete and Send Back actions, and a Send Back stage with a Submit action that returns the task to Open. The shipped table at the top has no such route, so if you see one, it was built, and it is worth reading its flow before relying on it, because a stage somebody added later was tested against the shipped buttons by nobody.

Audits link to their predecessors. Handlers commonly record the completion date and link each audit to the previous one for the same scope, which is what a trend comparison across audit cycles needs and what the shipped workflow does not do on its own. That the link is used for trending is an inference from its existence rather than something a screen states.

Security is role-based. Separate rights for a gatekeeper, regulatory experts, site leads, site support, plant management and view-only users is the usual shape, layered on top of the stage security described above.

The customizations are the part to worry about

Everything above is shipped, and shipped logic has one great virtue: it is the same in every environment. When your task workflow has a stage the table at the top does not show, three things follow.

First, it was built locally, and the person who built it may have left. Second, it interacts with the shipped buttons in ways nobody tested against the shipped buttons, which were written years earlier by someone who never saw it. Third, every one of the traps above is still present underneath it, because adding a stage does not change the closure gate, the denylist or the count.

The environment this was drawn from had exactly such a stage, added by an implementation partner three years after the shipped ones, and it is left out of this article on purpose. The point is not that customization is wrong. It is that the shipped layer is the only part you can reason about from a distance, and this article is that layer.

What this does not tell you

Field definitions, data types and required flags on any of the objects. What a Finding looks like, beyond the fact that findings are their own object and a Finding column appears on the task's requirements grid. When a recurring monitoring issues its next instance, which the patterns above do not settle. And whether any of this changed in a platform release after the one observed, because the stages carry 2016 creation dates and the capture is from 2026, which tells you the layer has been stable for a decade and nothing about next quarter.