Microsoft Power Platform
Power Apps, Power Automate, Dataverse and the rest of Power Platform run inside the Microsoft environment your business already uses, with the same identities, security and administration.
Power Platform works best when the users are known, the process has clear stages and the data can be modelled properly. Outside those conditions, a different platform is often cheaper to build and easier to support.
What each part of Power Platform does
Power Platform is a group of connected products. It helps to read it as layers.
Power Apps
Power Apps is the screen people work in. Canvas apps give more control over layout, while model-driven apps build structured, data-led applications on Dataverse.
Power Pages
Power Pages is for external web experiences such as partner portals, customer forms and self-service sites. It is separate from Power Apps, with its own licensing and architecture.
Power Automate
Power Automate runs workflows between people, applications and data. Cloud flows respond to events or schedules, desktop flows work through existing software interfaces, and business process flows guide users through defined stages.
Copilot Studio
Copilot Studio builds agents and agent flows on the same platform. An agent can answer from approved information and call a flow to look up a record or complete an action.
Dataverse
Dataverse is the data and security layer. It supports related tables, role-based security, business rules, validation, auditing and managed access to business information.
Power BI
Power BI reports across Dataverse, SQL and other sources. It can be embedded in an application or used on its own for operational and management reporting.
A strong fit for internal work, the wrong tool for some jobs
Strong fit Where Power Platform is a strong fit
Power Platform is usually well suited to internal work with known users, defined stages and structured information. Common examples include:
- Requests and approvals
- Inspections, audits and field data capture
- Onboarding and offboarding
- Equipment and access requests
- Compliance checklists and evidence collection
- Internal job and work tracking
- Document routing and notifications
- Data collection across several teams
- Applications connected to Microsoft 365 or Dynamics 365
The strongest projects normally have a clear process owner, repeated use, manageable exceptions and an outcome the business can measure.
Different platform Some applications need a different platform
Power Platform can be extended substantially, but forcing every requirement into low-code creates avoidable cost and complexity.
Public and high-volume applications
Public-facing applications with large user volumes, complex customer experiences or demanding performance requirements may be better suited to custom web development. Power Pages can support many external portal scenarios, but it should be assessed separately from an internal Power App.
Heavy transactional processing
Applications processing high transaction volumes, payments, large inventories or substantial real-time workloads may need a platform designed specifically for that purpose.
Highly specialised application logic
Complex calculations, specialised interfaces, heavy server-side processing or substantial real-time integration can be difficult to maintain within a low-code design.
An established product already exists
If a supported software product already fits the process and commercial requirements, implementing and integrating it may make more sense than building another application.
The process has not been agreed
An application cannot resolve unclear ownership, constantly changing rules or unresolved exceptions. Those decisions need to be made before the workflow is built.
AI is now part of the Power Platform stack
Power Platform can use AI in both the way applications are built and the work they perform.
Building applications with natural language
Copilot in Power Apps can create an initial application and Dataverse tables from a written description. Generative pages can create working pages for model-driven applications from plain-language instructions and selected Dataverse tables.
Generated applications still need review of the data model, permissions, business logic, user experience and maintainability before they are put into production.
Document and information processing
AI Builder can extract information from documents, classify text, recognise content and use prompts within Power Apps or Power Automate. This can support invoice handling, form processing, document routing and other information-heavy workflows.
Agent flows
Agent flows are low-code automations built in Copilot Studio or Power Automate. An agent can call a flow to retrieve information or perform an action through defined triggers and steps.
AI does not replace the workflow
If the work follows known rules, standard automation may be enough. AI becomes relevant when the workflow also needs to interpret documents, classify information, retrieve context, draft content or recommend a next action.
Explore AI agent deploymentPower Platform licensing needs to be modelled before the build
The cost depends on more than the number of people using the application. The design can involve user or app licensing, premium connectors, Dataverse capacity, Power Automate entitlements, Power BI licensing and usage-based AI consumption.
Microsoft is moving AI Builder licensing to Copilot Credits. The cut-off date for existing AI Builder capacity customers to renew or add capacity is 1 November 2026. Credits from active add-ons remain usable until the relevant contract expires. Eligible Power Platform and Dynamics 365 licences bought or renewed from 1 November 2026 no longer include seeded AI Builder credits; licences bought or renewed before then keep them until the end of their contract term.
Training custom models and testing models or prompts in their respective builders does not consume credits. Once prompts or models run in applications, flows, agents or agent flows, they consume the applicable credits. Prompts and models in agent flows also consume Copilot Credits when run from the test panel or flow designer.
Expected document volumes, prompt usage and agent activity therefore belong in the commercial model.
The licensing model should account for:
- 01 The number and type of users
- 02 How many applications each person needs
- 03 Premium connectors and external systems
- 04 Dataverse database, file and log capacity
- 05 Automated and unattended flows
- 06 API and transaction volumes
- 07 Power BI access and capacity
- 08 AI Builder or Copilot Credit consumption
Low-code applications still need engineering control
Power Platform makes it quick to start building. Without ownership and release controls, it can also produce applications the business can't maintain. On the Power Platform work we deliver, these controls go in before the first application does.
Separate environments
We separate development, test and production, so changes are reviewed before they reach live users.
Managed releases
Apps and flows are packaged in solutions, versioned and moved through a controlled release process. Pipelines and source control keep a record of what changed and a way back when a release causes a problem.
Data design
We define tables, relationships, validation, permissions and retention up front. SharePoint lists can suit lighter workloads, while Dataverse or another database is usually the better home for applications the business depends on.
Connector and data policies
Data loss prevention policies set which connectors can be used together, so business information doesn’t drift into unapproved services.
Ownership and support
Each app and flow gets a business owner, a technical owner, documentation and a support path. Apps built under personal accounts become a problem the day that person changes roles or leaves.
Inventory and lifecycle
We keep a current view of environments, apps, flows, connectors and owners, and retire what is unused or unsupported.
What makes a good first Power Platform application
The best first build is the process your team already grumbles about every week.
A good first project is narrow enough to implement properly and important enough for users to notice the improvement.
The first build should also establish reusable practices for environments, security, data, releases and support. Those practices matter more to future delivery than producing a large first application.
- A clear owner
- Frequent use
- Defined stages and decisions
- Structured information
- Manageable exceptions
- A known group of internal users
- A measurable outcome
- A process with no agreed rules
- An application meant to replace several core systems at once
- A requirement driven mainly by wanting to use the platform
Power Platform or custom development
Both approaches have a place. The decision belongs before the application is designed in detail.
Power Platform is usually stronger when
- Users are internal and already work in Microsoft 365
- The workflow has defined stages and moderate complexity
- Dataverse or supported connectors suit the information involved
- A low-code application can meet the user experience requirements
- Faster iteration is more important than complete control of the software stack
Custom development is usually stronger when
- The application is public-facing or has complex external-user requirements
- Performance, transaction volume or specialised interfaces are central to the design
- Business logic is difficult to express and maintain in low-code tools
- The application needs a highly specific architecture or deployment model
- Long-term software ownership requires control beyond the Power Platform boundary
Some projects use both. A custom service or API can handle specialised logic while Power Apps provides an internal interface and Power Automate manages the workflow around it.
Power Platform questions
Is Power Platform included with Microsoft 365?
Partly. Many Microsoft 365 licences include limited Power Apps and Power Automate use rights for standard Microsoft 365 services. Dataverse-backed applications, premium connectors, unattended automation and other advanced capabilities usually require separate licensing.
What is the difference between Power Apps and Power Automate?
Power Apps provides the application interface people use. Power Automate moves information and actions between people and systems. Many solutions use both.
Does every Power App need Dataverse?
No. A lighter application may use SharePoint or another supported data source. Dataverse becomes more relevant when the application needs related data, role-based security, auditing, business rules and managed deployment.
Can external users access a Power App?
Sometimes, but it needs careful licensing and identity design. Power Pages is generally the Microsoft product intended for external portals and forms. Public or high-volume applications may still be better suited to custom development.
Can Power Platform use AI?
Yes. AI Builder handles document processing, classification, extraction and prompts inside apps and flows, and agent flows let Copilot Studio agents carry out actions through defined steps. Production use consumes AI Builder credits or Copilot Credits, depending on the product and licensing arrangement.
Can Power Platform become shadow IT?
Yes. Unmanaged environments, personal ownership, uncontrolled connectors and applications built directly in production can create an unsupported software estate. Environment controls, data policies, release management, ownership and inventory prevent that.
Who supports Power Platform applications?
The organisation needs an agreed support owner. Inlight IT can document, monitor and support applications and flows and manage controlled changes. Support is raised and tracked in Microsoft Teams.
Move from a workflow to a supported application
Inlight IT builds Power Platform and custom applications, connects them to the required systems and supports them once they are running.