Make the real workflow visible before adding technology
Before approving Power Apps, workflow automation or another system change, map how the work really moves today. Capture each step, handoff, approval, data entry point, queue, exception and owner. A broken workflow is often not a technology gap first. It is usually delay, rework, double entry or unclear accountability made visible through daily friction.
Most leaders do not see the full workflow. They see the complaint.
A customer update takes too long. A purchase request sits in approval. A finance task needs chasing. A sales or service team re-enters the same information in more than one place. Someone builds a spreadsheet outside the official process because the system feels too slow, too rigid or too unclear.
Those symptoms matter, but they are not the diagnosis.
A broken workflow usually shows itself through five everyday signals:
- work waits in the same place for too long
- people re-key information already captured elsewhere
- approvals depend on chasing rather than clear rules
- errors return work to an earlier step
- teams rely on informal workarounds to keep things moving
Each one carries a business cost. Waiting slows delivery. Re-keying increases error risk. Chasing consumes management time. Rework weakens trust in the process. Workarounds hide the truth from reporting.
That is why the first job is current-state mapping. Not the ideal version written in a procedure document, but the lived version: who receives the request, what information they need, where they get stuck, which system they use, who approves, what happens when something is missing, and where the customer or internal user feels the delay.
A useful workflow map should expose three things.
First, the handoffs. These are the moments where work moves between people, teams or systems. Handoffs often reveal ownership gaps.
Second, the repeated inputs. These show where data is being copied, corrected or rebuilt instead of flowing cleanly.
Third, the hidden queues. These are the waiting points that do not appear on a dashboard, yet determine how long the process really takes.
Take a purchase approval. The visible complaint may be that finance takes three days to approve requests. The root cause may sit earlier: missing supplier details, unclear spending limits, duplicate document checks or no agreed route for exceptions. Automating the finance approval alone would speed up the wrong part of the process.
A better diagnosis protects the business from building technology around confusion. It gives leaders enough evidence to ask the right next question: which workflow problems genuinely affect speed, control, visibility or customer confidence?
Prioritise workflow pain by business impact, not noise
Fix the workflow problem that creates the greatest business drag, not the one that generates the most complaints. A useful workflow diagnosis scores each issue against four outcomes: speed, control, visibility and customer confidence. This keeps leaders focused on operational risk, cost and decision quality rather than isolated frustration.
A slow task is not always a strategic problem. A noisy process is not always the most damaging one.
The better question is: what does this broken workflow weaken?
Use The Workflow Drag Test to separate irritation from impact
| Workflow signal | What to test | Business risk |
| Work waits in a queue | Does the delay affect delivery, billing, fulfilment or response time? | Slower cash flow, missed deadlines, weaker service |
| Data is entered twice | Does re-keying create errors or reconciliation work? | Higher admin cost, poor reporting, lower trust |
| Ownership is unclear | Does work stall because no one knows who acts next? | Delayed decisions, escalation, management drag |
| Exceptions are handled manually | Are teams inventing their own route each time? | Inconsistent control, audit risk, poor scalability |
| Leaders lack visibility | Can managers see status, blockers and workload? | Late intervention, weak planning, poor accountability |
| Customers chase updates | Does the workflow create silence or uncertainty? | Lower confidence, reputational damage, service pressure |
This is where workflow diagnosis becomes commercially useful.
A duplicated internal task may annoy a team, but if it only costs five minutes a week, it may not justify a build. A hidden exception process in order fulfilment, finance approval or customer service may look less visible, yet create late deliveries, billing delays, compliance gaps or customer complaints.
Prioritisation should balance value versus complexity.
High-value, low-complexity fixes are usually the first candidates. These might include removing a redundant approval, clarifying who owns each stage, standardising required fields, or building a simple Power App to capture requests consistently.
High-value, high-complexity issues need more care. A workflow that crosses sales, finance, operations and customer service may need integration, Dynamics 365 process redesign, reporting changes and a stronger governance model. Trying to fix that with a quick app alone can move the bottleneck rather than remove it.
Low-value, high-complexity fixes should be challenged. They often become expensive distractions.
For operational leaders, the strongest workflow improvements usually sit where manual drag affects one of four things: how fast work moves, how well the business stays in control, how clearly leaders can see performance, or how confidently customers experience the business.
GO ERP’s view is practical: do not start with the technology category. Start with the drag. Once the business impact is clear, the right solution path becomes easier to choose.
Do not automate a bad habit
Process change should come before Power Apps or automation when the workflow has unclear rules, poor data, too many exceptions or no agreed owner. Technology works best when it supports a process the business already understands. If the process is confused, automation can make the confusion faster, harder to govern and more expensive to unwind.
This is the common trap: a team feels pressure, asks for an app, and the business assumes the request is the requirement.
It may not be.
A workflow that depends on memory, favours, inbox chasing and spreadsheet fixes is not ready to be digitised as-is. It needs to be simplified first. The work needs clearer entry criteria, fewer unnecessary approvals, defined ownership and agreed exception routes.
The question is not “Can we automate this?”
The question is: should this workflow exist in its current form?
A few red flags should pause any build decision:
- different teams follow different versions of the same process
- approvals depend on personal judgement rather than agreed rules
- data arrives incomplete, duplicated or in the wrong format
- exceptions are more common than standard cases
- no one owns the workflow end to end
- reporting is weak because users capture information inconsistently
Power Apps can be a strong answer when a business needs a focused, usable tool to capture information, guide users through steps, reduce spreadsheet dependency or connect a process into the Microsoft ecosystem. Power Automate can remove manual handoffs, trigger alerts, route approvals and keep work moving.
Both are valuable when the workflow has enough discipline to support them.
They are risky when the organisation is still debating what the process should be.
For example, a service team may want an app to manage customer complaints. The build may be straightforward. Yet if complaint categories are unclear, escalation rules vary by manager, and no one agrees what “resolved” means, the app will only give the old confusion a cleaner screen.
That creates a second problem: adoption. Users quickly lose trust in tools that reflect awkward processes. They work around them, data quality drops, and leaders start questioning the platform rather than the design decisions behind it.
A safer route is to fix the operating logic first.
Before building, ask three questions:
- Can we remove steps before we digitise them?
- Can we clarify rules before we automate decisions?
- Can we define ownership before we route work between teams?
Once those answers are clear, technology becomes easier to scope and safer to support. The business can then choose whether the right move is a simple process change, a low-code app, an automated approval, an integration, a reporting layer or a deeper Dynamics 365 improvement.
Good workflow design does not slow technology down. It prevents avoidable rework later.
Choose the safest, simplest solution path
Choose the lightest fix that removes the real constraint without creating future support risk. A broken workflow may need process change, Power Apps, automation, integration, reporting, Dynamics 365 improvement or wider redesign. The right route depends on the cause of the drag, the data involved, the ownership model and the scale of the process.
The safest solution is rarely the biggest one.
A strong workflow diagnosis should lead to a clear decision route:
| If the diagnosis shows… | The likely fix is… | Watch for… |
| Unclear ownership | Process redesign | No named owner after change |
| Too many approvals | Rule simplification | Governance being weakened rather than improved |
| Repeated manual entry | Power Apps or automation | Poor data rules being copied into the new flow |
| Disconnected systems | Integration or Dynamics 365 improvement | Fragile links and unclear data ownership |
| Weak status visibility | Reporting or dashboard improvement | Reporting before data is trusted |
| High exception volume | Process redesign before automation | Automating edge cases too early |
| Cross-functional operating pain | Wider system or operating model review | Over-scoping before priorities are agreed |
This is where solution architecture earns its keep. A low-code app may be enough for a controlled departmental workflow. Power Automate may be right for repeatable approvals and alerts. A Dynamics 365 change may be better when the process already belongs inside CRM, Business Central or Finance & Supply Chain Management. A wider redesign may be needed when the issue crosses data, people, systems and governance.
The decision should also test what happens after go-live.
Who owns the workflow? Who maintains the app? Who approves changes? What data is mandatory? What reporting will prove the fix is working? How will users be trained? What happens when the business grows, adds sites or changes rules?
Without those answers, a quick fix can become another workaround.
FAQ
What is a broken workflow?
A broken workflow is a process where work slows, repeats, disappears, waits for unclear decisions or depends on manual chasing.
When should you use Power Apps for workflow improvement?
Use Power Apps when the process is specific, repeatable, data-led and too awkward for spreadsheets or email, but does not require a full system rebuild.
What is the difference between process mapping and workflow automation?
Process mapping shows how work moves today. Workflow automation removes or reduces manual steps once the process is clear enough to govern.
How do you find a business process bottleneck?
Look for queues, rework, missing information, repeated data entry, unclear ownership and customer-facing delays.
The practical next step is a focused workflow diagnostic. GO ERP can help map the current process, identify where manual drag is damaging speed, control or visibility, and define the safest route before money is committed to Power Apps, automation or wider system change.
