Retry within a fixed limit
A temporary service or connection fault may wait and retry. The count, delay and final failure remain in the run history.
Stop after the agreed limit and notify the operational owner.Automation
Replace reminder emails with an owned action and evidence workflow.
For reporting, operations and assurance teams whose recurring refreshes, reminders, approvals or follow-up depend on manual coordination.
Quanta Meridian records who must respond, which evidence version was submitted, what the reviewer decided and what condition allows the action to close.
When coordination becomes the work
Repetition is useful only when the people and decisions are understood.
An assurance coordinator is following 42 remediation actions across eight business units. Email can remind an owner, but it does not reliably preserve whether the owner accepted the action, which evidence version was reviewed or why closure was approved.
The workflow keeps the dated action in Lists or SharePoint, lets the owner submit through the app and records the reviewer response. Reminders and escalation follow the due date without replacing the human decision.
The same design supports quarterly access evidence: the assessor can return a wrong-period file, ask about leavers and accept a named replacement version without losing the earlier submission.
Orchestration circuit
Let the routine run. Keep its decisions and failures legible.
A trigger starts the recorded sequence through validation, owner response and human review. Short-lived technical faults may retry within a fixed limit. Invalid submissions and returned decisions go back to the named owner.
01 · TRIGGERAction assigned or reminder due
Action ID · owner role · due date
02 · VALIDATERole and transition are allowed
Required values · current status · permission
03 · ACTIONAccept action or submit evidence
Version · link · checksum · submitted date
04 · HUMAN REVIEWIs the evidence sufficient?
Accept · return · ask a question
05 · UPDATEWrite decision and next status
Owner · response · next due date
FAILURE CLASSIFICATIONTechnical fault or returned evidence?
Retry the connection or return the record to its owner
BOUNDED RETRY · 2 OF 3Wait, retry and record
Stop when the limit is reached
OWNER QUEUECorrect the submission or unblock the action
Evidence · due date · escalation
06 · AUDIT HISTORYRun, decision and outcome retained
Started · changed · decided · completed
01 · TriggerA new assurance action is assigned
Action, owner role, due date and finding recorded
02 · ValidateCheck the owner and allowed status change
Required fields, role and current history
03 · ActionOwner accepts and submits evidence
Evidence link, version and submission date retained
04 · Human reviewAn independent reviewer accepts or returns the evidence
Question, reason and reviewed version remain visible
05 · UpdateWrite the decision and next due date
Closure or rework cannot overwrite the earlier history
06 · Audit historyRetain every reminder, submission and decision
A future owner can explain why the action closed
Exception handling
Short-lived technical fault
Retry within a fixed limit, then stop and notify the owner.
Invalid input or rejected decision
Do not retry. Retain the reason and assign it for resolution.
Normal sequenceValidated work moves towards a recorded decision.
Human decisionJudgement stays with a named reviewer.
Exception handlingFailure is classified before retry or escalation.
Automation decision framework
Decide how the routine should operate before choosing the tool.
The method keeps the process, human decision and operating responsibility in view. A faster step is not useful if nobody can explain its failure or safely resume it.
The action, evidence requirement, owner, due date and allowed status changes are defined before the Canvas App or flow is built. Every command writes a dated history event.
Power Automate sends reminders and records responses, but a file upload does not close an action. The evidence reviewer accepts, returns or questions a specific version, and permissions restrict who can make that decision.
The retained implementation package includes the List schema, app formulas, flow definitions, role notes, transition tests and rebuild guidance. The public example does not claim a live tenant.
Failure, retry and recovery
Not every interruption should run through the same loop.
The automation records what happened, selects a proportionate response and stops when continuing would hide an unresolved problem.
Assign the record instead of repeating it
A missing file, invalid value or unresolved rule will not improve through repetition. Retain the input and send it to the person who can resolve it.
Resume only when the correction or accepted limitation is recorded.Return the work with its review context
A rejection is a human response, not a failed connector. Keep the reason, reviewer and requested change attached to the work.
Rework, review again and preserve both decisions.Automation types
Choose the operating surface that fits the work.
The options can work together, but each has a different purpose. The smallest maintainable workflow is preferable to a larger platform that the team cannot operate.
Power Query refresh routines
Use when
Repeated files share a stable structure and a controlled workbook or dataflow is the right operating surface.
Boundary
Expected files, schema drift, malformed inputs and release checks must remain visible rather than being skipped.
Power Automate workflows
Use when
Microsoft 365 records need reminders, approvals, owner updates or evidence follow-up with retained status history.
Boundary
Permissions, licensing, connections, environments and application lifecycle management are part of the design.
SQL and Python jobs
Use when
Transformations or checks need scheduled execution, code review, repeatable tests and retained run metadata.
Boundary
A scheduler starts work; it does not make the code idempotent, observable or safe to retry.
Notifications and approvals
Use when
A person must decide, acknowledge, supply evidence or respond before the next action can continue.
Boundary
A notification is not ownership. The request needs a due date, recorded response and escalation or expiry rule.
Report generation
Use when
An agreed dataset and template need a repeatable report with validation and a controlled issue decision.
Boundary
Automated production does not replace commentary, materiality review or release approval where those remain necessary.
Power Platform operating standard
A working flow still needs a controlled life after development.
Application lifecycle management covers how a flow is configured, tested, released, monitored and changed. It matters when an automation becomes part of a reporting or assurance routine.
Power Platform components should be packaged as a solution when they move between environments. Connection references and environment variables keep configuration out of the workflow logic.
Changes are tested away from live use, then released through an agreed version and recovery process. Exported definitions and release history show what changed and who authorised it.
Operational ownership continues after release. Someone remains responsible for failures, connections, permissions and the decision to change or retire the flow.
The project evidence below demonstrates controlled refreshes, workflow states and retained review history. It is not presented as a deployed Power Automate solution or as evidence from a live client tenant.
The workflow handover
A workflow that can run, fail, recover and pass to a new owner.
Decide what should run
Make the current process, decisions and exceptions clear enough to choose a proportionate automation.
The workflow handover retains current process and automation decision map and trigger, owner and system-of-record definition.
Build and test the routine
Connect the trigger to validated actions, human review and a deliberate response when the routine fails.
The workflow handover retains controlled refresh, workflow or scheduled job and validation, exception, retry and recovery tests.
Operate and hand over
Leave the next owner with the history, release instructions and information needed to maintain the automation.
The workflow handover retains run, approval and status history and ownership, environment, release and recovery notes.
Related project evidence
Two working routines connect failed data and commentary to named decisions.
The examples cover a missing product code and a management commentary request. Each project states what has been built and what remains outside the evidence.
01
One reporting incident from detection to release
Reporting Data Issue and Retest Register
A reporting data incident register that starts with a retained failed row and ends with verified closure, an approved limitation or a continued hold.
PRD-UNKNOWN is replaced by PRD-01001. The retained SQL returns Product category 06 and PASS before the reporting owner releases the corrected report.Inspect this project02
One movement from figure to follow-up
Monthly Performance Commentary and Decision Log
A working Excel process that requests explanations for significant metric movements before the monthly meeting and carries unanswered decisions and actions into the next reporting cycle.
Seven retained records connect the starting metric, breached threshold, manager explanation, finance challenge, meeting decision and January action.Inspect this projectRelated capabilities
Connect workflow design to the records and people involved.
Excel and Power Query
Excel and Power Query are used when people need a familiar workbook without hiding file intake, transformation logic, adjustments or checks.
See how it is used in projectsSQL
SQL gives invoice lines, orders, receipts and reference data a declared grain before they become shared reporting totals.
See how it is used in projectsPython
Python turns a reporting check into an executable rule that retains the failed rows, run time, affected report and later retest.
See how it is used in projectsWorking boundary
Automation should expose responsibility, not make it disappear.
Automation follows an understood process. It does not repair unclear rules, remove necessary judgement or prove a production Power Platform deployment without the native solution, environment, security and run evidence.
Bring one recurring routine, its current trigger and a short account of the decisions or failures that still need people. Confidential or protected data is not needed for the first conversation.
Discuss a repeated processReturn to all solutions