Routine processes often live in email, spreadsheets and memory. Matt designs apps and automation on Power Platform, with Azure Logic Apps for integration, and plans the environments, identities and owners that keep them running.
Choose what to automate
A team receives different pieces of work that may look similar at first. Look at their requirements and exceptions before choosing a route.
The useful distinction is what each task needs to reach an acceptable result. Volume alone does not tell you what to automate.
Keep review with people when a decision depends on interpretation or judgement that the process cannot check reliably. They need the context behind the work, not just a finished-looking output.
Make the review responsibility explicit. People need to know what they are deciding and what evidence supports it.
The assisted route uses maintained context to help prepare documents. It changes how the work is produced while leaving the team responsible for its usefulness.
Choose assistance where a person can inspect the result and give actionable feedback. Keep that feedback available for the next attempt.
The automated route follows a defined sequence through validation to a record. Each stage has a clear job in handling the work.
Decide when a failure should stop the sequence and reach a person. Reliable repetition includes a way to handle the exception.
People, assistance and automation can serve different tasks within the same team. Choose the method by the requirements and consequences of the work.
Begin with one repeatable task and judge the result. Broader change can follow what the team learns from doing it.
A team receives different pieces of work that may look similar at first. Look at their requirements and exceptions before choosing a route.
The useful distinction is what each task needs to reach an acceptable result. Volume alone does not tell you what to automate.
Keep review with people when a decision depends on interpretation or judgement that the process cannot check reliably. They need the context behind the work, not just a finished-looking output.
Make the review responsibility explicit. People need to know what they are deciding and what evidence supports it.
The assisted route uses maintained context to help prepare documents. It changes how the work is produced while leaving the team responsible for its usefulness.
Choose assistance where a person can inspect the result and give actionable feedback. Keep that feedback available for the next attempt.
The automated route follows a defined sequence through validation to a record. Each stage has a clear job in handling the work.
Decide when a failure should stop the sequence and reach a person. Reliable repetition includes a way to handle the exception.
People, assistance and automation can serve different tasks within the same team. Choose the method by the requirements and consequences of the work.
Begin with one repeatable task and judge the result. Broader change can follow what the team learns from doing it.
Not every process should be automated. Keep judgement with people, use AI to prepare work that still needs review, and automate the routes that repeat. Start with one repeatable process, and decide when a failure should stop it.
People join a Microsoft 365 group. That membership supports the permissions for the team and its connected SharePoint site.
The assignment gives the business a place to review who belongs in that collaboration space as responsibilities change.
An app registration defines the application. Its service principal represents it in the tenant and receives an Azure role at a selected scope.
The application needs a deliberate grant for the work it performs. A person’s team membership does not establish that grant.
Review collaboration permissions for Teams and SharePoint separately from Azure resource roles. Each grant needs a purpose and a scope that an owner can explain.
Reviewing the destination alongside the assignment makes the access decision concrete: which work is allowed, and where?
Recognizing an identity is only the start of an access decision. Group membership, service permissions and Azure role scope determine what that identity can do.
Plan the people and application routes together so a review can account for both ways into the organization’s work.
People join a Microsoft 365 group. That membership supports the permissions for the team and its connected SharePoint site.
The assignment gives the business a place to review who belongs in that collaboration space as responsibilities change.
An app registration defines the application. Its service principal represents it in the tenant and receives an Azure role at a selected scope.
The application needs a deliberate grant for the work it performs. A person’s team membership does not establish that grant.
Review collaboration permissions for Teams and SharePoint separately from Azure resource roles. Each grant needs a purpose and a scope that an owner can explain.
Reviewing the destination alongside the assignment makes the access decision concrete: which work is allowed, and where?
Recognizing an identity is only the start of an access decision. Group membership, service permissions and Azure role scope determine what that identity can do.
Plan the people and application routes together so a review can account for both ways into the organization’s work.
Every flow and connector acts as someone: a signed-in person, or an application identity with permissions of its own. Decide which identity each connection uses and what it can reach, and review it like any other access.
Canvas and model-driven Power Apps give a process a proper interface: forms, approvals and tracking, on data structured in Dataverse. Design the tables and views first. Power BI reports can then show the process as it runs.
Azure Logic Apps suit integrations that run in Azure: connecting business systems, APIs and data services on a schedule or an event. Choose between Power Automate and Logic Apps by who maintains the flow, where it runs and what it connects to.
Release through separate development, test and production environments, to a limited group before everyone, and name an owner for every app and flow. For a utility's field training, Matt delivered 14 Power Apps, 70+ flows and 30+ Power BI reports to 6,000 users, with 95% completion among 2,000 field staff.
Map the content people will use and the access they already have. Establish ownership before introducing the workflow to a wider group.
The assessment gives the first rollout a defined scope. It also identifies the questions that testing needs to answer.
Begin with a limited cohort using scoped content. This gives the team a manageable setting for learning how the workflow behaves.
Keep the purpose and boundaries clear to the participants. Their experience should contribute evidence for the next decision.
Review the evidence from the limited rollout and resolve the findings that matter. The decision concerns readiness for the next scope of use.
A date on the calendar is not that evidence. Keep expansion tied to what the review has established.
A wider rollout follows the review decision. Choose the next group and content scope with the lessons from the first cohort in view.
Continue collecting useful findings as the audience grows. A successful first stage does not settle every condition of wider use.
Access reviews, content owners, policy checks and audit continue across the rollout. They are ongoing responsibilities rather than a one-time launch gate.
Use the sequence to make each expansion decision explicit. The scope grows as the evidence and ownership support it.
Map the content people will use and the access they already have. Establish ownership before introducing the workflow to a wider group.
The assessment gives the first rollout a defined scope. It also identifies the questions that testing needs to answer.
Begin with a limited cohort using scoped content. This gives the team a manageable setting for learning how the workflow behaves.
Keep the purpose and boundaries clear to the participants. Their experience should contribute evidence for the next decision.
Review the evidence from the limited rollout and resolve the findings that matter. The decision concerns readiness for the next scope of use.
A date on the calendar is not that evidence. Keep expansion tied to what the review has established.
A wider rollout follows the review decision. Choose the next group and content scope with the lessons from the first cohort in view.
Continue collecting useful findings as the audience grows. A successful first stage does not settle every condition of wider use.
Access reviews, content owners, policy checks and audit continue across the rollout. They are ongoing responsibilities rather than a one-time launch gate.
Use the sequence to make each expansion decision explicit. The scope grows as the evidence and ownership support it.
Bring the process that takes the most manual effort. We decide what to automate, build it, and set up the platform to keep it running.
Map one repeatable process, choose the route for each step, and build it on Power Platform with an owner and a failure path.
Plan environments, connections and identities, and a release path from development to production, before more makers join.
Automation that keeps running after launch.
Matt designs the process with the people who run it, builds the apps and flows, and plans environments and ownership so the work survives the first release.
Start with the one your team repeats most.