What it is
Power Platform is a family of Microsoft products aimed at building business apps with less traditional code. Power Apps makes forms and simple applications, either canvas apps (you place controls) or model-driven apps (the UI follows the data model). Power Automate runs flows: triggers and actions such as "when a file is created, post a message". Power BI models and visualises data. Dataverse is the platform's own relational store, with tables, relationships and security roles. Connectors link these pieces to SharePoint, Outlook, SQL and hundreds of other systems.
It lives next to Microsoft 365 and Azure. It is not SPFx, and it is not a general programming language.
Why and when it is used
Use Power Platform when the owners of a process can help build it, the audience is inside one tenant, and the logic is "form in, approval, row in a table, email out". A leave request, a facilities checklist, or a flow that copies SharePoint metadata into a team channel are good fits.
Prefer ordinary code (TypeScript, C#, a web framework) when you need custom UX, heavy domain logic, automated tests, or a product you ship to many customers. Prefer SPFx when the UI must be a web part on a SharePoint page. Prefer Azure Functions or another API when the work is a service other systems call. Low-code and code can meet: a flow calls your HTTP endpoint, or a canvas app embeds nothing and your app reads Dataverse through its API.
How it works
A maker signs in to the tenant. An environment (Default, or a dedicated Dev/Test/Prod) holds apps, flows and Dataverse tables. A canvas app's screens call connectors. A connector action runs as a connection: the user's credentials or a service account. Power Automate triggers on a schedule, a button, a Graph-backed event such as a new list item, or an HTTP request. Dataverse enforces security roles on rows. Solutions package apps and tables so you can move them between environments. Admins use the Power Platform admin center to control environments, connectors and data loss prevention policies that block, for example, a flow copying tenant files to a personal consumer service.
Technologies and dependencies
You depend on the tenant's licences (some connectors and Dataverse capacity are not in the cheapest seats), on Entra ID users, and on the connectors your data-loss-prevention policy allows. SharePoint lists are a common back end for simple apps; Dataverse is the better back end when you need relationships and row security. On-premises data needs a gateway. Custom logic can be a connector to an API you host on Azure. ALM for serious work uses solutions and source control, not only editing in production in the browser.
How to get started
- Open make.powerapps.com in a dev tenant, not production.
- Build a canvas app with one SharePoint list: a form that creates an item and a gallery that lists items.
- Add a flow that sends a message when the item is created. Use a test account.
- Look at the environment and the connections page so you see whose identity the flow uses.
- Read what your licence includes before you design around premium connectors or Dataverse.
- If the app grows past a few screens and you cannot explain the logic, stop and sketch it as a normal service. That is a successful outcome, not a failure of the prototype.
Cautions and trade-offs
Low-code spreads faster than review. Flows with broad connections can exfiltrate data if a connector policy is loose. Apps edited directly in production have no pull request. Premium-connector cost surprises teams who prototyped on a trial. SharePoint-backed apps hit list limits. Dataverse is powerful and is also another database to govern.
Do not hide secrets in flow definitions. Do not use a personal account as the connection for a company process; that flow dies when the person leaves. Treat Power Platform as production software once people rely on it: environments, owners, and a way to export the solution. And do not tell developers that Power Apps replaces React or SPFx. It solves a different class of problem.