Overview
Automation fails quietly, which is what makes it dangerous
A broken flow does not throw an error banner across your intranet. It stops, an approval sits unactioned, and three weeks later someone asks why their request never came back. Building automation that degrades visibly is as important as building it at all.
- Designed around real constraintsFlow run duration caps, API throttling, connector limits and licensing boundaries factored into the design, not discovered in production.
- Failure handling built inRetry policies, error branches and notification on failure so problems surface immediately rather than silently.
- Documented and ownedEvery flow documented with its trigger, purpose, owner and dependencies, so it does not become an orphan when someone leaves.
- Governed connectionsService accounts and connection references handled properly, so a flow does not break the day an employee’s licence is deactivated.
Architecture
Approvals that survive the run limit
Splitting creation from response means the process persists in a list rather than inside a single flow run, so an approver on leave does not silently destroy the request.
What is included
What we build
Approval workflows
Multi-stage approvals with delegation, escalation and reminders — architected to survive the platform’s thirty-day run duration limit.
Document processing
Automated routing, metadata stamping, retention actions and library-to-library movement triggered by content type or column value.
Power Apps forms
Canvas and model-driven apps replacing complex SharePoint list forms, including offline-capable field applications.
System integration
Flows connecting SharePoint to Outlook, Teams, Dataverse, SQL and external APIs through custom connectors where needed.
Scheduled operations
Recurring jobs for reporting, data synchronisation, cleanup and archival, with alerting when a run fails.
Remediation of existing flows
Auditing an estate of flows nobody owns any more, documenting what each does, and fixing or retiring them.
In practice
The thirty-day problem
Power Automate flows have a hard maximum run duration. An approval built as a single flow — create the approval, wait for the response — will terminate if the approver takes longer than that window, and the request vanishes with no error anyone sees.
In organisations where approvals routinely sit with someone on leave, this is not a theoretical limit. The fix is to decouple the creation of an approval from waiting on it, so the process survives across flow runs and can be resumed, escalated or reassigned.
This is the kind of thing that separates automation that works in a pilot from automation that works in year two. It is also the kind of thing we would rather design in from the start than retrofit after a stuck approval costs somebody a deadline.
Questions
Common questions
Do we need Power Automate premium licences?
It depends on the connectors involved. Standard connectors cover a great deal; Dataverse, SQL and custom connectors are premium. We identify the licensing implication during design, before you commit.
Can you automate a process that spans several systems?
Yes. That is usually where the value is. Cross-system processes need more attention to error handling, because there are more places to fail.
What happens when a flow breaks?
Flows we build notify a named owner on failure and log enough context to diagnose the cause. Silent failure is a design defect, not an accident.
Can you take over flows built by someone else?
Yes. We start by auditing what exists, since undocumented flow estates are common and frequently contain duplicates and orphans.