Microsoft Power Platform
Build the process you need.
Without rebuilding the platform you already have.
Process gapControlled solution
Not every business requirement belongs inside ERP, and not every workflow needs a new enterprise application. Power Platform can extend Microsoft business applications with focused apps, automation, data and external experiences where there is a genuine process gap. The important question is not whether we can build it. It is whether we should.
Low code should reduce business complexity, not create technical complexity somewhere else.
Low code makes building easier. It does not make architecture optional.
Power Platform can accelerate useful change. But without ownership, environment strategy, data governance, a commercial view and lifecycle control, a collection of helpful apps can become another form of technical debt.
In short
What this page decides.
- Power Platform closes focused process gaps between the applications you already run.
- Standard capability, configuration and automation should be exhausted before anything is built.
- Applications extend ERP and CRM processes. They do not become a second system of record.
- External access, AI and agents change the qualification, not just the build.
- Governance, licensing, support and adoption decide whether a solution survives its first year.
The fit decision
Seven questions before anything is built.
This is a decision sequence rather than an automated architecture answer. Most requirements stop before question three, and that is usually the cheapest outcome available.
1. Does standard ERP, CRM or another existing application already support this process sufficiently?
Yes: use or configure the standard capability. Nothing needs to be built.
No: continue.
2. Is the requirement primarily a known deterministic rule or handoff?
Yes: automate it. A rule that is already known rarely needs a new interface.
3. Does a defined user group need a focused experience around structured business information?
Yes: consider Power Apps, with a named owner and a support route.
4. Does the process involve external customers, suppliers, partners, citizens or other external users?
Yes: consider Power Pages, but qualify identity, access, data exposure, security, volume and the commercial model first.
5. Does the process require interpretation, conversation or knowledge assistance?
Yes: consider Copilot Studio or wider AI capability, after governance qualification.
6. Does a mature specialist product already solve the requirement better?
Yes: evaluate buy against build honestly, including the cost of owning what you build.
7. Is the process itself unclear or disputed?
Yes: Transform the process first. Building freezes a disagreement into software.
Possible outcomes
- Use standard capability
- Configure
- Automate
- Power Apps
- Power Pages
- Copilot Studio
- Specialist ISV
- Broader custom development
- Transform
- Recover
- Optimise
Build, buy or extend
Move right only when the option to the left does not satisfy the requirement.
Custom build is not inherently wrong. It simply carries the most ownership, so it needs the clearest justification.
Use standard
Capability already owned, already supported, already tested.
Configure
Settings, rules and roles inside the existing application.
Automate
Known rules and handoffs, without a new interface.
Extend
A focused Power Platform solution around the existing process.
Buy specialist
Where a mature product genuinely does the job better.
Custom build
Justified, owned, governed and supported.
The further the solution moves from standard capability, the clearer the value and ownership case needs to become.
Close the process gap
Use Power Platform where the requirement sits between standard applications.
These are the gaps that rarely justify a new enterprise system, but quietly cost time every week when they are handled by email, spreadsheets and memory.
- Approval
- Inspection
- Mobile form
- Case workflow
- Internal request
- Site process
- Partner process
- Data capture
- Exception management
- Customer or supplier portal
- Operational task
- Document workflow
Focused problem. Focused application.
The capabilities we use
Power Platform capabilities we use to close process gaps.
Described by the job they do rather than as a product catalogue. Most useful solutions combine two or three. Very few need all of them.
Power Apps
Focused business applications for a defined user group and a defined task.
Power Automate
Cloud workflow, approvals, automated coordination and orchestration between applications.
Power Pages
External business experiences for customers, suppliers, partners or citizens.
Copilot Studio
Governed conversational and agent experiences where approved knowledge and actions exist.
Dataverse
Structured application data, relationships and security beneath Dynamics 365 and Power Platform solutions.
Power BI
Part of the Power Platform portfolio. We treat reporting and analytics as a separate decision journey.
Focused applications
Give people the workflow they need for the task they are doing.
Open only what is relevant. Fit matters more than capability: the same tool can be an excellent answer and a poor one depending on the scope.
- Warehouse exception
- Site inspection
- Approval
- Field form
- Case process
- Internal request
- Quality workflow
- Project action
- Service process
- Delivered as canvas apps, model-driven apps or mobile experiences
A low-code tool should not be used to avoid making a platform decision.
Automation
Automate predictable coordination.
Most operational delay is not complex. It is waiting for someone to be told something.
- Cloud workflow
- Approval
- Notification
- Task creation
- Data movement
- Reminder
- Escalation
- Document routing
- Status update
- System-to-system orchestration
- Automated coordination between teams
Invoice exceeds approval limit
A known rule, not a judgement.
Route to approver
The right person, based on the rule.
Record decision
The outcome is captured, not remembered.
Update status
The system of record reflects reality.
Notify requester
Nobody has to chase for an answer.
No AI required
Every step above is a known rule. If the rule is known, ordinary automation is usually better than AI: cheaper, faster, easier to test and easier to explain to an auditor.
Where AI may help
Summarising the supporting context, extracting information from the document, or drafting the explanation the approver would otherwise write by hand.
Our scope
Our Power Automate work is deliberately focused on cloud workflow and business orchestration. Desktop automation and process mining are not part of the current offer. Where a requirement genuinely needs them, we will say so rather than reshape the requirement to fit.
Structured business data
Decide authority before copying data.
Dataverse provides tables, relationships, security and integration for application data. It is not simply somewhere convenient to put a copy of something.
- Tables
- Relationships
- Security
- Business rules
- Audit capability
- Integration
- Application logic
Authoritative operational data
Financial, inventory and transactional truth normally belongs in ERP. Dataverse may be authoritative for relationship, service or application-process information where the architecture assigns that responsibility.
Reference and context data
Copied to make an experience usable, owned elsewhere. The source, refresh route and reconciliation should be explicit.
Analytical copies
Reporting representations of operational truth. They inform decisions. They do not own them.
Documents
SharePoint is often the appropriate home. Do not force large documents into business tables unnecessarily.
Before duplicating anything
- Why is this data required here?
- Which application is authoritative?
- Who owns its meaning and quality?
- How do changes flow, and in which direction?
- How are failures detected and handled?
- How is duplication reconciled?
External experiences
External access changes the risk profile.
Extending a process beyond the organisation should be a deliberate decision rather than a natural next step. Five questions decide the shape of the service before any technology is chosen.
- Customer
- Supplier
- Partner
- Citizen
- Service user
- Another party acting on someone's behalf
Power Pages suits some external experiences well, particularly where the process already lives in Dataverse. It is not automatically the best external portal technology, and the honest answer is sometimes a different platform or no portal at all.
Extend, do not replace
The app should extend the ERP process. Not become a shadow ERP.
A well-designed extension takes the work out to where it happens, then returns the result to the system that owns it. The same principle applies to CRM.
ERP or CRM
Finance, purchasing, inventory, production, projects, customers and cases.
Power Platform
Focused workflow, mobile experience, approval or external form.
Back into the system of record
The approved result, the transaction and the status.
- The Dynamics 365 customer engagement applications provide the customer, relationship, opportunity, case and service context
- Power Platform may extend them with focused workflow, an external experience, an internal app, approval or automation
- Because those applications already use Dataverse, the architecture can be particularly natural where the requirement genuinely fits
- A Power Platform solution should not accidentally become an ungoverned second system of record
AI-assisted workflow
AI interprets, workflow governs.
AI can add interpretation to an otherwise deterministic process. The workflow still decides what happens next, and not every workflow needs AI at all.
- Extract information
- Summarise context
- Classify request
- Draft response
- Find knowledge
- Prepare recommendation
- Analyse text
Read approved context
Only the information the agent is permitted to see.
Prepare a recommendation
Interpretation, not an unreviewed decision.
Call an approved action
A defined Power Platform action, not open access.
Request human approval
Where the consequence justifies it.
Execute
Under a known identity, within known limits.
Record the result
Audit and reconciliation, not assumption.
- The requirement is a low-code conversational or agent experience
- The experience sits around Microsoft 365, Dataverse or approved business systems
- Known knowledge sources are available
- Approved actions and workflows are defined
- Governance requirements fit the platform
An agent should not gain an unrestricted set of actions simply because the platform makes them easy to connect.
Cost of ownership
Low code still has a commercial architecture.
Low code can reduce delivery friction while still creating meaningful operating cost. These are the factors we qualify before a design is agreed, using current Microsoft terms at the point of design rather than assumptions published here.
- User population
- Internal and external users
- Premium capabilities
- Connectors
- Dataverse capacity
- Environment strategy
- Power Pages use
- Automation volumes
- AI and agent consumption
- Managed Environment requirements
- Integration
- ISV components
- Support
- Administration
The technically right solution still needs to be commercially sensible to own.
Explore LicensingBuild with control
Governance should be built into the platform, not stored only in a policy document.
Every app needs an owner before it needs another feature. The depth of control should be proportionate to the importance of the process.
- Business owner
- Technical owner
- Data owner
- Support model
- Monitoring
- Lifecycle and retirement
- If nobody owns the app, the organisation already has technical debt
If nobody owns the app, the organisation already has technical debt.
Application lifecycle management
Deliberate change, not manual and hopeful deployment.
Open the detail only if it is relevant to your position.
Confidence gates
Four points where we confirm this is still the right thing to build.
A gate is a short decision conversation, not a governance ceremony. Stopping at a gate is a legitimate and often valuable outcome.
Gate 1
Before design
Fit and value
Confirm that this is a genuine gap, that it is owned, and that closing it is worth the cost of owning a solution.
Confirmed at this gate
- The business problem
- A named owner
- The users
- Existing standard capability
- Alternatives considered
- Measurable benefit
- Power Platform fit
Decision
Configure standard · Automate · Build · Buy · Transform · Stop
Gate 2
Before build
Architecture and governance
Confirm where the truth lives, where the solution runs, who can reach it and what it will cost to own.
Confirmed at this gate
- System of record
- Data authority and flow
- Environments
- Identity
- Connectors
- Integration
- Security
- Licensing
- Support owner
- External access where applicable
Decision
Proceed · Simplify · Re-scope
Gate 3
Before release
Prove
Confirm the solution works for real people doing real work, under conditions that resemble production.
Confirmed at this gate
- Representative end-to-end scenarios
- Real user needs
- Data
- Security
- Integration
- Accessibility
- Expected volume and performance where relevant
- User acceptance
- Supportability
- Adoption readiness
Decision
Release candidate · Remediate · Stop
Gate 4
Release and operate
Release and operate
Confirm the solution has an owner, a support route and a review date before it becomes part of the estate.
Confirmed at this gate
- Production deployment
- Access
- Owners
- Support
- Monitoring
- Documentation
- Adoption
- Rollback and fallback
- Lifecycle
- Review date
Decision
Deploy · Defer · Rework
Shared responsibilities
A Power Platform solution is not owned only by the developer.
These roles do not all need different people, but they do all need a name against them.
Business owner
Owns the business outcome the solution exists to improve.
Process owner
Decides how the process should actually work.
Data owner
Owns the meaning and quality of the information involved.
Technical owner
Owns architecture and platform operation.
Security and governance
Owns the appropriate platform controls.
Support owner
Owns operational response after deployment.
Users
Validate usability and whether it fits how work is done.
Commercial owner
Understands the licensing and cost implications.
InteliSense can provide architecture, design and delivery. The organisation still owns the process it is asking technology to support.
Release condition
Deployment is not adoption.
A technically functioning app that nobody uses is not a successful implementation. These are the signals we look at before and after release.
- User involvement during design
- Fit with how the work actually flows
- Usability on the device people use
- Accessibility
- Training that matches the task
- Communication before and after release
- Measured usage
- A route for feedback
- Management reinforcement
- Whether the old spreadsheet is still open
Power Platform recovery
Recovery starts by establishing what actually exists.
Many organisations do not have a Power Platform problem. They have an inventory problem, an ownership problem and a licensing problem that nobody has yet written down.
Warning signs
- A large app and flow estate nobody can describe
- Ownerless apps
- Ownerless flows
- Default-environment sprawl
- Expired or broken connections
- Unclear premium licensing exposure
- Duplicated apps solving the same problem
- Unsupported custom connectors
- No environment strategy
- No application lifecycle
- No support model
- Business-critical apps nobody knew were critical
- Obsolete apps still running
What exists
An inventory rather than an impression.
Who owns it
Named people, not assumed teams.
What is used
Measured usage, not reported usage.
What is critical
The apps the operation would notice losing.
What is risky
Access, connections, data exposure and cost.
What moves under governance
Environment, lifecycle, support and ownership.
What is retired
Ending an application is a valid outcome.
Evidence
What we can currently prove, and what we cannot.
We hold no published Power Platform customer outcome study, so we do not present one. Reusing Dynamics evidence to imply Power Platform results would be dishonest.
Level 1: Demonstration
Shows the intended workflow or application. It proves the design, not the outcome.
Available on request
Level 2: Proof
Validated against a representative or customer scenario with real conditions.
Established per engagement
Level 3: Production use
Operating inside a real workflow, with owners, support and measured usage.
No published Power Platform example yet
Level 4: Verified outcome
Measured against an agreed baseline that was captured before the change.
No published Power Platform example yet
Proof before scale
How Power Platform value is proved.
Value is established against a baseline captured before the change, using measures that relate to the process itself.
Problem
One process, named and owned.
Current effort and risk
The baseline, captured before anything changes.
Focused solution
The smallest thing that could close the gap.
Users
The people who will actually use it.
Process test
Real scenarios, including the failure paths.
Adoption
Measured use, not measured deployment.
Outcome
Compared with the baseline that was agreed.
Scale decision
Extend, hold or stop.
What we measure
- Manual steps removed
- Waiting time
- Duplicate entry
- Rework
- Process completion
- User adoption
- Exception visibility
We do not publish percentage improvements we have not measured. Where a future Power Platform example is published, it will explain the problem, why standard capability was insufficient, why Power Platform was chosen, how it was governed, how it was adopted and what was verified.
Where it tends to help
Three patterns, applied across sectors.
The principle is the same everywhere: focused extension around the processes standard applications do not reach, with the boundary stated as clearly as the opportunity.
Operational workflow
Manufacturing · Distribution & logistics · Construction
- Quality and inspection
- Production or warehouse exception
- Issue and damage capture
- Mobile and site workflow
- Maintenance and variation request
- Operational approval
Do not rebuild MRP, production planning, warehouse execution or specialist construction systems inside Power Apps where an existing platform already provides them.
Service and case workflow
Public sector · Healthcare & care · Not for profit
- Referral and intake
- Case workflow
- Partner and provider process
- Funding or grant approval
- Service coordination
- Operational data capture
Sensitive information, service-user privacy and partner access boundaries come first. Power Platform supports administration and coordination. It is not a clinical decision engine.
Customer and professional workflow
Professional services · Retail & ecommerce
- Project governance and change request
- Risk and resource request
- Customer onboarding
- Store or product-data workflow
- Return and service exception
- Supplier or partner process
Often a strong opportunity to connect CRM, Business Central and Power Platform around one delivery process. It is focused extension, not an ecommerce or PSA platform replacement.
Solution lifecycle
Low code still has a lifecycle.
Applications and automation should move between environments deliberately, then be reviewed, replaced or retired rather than left running because nobody decided otherwise.
Idea
Someone has a problem worth solving.
Qualify
Is this a genuine gap, or a standard capability nobody has used?
Design
Process, data, users and boundaries.
Build
In a controlled environment.
Test
Prove the process, not only the screens.
Approve
A named person accepts the change.
Deploy
Deliberately, not manually and hopefully.
Adopt
Deployment is not adoption.
Support
Someone answers when it breaks.
Review
Is it still used and still correct?
Retire or replace
Applications should be allowed to end.
Check the fit
Six questions that make the first conversation useful.
Your answers stay on this page until you choose to continue, and they are carried into the enquiry so nothing has to be retyped.
Indicative signal
Answer the questions and we will show a likely starting point. This is a recommended next route rather than a technical recommendation, and sometimes the honest answer is that nothing should be built. Please keep every answer at organisational level: no customer, personal or case information.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
How this connects
Power Platform supports recovery, transformation and optimisation.
It is rarely the whole answer. It is often part of it. Low code can accelerate a good process. It can also accelerate confusion.
Recover
Recovery starts by establishing what actually exists, who owns it and what should be retired.
Transform
Transformation is the moment to decide what belongs in the platform and what belongs beside it.
Optimise
Optimisation can remove manual coordination without replacing the core application.
Support
Applications and automation need a support route, not only a builder.
Common questions
Questions leaders ask about Power Platform.
Your process gap
Is this a genuine gap, or a decision waiting to be made?
We are happy to say when Power Platform is the right answer, and equally happy to say when the requirement belongs in ERP, CRM or a specialist platform instead.