A Power Platform support model allocates accountability before it addresses tools. Five asset classes (platform, environments, apps, flows, data), two owners per app or flow (business and technical), and four support tiers each stopped by a different constraint. When IT says it will not support apps and flows the business built without it, that is not a policy problem; it is an accurate description of limits the support model closes deliberately.
Key Takeaways
A Power Platform support model allocates accountability before it addresses tools. The five asset classes are platform, environments, apps, flows, and data: each needs a named accountable person, a responsible party, and a verifiable documentation location.
Every app and every flow needs two owners: a business owner (answers whether the process still fits policy) and a technical owner (holds co-owner permissions and manages the artifact). One-owner assets are one-departure incidents.
Four support tiers, each stopped by a different constraint: maker (limited authority), service desk (stopped by access), platform team (stopped by business decisions), vendor (platform defects only, reached through the org’s support plan).
Service levels are set by business impact, data sensitivity, and user dependency, not by who built the asset. Levels describe who responds and by when, not resolution guarantees, and the lowest tier requires documented business-owner acceptance.
When makers leave, two things go wrong at once: the ownership record does not update itself, and authenticated connections may fail. Add the ownership register to the departure checklist, and use usage analytics to find concentration risks before they become outages.
Why Support Comes Before Tools
When IT says it will not support apps and flows the business built without it, that is not a policy problem. It is an accurate description of limits: no visibility into what exists, no authority to change process rules, no way to reach connections owned by other people, and no service model behind the answer. The support model is what closes those gaps deliberately, before the platform team is asked to hold up work it never saw built.
Five Asset Classes, Five RACI Rows
Asset
Accountable
Responsible
Where the record lives
Platform (tenant, licensing)
Platform owner
Platform team
Power Platform admin center; licensing portal
Environments
Environment owner per environment
Environment administrators
Environment list in the Power Platform admin center
Apps
Business owner
Technical owner (co-owner in Power Apps)
Sharing record in Power Apps; support register
Flows
Business owner
Technical owner (co-owner on the flow)
Owners section on flow details
Data (connections, Dataverse tables)
Data owner
Platform team plus technical owner
Connection details page; Dataverse security roles
Two Owners Per Asset, and Why
A business owner answers whether the encoded process still fits the policy the business runs on. A technical owner holds co-owner permissions, manages the artifact, and answers for the mechanics. They can be the same person only for the smallest applications; for anything the business depends on, they are two people, and the reason is continuity: one owner is a single point of failure and the estate has too many of those already.
Four Support Tiers, Each Stopped by a Different Thing
Maker (first responder, limited authority). Fast, cheap, answers most application questions. Stopped when the question requires access the maker does not have or a decision the maker cannot make.
Every tier above the maker is stopped by a different thing.
Service desk (intake and routing). Owns tickets, routes them to whoever can act. Stopped by access limits: the service desk cannot open connections it does not own or change apps in environments it cannot reach.
Platform team (cross-asset visibility, tenant authority). Sees the estate, holds environment and DLP authority, can reach any connection or app. Stopped by business decisions: the platform team does not decide whether an application’s process is still correct.
Vendor (Microsoft). Platform defects only, reached through the organization’s support plan. Not a first response and not a substitute for a support model.
Service Level Design
Service levels are set by business impact, data sensitivity, and user dependency, not by who built the asset. A maker-built app that carries payroll needs the same response as a platform-built app that does. Levels describe who responds and by when, not what gets resolved. The lowest tier (best-effort, business hours) is a valid choice; it just requires the business owner to accept it in writing.
The app is quick. The architecture is not.
Screens come together in weeks; data models, environment strategy, and release control decide whether the application survives year three. i3solutions provides senior Power Apps and Power Platform specialists with regulated-industry delivery experience.
When a maker leaves, two things go wrong at once and each has its own remediation. Ownership records do not update themselves: a departure without a handover leaves apps and flows technically owned by an inactive account. Authenticated connections may fail: the specific actions using the departed person’s credentials return errors, even where the flow itself has a co-owner and keeps running.
The fix is not to catch this at departure. The fixes are to add the ownership register to the standard departure checklist, and to use usage analytics to identify concentration risks: the applications and flows where one person holds a disproportionate share of the ownership, while people are still there to hand over.
Common Misconceptions
“IT refuses to support unauthorized apps.” IT cannot support what it cannot see, cannot reach, and did not decide about. That is not a policy stance; it is a description of the mechanics. The support model is what changes the mechanics.
“A support model is a governance document.” A support model is a set of RACI rows the business can read against reality. If the record does not name a person, the row is not staffed.
“The maker is the support model.” The maker is the first responder. Every tier above the maker is stopped by a different thing, and the model exists so the escalation path is knowable before something stops.
How i3solutions Runs This Work
i3solutions has delivered on the Microsoft stack since 1997, with senior, 100 percent US-based teams. The support model runs the same discipline every governance-first program does: name the accountable and responsible per asset class, staff the four tiers with people who can actually act at their level, and treat maker departures as scheduled handovers rather than outage triggers.
Michael Branson
Founder/COO
Michael Branson co-founded i3solutions 30 years ago and brings executive, operational, and technical perspective to organizations working in complex, secure, and mission-critical environments. His insights focus on business process consulting, automation, data analytics, collaboration, secure operating models, and the operational discipline required to turn technology investments into practical business systems with measurable value.
A written allocation of accountability before it addresses tools. Five asset classes (platform, environments, apps, flows, and data) each with a named accountable person, a responsible party, and a verifiable documentation location. Every app and every flow has two owners: a business owner who answers whether the process still fits, and a technical owner who holds co-owner permissions and manages the artifact. Four support tiers escalate from maker to service desk to platform team to Microsoft, each stopped by a different constraint.
Two people. A business owner accountable for whether the encoded process still fits the policy the business runs on. A technical owner who holds co-owner permissions and manages the artifact. They can be the same person only for the smallest applications; anything business-critical has two owners, because one owner is a single point of failure the estate already has too many of.
By business impact, data sensitivity, and user dependency, not by who built the asset. A maker-built app that carries payroll gets the same response as a platform-built app that does. Levels describe who responds and by when, not what gets resolved. The lowest tier (best-effort, business hours) is a valid choice, and it requires the business owner to accept it in writing.
Maker (first responder, limited authority; stops when the question exceeds the maker's access or authority). Service desk (intake and routing; stops at access limits). Platform team (cross-asset visibility and tenant authority; stops at business decisions). Vendor (Microsoft, platform defects only, reached through the organization's support plan).
Two things go wrong at once. The ownership record does not update itself, so apps and flows end up technically owned by an inactive account. Authenticated connections may fail: specific actions using the departed person's credentials return errors, even where the flow itself has a co-owner and keeps running. The fix is to add the ownership register to the standard departure checklist and use usage analytics to identify concentration risks while people are still there to hand over.
Governance Debt on the Power Platform Compounds Quietly
Ungoverned environments, unmanaged connectors, and apps on personal credentials surface at audits, not in demos. i3solutions' senior Power Platform advisors work with enterprise IT leaders who have found the exposure and want the remediation scoped.
