A request for a Power App often arrives after the underlying problem has become normal.
A spreadsheet controls an approval. A shared inbox doubles as a work queue. Someone maintains a local file because the ERP process does not support the job cleanly. Another employee knows which exceptions need chasing because nobody has documented the rule.
Individually, these can look like minor workarounds. Together, they can become an unofficial operating layer that the business relies on but does not properly control.
Expose the unofficial process before discussing technology
What should you do before building a Power App or adding AI?
Before building a Power App or adding AI, map how the process really works: its spreadsheets, inboxes, paper forms, local files, duplicate records, handoffs, exceptions and dependencies on individual employees. Identify who owns each step, where information is re-entered and what fails when somebody is unavailable. Choose the technology only after that diagnosis.
That is the purpose of Power Apps process discovery: understanding the current process, users, data, ownership, exceptions and business friction before deciding what Microsoft technology should change.
The distinction matters. Digitising a workaround does not necessarily remove the reason the workaround exists.
When does a workaround become a business risk?
Spreadsheets are useful. Risk rises when a temporary tool quietly becomes part of a business-critical process without comparable controls around ownership, testing, continuity and change.
Deloitte’s guidance on spreadsheet controls highlights practical questions around purpose, testing, accountability and knowledge concentration. It also recommends maintaining an inventory of important spreadsheets and assessing them according to risk, materiality and complexity.
Those questions extend beyond spreadsheets.
Who owns the workaround? Can somebody else run it safely? Is the latest version obvious? Can approvals be traced? What happens if a file is missed, a formula is changed or the person who understands the process is absent?
When those answers are unclear, the issue is no longer simply administrative inconvenience. Managers may be relying on information they cannot readily verify, while teams depend on processes whose continuity rests on individual knowledge. That is the spreadsheet workflow business risk behind many manual spreadsheet business processes.
Use the TRACE Test before you scope a solution
A practical way to structure discovery is the TRACE Test:
- Track unofficial tools.
- Record repeated hand work.
- Account for exceptions and memory.
- Clarify the root cause.
- Evaluate the right intervention.
The order matters.
GO ERP approaches Power Platform work from the business pain and the way work is actually performed, then moves into process design, data, architecture and technology choice. A Power App may be the right answer. Power Automate, an integration, process redesign or a combination may remove more friction.
First, establish what is already keeping the process running.
Follow the hand work to find where the process is breaking
Once the unofficial tools are visible, follow the information through the process.
Repeated hand work is one of the clearest signals: rekeying customer details, copying order numbers between systems, updating the same status twice, reconciling spreadsheet totals against ERP data or moving information from email into a local tracker.
None of these tasks needs to be dramatic to matter. Repeated across a working week, a month or a high-volume process, they show where employees have become the manual connection between systems or process steps.
What does repeated manual work tell you?
Repeated manual intervention often points to a break between systems, data structures or process ownership. The useful question is not simply how long the task takes. It is why a person has to bridge two parts of the process manually in the first place.
Consider a service team that receives requests through a shared inbox, copies key details into a spreadsheet, checks customer data in Dynamics 365 and emails another team for approval.
A Power App could replace the spreadsheet with a better interface. Yet staff could still be rekeying the same information, waiting for emailed approvals and checking several places to understand the status of one request.
A business process automation assessment should therefore trace information from its source to the point where the business outcome is completed.
| Manual step | What to examine | Business consequence |
| Rekeying data | Frequency, source and destination | More handling time and greater opportunity for entry errors |
| Copying data between systems | Why the systems do not exchange it directly | Duplicate or inconsistent records |
| Manual reconciliation | What repeatedly creates the mismatch | Slower reporting and weaker confidence in the numbers |
| Repeated chasing | Where routing or ownership breaks down | Delayed decisions and missed handoffs |
| Spreadsheet updates | Who relies on the file and how it is controlled | Version, continuity and ownership risk |
This turns hidden manual work processes into evidence that can support prioritisation rather than relying on general complaints that a team is too busy.
For complex processes, process mining can reconstruct flows from system event data, while task mining can expose desktop-level activity such as work across spreadsheets, documents and email. These techniques are useful when observation alone does not show enough of the process. They are diagnostic tools, not prerequisites for every automation project.
Do not build another screen when the problem is data movement
Repeated re-entry can indicate that integration, workflow redesign or clearer data ownership would remove more work than a standalone app.
That distinction has a direct commercial consequence. A technically successful Power App can still leave the original cost and control problem intact if employees continue moving the same information around it manually.
The second TRACE step is therefore Record: identify where human effort is compensating for disconnected data, systems or process design.
The next issue is less visible. Some of the work holding the process together may never appear in the system at all.
Find the work that exists only in people’s heads
Some of the most important manual work never appears in a spreadsheet.
It is the approval someone knows to chase. The customer exception an experienced employee handles differently. The queue a manager checks because ownership is unclear. The personal tracker used because the formal process does not show what needs attention next.
These behaviours matter because the documented process and the process people actually follow are no longer the same.
Research into process workarounds supports an important distinction: a workaround may create risk, but it may also compensate for a weakness in the prescribed process. Removing the workaround without understanding why it exists can remove something the process currently depends on.
Which exceptions should you automate?
Do not assume every manual exception should disappear. First establish whether it represents necessary human judgement, a legitimate process variant, an unclear rule or an ownership gap.
Take an invoice approval that appears straightforward on paper. Experienced staff may know that certain contract types require an extra check. If that rule exists only in somebody’s memory, automating the documented route could make approvals faster while quietly removing a control the business relies on.
The third TRACE step is Account: identify the exceptions, judgements and workaround behaviours that keep the process functioning.
For each one, ask:
- What triggers the deviation?
- Is the deviation legitimate or avoidable?
- Who decides what happens next?
- Can the decision rule be documented?
- What happens when the usual person is unavailable?
These questions separate necessary human judgement from accidental manual work. They also expose key-person dependency before it is embedded in a new system.
System data does not show everything people do
Process mining can reveal unexpected process variants, but event data has limits. Research into workaround detection found that some activity outside the formal system could not be identified from event logs. A phone call or informal check, for example, may leave no usable system trace.
That is why interviews and observation still matter in serious Power Apps process discovery, particularly where Teams messages, calls, paper notes or remembered checks sit outside the recorded workflow.
Power Platform can support approvals, exception routing, audit trails and controlled workflows. Low-code still requires sound design, security, testing, ownership and governance when the resulting application becomes part of a business-critical process.
A prototype used by one person and a production process relied on by a department carry very different consequences. A failed flow, unclear exception route or poorly owned dataset becomes an operational problem once people depend on it to get work done.
The principle is simple: do not automate ambiguity at scale.
Choose the intervention that removes the cause
Once the process has been traced, measured and challenged, technology selection becomes much easier.
The final TRACE steps are Clarify the root cause and Evaluate the right intervention.
The sequence prevents a common mistake: treating the requested technology as the requirement.
GO ERP’s Power Platform work sits within a wider business applications capability spanning process design, Power Apps, Power Automate, integration, data architecture and Microsoft business systems. That matters when the correct answer crosses product boundaries rather than fitting neatly into one tool.
Power App, automation, integration or AI: which fits the problem?
| What you find | Likely response | Risk of choosing too quickly |
| Poor or inconsistent data capture | Power App or process redesign | A new interface collecting the same weak data |
| Repeated approvals and routing | Power Automate | Faster movement through an unclear process |
| Duplicate entry between systems | Integration | Another screen without removing rekeying |
| Numerous unknown process variants | Further discovery, task mining or process mining | Automating only the visible path |
| Repetitive work involving unstructured documents or messages | Targeted AI capability | AI operating on weak data or unclear rules |
| Unclear ownership and exceptions | Governance and process redesign first | Scaling ambiguity |
This is where a business process automation assessment earns its value. Its purpose is not to justify an app. It is to establish what friction should be removed, what is causing it and which intervention best fits the problem.
The same discipline should apply to Power Platform process automation more broadly. Automation is useful when the underlying process and decision rules are sufficiently clear. If they are not, technology can make weak decisions happen faster and across a larger volume of work.
Four questions to ask before you build
What should Power Apps process discovery include?
Power Apps process discovery should cover the current workflow, users, systems, spreadsheets, handoffs, data, exceptions, ownership, controls and measurable sources of friction. The aim is to understand the problem well enough to decide whether an app is actually required.
When is Power Automate a better fit than Power Apps?
Power Automate is often the better fit when the main requirement is routing, approvals, notifications or repetitive workflow between defined steps. Power Apps is more relevant when users need a purpose-built interface for capturing, viewing or managing data.
When is integration a better answer than a new app?
Integration is often the better answer when employees repeatedly copy the same information between systems that should exchange it directly. A new app may improve the interface without removing the underlying duplication.
Should AI be added before a manual process is redesigned?
Usually, no. AI needs a clear use case, usable data, defined decision boundaries and appropriate human oversight. It should support a process the business understands rather than compensate for one whose rules, ownership and exceptions are still unclear.
Start with one process, not a technology wishlist
Choose one spreadsheet-heavy, inbox-driven or exception-heavy process and run it through TRACE.
A Power Platform process discovery and automation-readiness review can map the users, data movements, handoffs, controls, exceptions and measurable friction in that process. The result should be a clear view of what to automate, integrate or redesign, what needs stronger governance first, and whether a Power App or AI capability is justified at all.
That is a stronger starting point than asking where Power Apps or AI can be used.
It starts with the work the business is already doing and then chooses the technology that removes the right problem.
