Two flows writing the same column on the same trigger

Flows on one trigger write the same column in undefined order.

Two or more enabled flows react to the same change to the same table and write the same column. Flows run independently, so nothing defines which finishes last and the final value is whichever run wrote it last. That can look stable for months and flip when a connector throttles or a run is retried.

Pathix compares the trigger each flow subscribes to (table, change type, filtering columns) against the columns each flow is parsed as writing, so both the co-firing and the overlap are read from configuration rather than guessed. Flows sharing a trigger but writing different columns are not flagged, and neither are flows whose triggers filter on different columns. Pathix does not claim one flow is a copy of the other: two flows deliberately splitting work across one trigger look identical from here.

List enabled flows with a Dataverse row-change trigger, grouped by table and change type, then compare the trigger's filtering columns and the columns each flow updates. Two flows that fire on the same change and write the same column are the finding. The symptom is a value that differs depending on timing rather than on who saved.

Decide which flow owns the column and remove the write from the other, or make one a child flow the other calls so two independent runs become one ordered sequence.

This one is environment health, so it carries a plain label and no control mapping. Presenting an operational gap as a security finding would make the real security findings harder to trust, so we keep the two apart.

• A plugin step that re-triggers itself on every save
• A cloud flow that re-triggers itself on every run
• Two plugin steps at the same execution order writing one column
• A flow calling a child flow that is switched off