The flow said Succeeded and the ticket still came
The case I keep seeing starts with a transfer in Workday HCM. The business process completes, and a Power Automate flow that listens for the event writes the new manager into Microsoft Entra ID and the new cost center onto a worker row in Dataverse that an expense app reads. Run history shows Succeeded on every action. Three days later a manager who has never met this person receives their expense report for approval, and the manager who has known them for years cannot see them at all.
The ticket that follows has nowhere to go. The identity team can see that the attribute changed but not what changed it. The maker who built the flow is out for the week. The expense app owner cannot tell whether Workday sent the wrong cost center or the flow mangled it. Every technical check passed, and one person is reporting to the wrong approver in three systems while nobody can say why.
The flow did what it was asked to do. The design left out who owns the result once the message has been delivered, what that person needs to see, and how they ask for it to be put right. Those three questions belong in the design review.
Succeeded describes the calls, not the outcome
Succeeded in Power Automate run history means every action returned without an error. It says nothing about whether the manager in Entra ID now matches the manager in Workday. I have watched a flow report success for months while a directory sync job reverted the manager within the hour, and the only evidence was a trickle of tickets nobody connected to the flow.
The change I ask for in review is a read-back. After the update action, read the attribute from the destination and compare it with the value the flow requested. When they differ, end the run with a Terminate action set to Failed and a message that names the worker ID, the field, the value requested and the value found. Run history then records whether the change landed.
Effective dating makes the read-back harder. Workday completes the transfer today with an effective date three weeks out. Act on completion and the new manager sees the worker early. Wait for the effective date and a rescind in between leaves the flow acting on an event that no longer exists. I ask the receiving owner which they can live with, write it into the design, and have the flow confirm the event is still in effect before it writes anything.
Find the person who gets the ticket on Monday
The flow has an owner. The result usually does not. In review I go destination by destination and ask who will be asked about this value when it is wrong at nine on Monday morning. For the manager attribute in Entra ID that is the identity team. For a leaver whose badge still opens the door it is physical security. None of them will accept the flow owner as the answer, because the flow owner is a maker who has never seen their queue.
Once the receiving owner is named, ask what they see when they open the ticket. If the answer is a run history page they cannot access, the design is not finished. The Architecture Clinic on queued work makes the same point about messages waiting in a queue. Delivery and responsibility are separate things.
A flow built under one maker's account runs on that maker's connections, and the leaver process is a poor place to discover that it depends on a leaver. Put the flow in a solution, add a co-owner from the receiving team, and run the connections under an account the identity team controls.
Send a record reference, not a sentence
The notification that reaches the receiving team usually says that an employee update has completed. No worker ID, no event ID, no effective date, no run reference. Every message, ticket and destination record the flow touches should carry the Workday business process instance ID, the worker ID, the field changed, the effective date and the flow run ID. Five values, and nobody has to open run history to find out what happened.
The reference breaks where identifiers do not line up. Workday has a worker ID, Entra ID has an object ID, and Dataverse has its own GUID. Match on email address and the next name change creates a duplicate, and the receiving team sees two rows. Pick a key that survives a name change and a rehire. The field guide to durable business keys walks through the choice, and for a worker it is almost never the email address.
Give the correction a path that works when the maker is on leave
A reference is only useful if there is somewhere to send it. The correction path I want is a ticket category or a short request form that lands with someone who can replay the original Workday event by its ID, or override the destination value with a recorded reason. Replying to the notification email does not count. The sender is a service mailbox, and the maker who would have read it is on leave.
Design replay in from the first version. Without it, someone types the right manager into Entra ID by hand, notes it nowhere, and the next run from Workday overwrites their fix. Overrides cover the opposite case, where Workday is wrong and the destination is right until HR processes the correction. The override needs an owner, a reason, an expiry and a record, the same shape as handling identity exceptions as owned work.
The operations review in where automation ownership breaks down records the work left behind after a failed run. Here the run did not fail, and the work still needs a home. In the meeting I ask who on the receiving team can trigger a replay, and where an override gets written so the next audit can find it. If the answer is one person and a spreadsheet, that becomes the next item on the list.
Keep an audit record that outlives run history
Power Automate keeps run history for a matter of weeks. That is no audit trail for a change to who approves someone's expenses. For each event I want four things in a table the receiving owner can query: the source event, the requested change, the approval boundary and the outcome.
The source event is the Workday business process instance and its type, so a reviewer can go back to Workday and see who approved it. The requested change is the field, the old value, the new value and the effective date. The approval boundary records what the flow may do on its own and where it must stop, for instance that a manager change for a worker with privileged access waits for a person. The outcome is the destination record ID, the timestamp and what the read-back found.
Then stop. The identity team does not need the home address or the bank details from the same Workday event, and copying them into a flow table creates a second store of personal data that someone has to protect and delete on request. Identifiers and field names are enough, because the reference takes a reviewer back to Workday, where the access controls already exist. Turn on secure inputs and outputs for the actions that carry the payload so the values do not sit in run history either.
The next time a flow that writes to a worker record comes to review, ask the person from the receiving team to describe the Monday morning ticket out loud, from the moment it lands to the moment it closes. Every gap in that story is a design item. Most of them take an afternoon to fix before go-live and a week of tickets to find afterwards.
