What vendor-qualification questions belong in an RFP for a Power Platform Center of Excellence buildout?
You are writing the qualification section of an RFP that every bidder will answer in the same confident low-code language, and you need questions the weak ones cannot answer. Ask questions that force a bidder to describe the mechanics of a governed tenant rather than its enthusiasm for low code, and score the answers against artifacts you can inspect. Six areas separate a real operator from a well-written proposal: how the bidder structures environments and promotes solutions between them, how it writes and tests Data Loss Prevention policies at tenant and environment level, how it runs application lifecycle management and source control, how it models licensing before it designs the app, how it handles the citizen developer population and the apps that already exist, and what it hands over so the Center of Excellence survives without the bidder. Under each area below there are specific questions to paste into the RFP, together with the answer shape that indicates the bidder has done this work and the answer shape that indicates it has not. The single most useful instruction you can add to the RFP is that every claim be answered with a named artifact, a named Microsoft capability, or a named client role, because a bidder that has run a Center of Excellence can produce all three and a bidder that has not will answer in adjectives.
Why generic RFP language fails on this particular buy
A Center of Excellence is not a deliverable. It is an operating function that keeps working after the engagement closes, which makes it unusually easy to buy badly. Most Power Platform RFP language asks whether the bidder can build apps. Every bidder can build apps. The question that actually predicts the outcome is whether the bidder can hold a tenant to a policy for two years while several hundred people build things in it.
That distinction shows up in the failure mode. A program bought on build capability produces a working pilot and an ungoverned tenant behind it: environments created ad hoc, connectors nobody approved, flows owned by people who have left, and no way to answer an auditor asking who can change what. The remediation costs more than the original build, and it lands on the client rather than the bidder, because nothing in the contract said otherwise.
So the questions below are written to be unpleasant to answer vaguely. Each one has a concrete right answer that a firm running governed tenants gives without preparation.
Area 1: Environment strategy and solution promotion
This is the first area to ask about because it is the one that constrains everything else. Microsoft documents the environment as the container for apps, flows, and data, and describes environment types and their intended use in the Power Platform environments overview. Ask:
- Describe the environment topology you would recommend for our tenant, naming each environment, its type, its purpose, and who is allowed to create apps in it.
- How does a solution move from development to production in your model, and what is the mechanism? Name it.
- Who is permitted to create a new environment after go-live, and what stops anyone else from doing it?
- What happens to an app that a business user builds in the default environment? Describe the actual process, not the policy statement.
A strong answer names managed solutions and a promotion path with a gate at each hop. A weak answer describes exporting and importing solutions by hand, or does not distinguish between the default environment and a governed one.
On our own practice, stated as the fact it is: i3solutions runs client Power Platform work on a multi-tenant Center of Excellence model with separate Dev, Test, UAT, and Production environments promoted through managed solutions. That is the shape of answer the question is designed to surface, from whoever you buy from.
Area 2: Data Loss Prevention policy design and testing
Connector policy is where a Power Platform tenant either has a boundary or does not. Microsoft describes tenant and environment scoped policies and connector classification in its Data Loss Prevention guidance, and the Managed Environments capability adds a further set of controls at the environment level. Ask:
- Walk us through how you would classify connectors for our tenant, and tell us which connectors you would block outright and why.
- Do you write policy at tenant scope, environment scope, or both, and what determines which?
- How do you test a policy before it goes live, and how do you find out which existing apps and flows it will break?
- What is your process when a business unit needs an exception, and who signs it?
- How do custom connectors get reviewed, and what is the approval record?
The exception process question is the one that separates operators from theorists. Every real tenant generates exception requests within weeks. A bidder that has not thought about who signs them has not run one.
i3solutions governs client Power Platform tenants with the Center of Excellence Starter Kit, tenant-level and environment-level DLP policies, and managed environment controls. The Center of Excellence Starter Kit is Microsoft’s own toolset for this, and a bidder proposing a Center of Excellence should be able to say plainly whether it uses the Starter Kit, extends it, or has replaced it, and why.
Area 3: Application lifecycle management and source control
Ask these questions even if you think low code makes them unnecessary. They are the questions that decide whether year two is maintainable. Microsoft’s application lifecycle management guidance for Power Platform is the reference to score answers against.
- What is your source control model for solutions, and where does the source of truth live?
- What is your deployment mechanism, and is it the same for a two-screen canvas app as for a model-driven app on Dataverse?
- How is a change tested before it reaches production users, and who signs off?
- How do you roll a change back, and have you had to?
- What is documented at handover, and in what format, so our team can run a deployment without you?
A weak answer treats low code as an exemption from change control. A strong answer names a pipeline capability, a repository, and a specific gate. For calibration: i3solutions delivery includes ALM practices with Power Platform pipelines or Azure DevOps integration, environment separation strategies, and change control processes.
Area 4: Licensing modeled before the design is fixed
Licensing is not a procurement footnote on this platform. It is an architecture input, because premium connectors, Dataverse, and per-app versus per-user plans change what the cheapest correct design is. A bidder that designs first and prices licences afterwards will hand you an architecture you cannot afford to run. Ask:
- At what point in your process do you model licensing, and what artifact captures it?
- For each app in scope, tell us which plan you assume and what would change that assumption.
- Which of the capabilities in your proposed design require premium connectors or Dataverse, and what is the alternative design if we decline them?
- What is your estimate of steady-state licence cost at year two, and what drives it up?
The last question is the useful one. A bidder that only prices year one is pricing the build, not the Center of Excellence. On our own approach: i3solutions implements Power Platform licensing across Power Apps per-app and per-user plans, Power Automate per-flow and per-user plans, and the Microsoft 365 default entitlements where app complexity is low.
Area 5: Citizen developers and the apps you already have
Most organizations buying a Center of Excellence already have an estate they did not plan. Ask the bidder to address it directly rather than starting from a clean tenant it will never see:
- How do you inventory what already exists, and what does the inventory contain?
- What is your disposition process for an app that is in use, has no owner, and violates the policy you are about to write?
- What is your enablement model for business builders, and what specifically are they permitted to do without review?
- How do you handle an orphaned flow whose owner has left the organization?
- What does the support model look like once the platform is live, and who answers a user at 4pm on a Friday?
Score the disposition answer hardest. Retire, rebuild, sanction, and adopt are all legitimate outcomes for an existing app, and a bidder with a real process names them and says who decides. A bidder without one says it will assess the estate. Our related reading on how these estates go wrong is in Power Platform governance gaps and audit exposure.
Area 6: What you own at the end
A Center of Excellence bought as a service you can never stop buying is not a Center of Excellence. Ask:
- List, by name, every artifact we own at the end of the engagement.
- Which of your team’s responsibilities transfer to our staff, and on what schedule?
- What proportion of the work is done by named individuals we will meet, and where are they located?
- If we terminate the relationship at month twelve, what specifically stops working?
The last one is worth asking in exactly those words. It is uncomfortable, and the discomfort is the point. If the honest answer is that the tenant becomes unmanageable, you are buying a dependency rather than a capability, and you should know that before you sign rather than at renewal.
How to score the responses
Do not score on completeness. Every bidder will answer every question. Score on three things instead.
Artifact or adjective. For each answer, mark whether the bidder named something inspectable, a policy, a pipeline, a document, a Microsoft capability, a role, or whether it described a quality. Count them. A response that is more than half adjectives will not survive contact with your tenant.
Consistency across areas. The environment answer, the DLP answer, and the ALM answer are the same design viewed from three angles. If the bidder proposes managed solutions in one area and manual export in another, or environment-scoped policy in one and tenant-only in another, the response was assembled rather than designed, by different people who did not read each other’s sections.
What the bidder refuses. A firm that has run governed tenants will decline at least one thing you asked for, or will qualify it. Universal agreement in a governance RFP is a warning sign rather than a strength, because governance is a set of trade-offs and a bidder claiming there are none has not made any.
Where i3solutions sits in this
Stated plainly and no wider than it goes. i3solutions is a Microsoft Solutions Partner. i3solutions has completed more than 600 Microsoft platform implementations. On Power Platform specifically at scale: i3solutions runs a governed Power Platform for a federal defense agency supporting roughly 10,000 personnel across about 180 locations, which works because it is governed, not despite it.
We publish these questions because a better-specified RFP produces a better program whoever wins it, and because the questions we would want to be asked are the ones we can answer with artifacts. If you want the operating model behind the answers, read centralized, federated, and hybrid Power Platform CoE operating models and our Power Platform governance practice. If external teams will be working inside your tenant, Microsoft vendor risk management for embedded teams covers the access and evidence side of the same contract.
Talk to a senior Power Platform architect
Frequently asked questions
What vendor-qualification questions belong in a Power Platform Center of Excellence RFP?
Questions that force the bidder to describe mechanics rather than intent, across six areas: environment topology and how solutions are promoted between environments, Data Loss Prevention policy design at tenant and environment scope including the exception process, application lifecycle management and source control, licensing modeled before the design is fixed, the disposition process for citizen-developer apps that already exist, and exactly what artifacts and responsibilities transfer to your team at the end. Add one instruction covering all of them: every claim must be answered with a named artifact, a named Microsoft capability, or a named role. A firm that has run a governed tenant produces all three without preparation.
How do we tell a real Center of Excellence operator from a good proposal writer?
Three tests. Count named artifacts against adjectives in the response and discard any answer that is mostly qualities. Check that the environment, Data Loss Prevention, and lifecycle answers describe one consistent design rather than three, because an assembled response usually contradicts itself across sections. And look for what the bidder declines or qualifies, since governance is a set of trade-offs and a firm agreeing to everything has not made any. The exception-handling question is the single most diagnostic one, because every live tenant generates exception requests within weeks and a bidder who has not decided who signs them has not operated one.
Should the RFP ask about Data Loss Prevention policy specifically, or is that too detailed for procurement?
Ask it specifically. Connector policy is the boundary of the tenant, and Microsoft scopes these policies at both tenant and environment level, so a bidder that treats it as an implementation detail is telling you the boundary will be designed by whoever happens to be on site. The questions worth asking in procurement are which connectors would be blocked outright and why, whether policy is written at tenant scope or environment scope and what decides, how a policy is tested against the existing estate before it goes live, and who signs an exception. None of those require the evaluation panel to be technical to score.
What should the RFP say about apps our business users have already built?
Require a disposition process, not an assessment. Ask how the bidder inventories what exists, what the inventory contains, and what it does with an app that is in active use, has no identified owner, and breaks the policy about to be written. Retire, rebuild, sanction, and adopt are all defensible outcomes, and a bidder with real experience names them and says who decides each case. Ask the same question about an orphaned flow whose owner has left, because that is the one that fails silently and is found during an audit rather than before it.
When should licensing come up in the evaluation?
Before the design is fixed, and the RFP should say so. On Power Platform, premium connectors, Dataverse, and the choice between per-app and per-user plans change which design is cheapest to run, so a bidder that architects first and prices licences afterwards can hand you a solution you cannot afford at steady state. Ask which plan is assumed for each app in scope, what would change that assumption, which proposed capabilities require premium licensing and what the alternative design is without them, and what the estimated year-two licence cost is and what drives it up. A bidder pricing only year one is pricing a build.
What should we own when the engagement ends?
Every artifact, named individually in the response rather than described as documentation. That means the environment and policy configuration and the reasoning behind it, the solution source and the deployment mechanism, the runbooks for routine administration, the exception register, and the inventory. Ask which of the vendor’s responsibilities transfer to your staff and on what schedule, and ask directly what stops working if you end the relationship at month twelve. If the honest answer is that the tenant becomes unmanageable, you are buying a dependency rather than a capability, and it is far better to learn that during evaluation than at renewal.
