low-code & automation

Makers keep building Power Platform apps. IT still decides where they run and what they can reach.

Citizen development turns into shadow IT when nobody sets the rules. We build Power Apps and Power Automate solutions and set up Copilot Studio agents. We also put environment, DLP and ALM rules in place.

Talk to a Microsoft Power Platform engineer What changed recently

platform dossierMicrosoft Power PlatformLow-code & automation

Vendor: Microsoft
Components: Power Apps, Power Automate, Copilot Studio, Dataverse
Current update: October 2026 release, North America 23 to 26 Oct 2026
Roadmap model: Continuous AI at Work roadmap from Sep 2026

release watch

October 2026 update reaches North America 23 to 26 October23 Oct 2026
Unmanaged developer environments deprecated, including Developer Plan ones15 Nov 2026

connects with

in short·15-second read

Cohash builds and governs Microsoft Power Platform.

We build Power Apps, Power Automate flows and Copilot Studio agents on Dataverse, and set the environment, DLP and pipeline rules around them. Microsoft still pushes a mandatory update twice a year, the October one reaching North America on 23 to 26 October 2026, so we test it in early access first.

you probably need this if

Hundreds of flows run in the default environment, and half the people who built them don't work here anymore.
Solutions travel between environments as zip files on one person's laptop. When that person is on holiday, nothing ships.
Someone wants a Copilot Studio agent, and security wants to know exactly which connectors it can reach before saying yes.

terms on this page RulesDataverseenvironmentCopilot Studio

Ask an engineer facts checked 2026-10-23

how it runs: 01Tenant inventory
02Environment and DLP model
03Build as solutions
04Pipelines to production
05Handover to the CoE
you keep: Environment strategy that says which environments exist, which are managed and who owns each one
DLP policies with every connector classified and a written reason for each block, so makers know why
Inventory of apps, flows and connectors. The orphaned ones get flagged for a new owner or deletion
+ 2 more documents
who does it: Power Apps developer (canvas and model-driven)Power Automate developerCopilot Studio developer Microsoft Certified: Power Platform Developer Associate Microsoft Certified: Power BI Data Analyst Associate
platforms
proof: 7 case studies on this
background: field note · 15 minDataverse for Teams is going away: what to keep, move or let go before September 2027

power-platform · release timeline

25 Aug 2026 Release waves replaced by the AI at Work roadmap Microsoft stopped writing release plans in September and posts new features to one rolling roadmap instead. Release Planner is gone by 15 November 2026. If your admins filtered it for their apps, they'll need a new habit.
31 Aug 2026 Power Automate mobile app deprecated Microsoft deprecated the iOS and Android app on 31 August 2026 and pulled it from both app stores. Cloud flows still run as before. The people who started flows from their phone are the ones who'll notice, so tell them what to use instead.
17 Sep 2026 September 2026 feature update Model-driven apps got the app-builder skill in September, along with a new header and navigation. The new navigation is opt-in, so tell users before you switch it on.
23 Oct 2026 October 2026 update reaches North America 23 to 26 October Microsoft rolls it out region by region over a weekend, and nobody can postpone it. North America and Australia get it 23 to 26 October 2026; GCC, DoD and China follow a week later. If you didn't test in early access, test the Monday after.
today · Nov 09, 2026
15 Nov 2026ahead Unmanaged developer environments deprecated, including Developer Plan ones From 15 November 2026 you can't create new unmanaged developer environments, and that includes the free Developer Plan ones. Existing ones get suspended from 15 December and deleted from 15 January 2027. Anything a maker built there and still needs has to move before then.
15 Nov 2026ahead Dataverse for Teams environments deprecated Nobody can create a new one after 15 November 2026. If you don't upgrade them to full Dataverse, they're suspended on 15 September 2027 and gone on 30 October 2027. Most tenants have a few Teams apps somebody still uses, so find their owners now.

the story · microsoft power platform estate

From the first call to a setup your own team can run.

Here's what usually prompts a call about your Microsoft Power Platform estate, what we do about it and in which order, and where you end up.

01 · where it hurts02 · what we change03 · how it runs04 · where you end up

incident board · microsoft power platform estate3 open

openHundreds of flows run in the default environment, and half the people who built them don't work here anymore.

recurringSolutions travel between environments as zip files on one person's laptop. When that person is on holiday, nothing…

blockedSomeone wants a Copilot Studio agent, and security wants to know exactly which connectors it can reach before saying…

exposure

Environment strategy and…Power Apps developmentPower Automate flowsCopilot Studio agentsALM and deployment pipelines

startrehearsehandover

Tenant inventory

Environment and DLP model

Build as solutions

Pipelines to production

Handover to the CoE

we are here

ready to hand over

Critical flows now sit in environments that have owners and rules.
Employees only see their own data through the agent now.
Environment strategy that says which environments exist, which are managed and who owns…
DLP policies with every connector classified and a written reason for each block, so…

chapter 01 · where it hurts
Why teams reach out
- Hundreds of flows run in the default environment, and half the people who built them don't work here anymore.
- Solutions travel between environments as zip files on one person's laptop. When that person is on holiday, nothing ships.
- Someone wants a Copilot Studio agent, and security wants to know exactly which connectors it can reach before saying yes.
chapter 02 · what we change
How we solve it
- Environment strategy and governance
- Power Apps development
- Power Automate flows
- Copilot Studio agents
- ALM and deployment pipelines
chapter 03 · how it runs
Our approach
- Tenant inventory
- Environment and DLP model
- Build as solutions
- Pipelines to production
- Handover to the CoE
chapter 04 · where you end up
What changes
- Critical flows now sit in environments that have owners and rules.
- Employees only see their own data through the agent now.
- Environment strategy that says which environments exist, which are managed and who owns each one
- DLP policies with every connector classified and a written reason for each block, so makers know why

what we do

Our Microsoft Power Platform work

5 kinds of Microsoft Power Platform work, each run by engineers who have done it on live tenants.

Environment layout, managed environments, data loss prevention policies and connector rules are agreed with your security team. Then they're enforced through the admin center.
Model-driven apps on Dataverse for structured processes and canvas apps where the screen design matters, built as solutions from day one.
Cloud flows for approvals and integrations, and desktop flows where a legacy system has no API. Error handling and run history are designed in.
Agents built on your knowledge sources and Dataverse data, with authentication through Entra ID and actions limited to what each user may already do.
Solutions moved from development to test to production through Power Platform pipelines or Azure DevOps, with environment variables and connection references set per stage.

capability 01 / 05in production

Environment strategy and governance

Environment layout, managed environments, data loss prevention policies and connector rules are agreed with your security team. Then they're enforced through the admin center.

talk to an engineer about this →

capability 02 / 05in production

Power Apps development

Model-driven apps on Dataverse for structured processes and canvas apps where the screen design matters, built as solutions from day one.

talk to an engineer about this →

capability 03 / 05in production

Power Automate flows

Cloud flows for approvals and integrations, and desktop flows where a legacy system has no API. Error handling and run history are designed in.

talk to an engineer about this →

capability 04 / 05in production

Copilot Studio agents

Agents built on your knowledge sources and Dataverse data, with authentication through Entra ID and actions limited to what each user may already do.

talk to an engineer about this →

capability 05 / 05in production

ALM and deployment pipelines

Solutions moved from development to test to production through Power Platform pipelines or Azure DevOps, with environment variables and connection references set per stage.

talk to an engineer about this →

typical situations

Microsoft Power Platform situations we walk into

We pieced these together from Microsoft Power Platform situations that come up a lot. They're patterns. You won't find a specific client in them.

case file 01

4,000 flows in the default environment and one part-time admin

composite · not a client story

Beforethe situation

The default environment holds about 4,000 flows and 600 apps, many owned by people who have left. A few run payroll exceptions and vendor onboarding, and DLP lets any connector talk to any other.
What we dothe work

We inventory everything with the CoE Starter Kit or the admin APIs, find the items the business depends on, and move them into managed environments as solutions with owners. DLP tightens in stages, starting with connectors that move data outside the tenant, and makers get a request path for new environments.
Afterwhere you end up

Critical flows now sit in environments that have owners and rules. The default environment is back to personal productivity, and every DLP rule has a written reason.

case file 02

HR built a leave agent in Copilot Studio, and it ran on the maker's login

composite · not a client story

Beforethe situation

HR built a Copilot Studio agent on top of a SharePoint site and a Dataverse table of employee records. In testing it answered questions about other people's leave balances, because it was running on the maker's connection.
What we dothe work

We switch the agent to authenticate users through Entra ID with their own connections, narrow knowledge sources to the policy site, and replace direct table access with an action that returns only the signed-in user's record. DLP is reviewed for the connectors it uses.
Afterwhere you end up

Employees only see their own data through the agent now. The maker's credentials aren't involved, and the agent goes to production through the same pipeline as everything else.

case studies

Microsoft Power Platform case studies

All case studies

AI rollout AI and agents

Classic RPA bots to agentic automation

Moving classic RPA bots to agentic automation in UiPath or Power Automate. APIs first, agents only where judgment is needed, and controls on both.

read the case study

AI rollout AI and agents

Microsoft 365 Copilot or Gemini Enterprise rollout with real adoption

Rolling out Microsoft 365 Copilot or Gemini Enterprise with oversharing fixed first, use cases tied to real tasks and adoption measured past login counts.

read the case study

migration ERP and HCM

Dynamics AX 2012 to Dynamics 365 Finance & Operations

We take AX 2012 R2 or R3 systems to Dynamics 365 finance and operations apps, and the code, data, attachments and integrations come across with them.

read the case study

migration CRM, ITSM and automation

Self-hosted Dynamics CRM to Dynamics 365 online, where Microsoft runs the servers

Hosting Dynamics CRM yourself or with a partner keeps you on the on-premises product and its support dates. We move 9.x orgs to Dynamics 365 online.

read the case study

migration CRM, ITSM and automation

Replacing a homegrown or Siebel CRM nobody wants to touch with Salesforce or Dynamics 365

Outgrown a homegrown or Siebel CRM? We move its business rules, data and integrations to Salesforce or Dynamics 365, one business unit at a time.

read the case study

migration Data and analytics

Power BI Premium P SKUs to Microsoft Fabric F SKUs

Moving Power BI Premium per-capacity P SKUs to Microsoft Fabric F SKUs before the agreement ends, sized from real load and reassigned in validated batches.

read the case study

approach

How a Microsoft Power Platform engagement runs

We don't start a step until the last one has produced something you can check.

step 01
Tenant inventory

We list environments, apps, flows, agents and connectors from the admin center and CoE data, then mark what is orphaned, risky or worth keeping.
step 02
Environment and DLP model

We sit down with your security team and agree the development, test and production environments. Then each tier gets managed environment settings and connector rules that match how risky it is.
step 03
Build as solutions

Everything goes into a solution from day one, agents too. We use environment variables and connection references instead of hard-coded values, so the build that passed test is the one that goes live.
step 04
Pipelines to production

We use Power Platform pipelines or Azure DevOps to move managed solutions between stages. Before anything touches production, a named person on your side approves it.
step 05
Handover to the CoE

Your admins keep the governance rules, a maker onboarding guide and a routine for reviewing new connectors and stale flows.

ai on microsoft power platform

Where AI fits on Microsoft Power Platform, and where it needs guardrails.

Power Platform's AI is mostly Copilot Studio and Dataverse. In Copilot Studio, makers build agents that call tools from MCP servers. Dataverse can be an MCP server itself. Makers can also build model-driven apps with the app-builder skill now. For engineering teams the hard parts are authentication and DLP, and then who pays for the Copilot credits.

AI agentasks for data or an action

Scoped identityonly the access it needs

MCP serverthe one door into the platform

Logged, approveda person signs off on writes

Microsoft Power Platformdoes the work

Microsoft publishes the Dataverse MCP server, and Copilot Studio can call external MCP servers. We register MCP connectors per environment under DLP rules and use end-user authentication through Entra ID rather than maker connections. Allowed-client lists stay short. Agents need approval before they delete records or change schemas.

Copilot Studio agents with MCP tools

Copilot Studio agents connect to MCP servers and use their tools and resources, which update on their own when the server changes. You need generative orchestration on. We choose the MCP servers each environment can reach, run agents as the signed-in user through Entra ID, and promote them through pipelines like any other solution.

Dataverse as an MCP server

Dataverse exposes tables and records to MCP clients, with tools for search, SQL read queries, record writes and schema changes. Whether the server is on, and which clients may connect, is set per environment. For us, schema tools only run in development environments. Microsoft renames tools from time to time, and each time we recheck the client allow-lists.

App-builder skill for model-driven apps

The September 2026 feature update made the app-builder skill for model-driven apps generally available. Makers can use it in managed environments. It generates tables, forms and security roles, and we review all three before an app leaves development.

Credit and DLP review

Copilot Studio usage costs Copilot credits, and so do Dataverse MCP calls from agents built somewhere else. So before launch we estimate volumes, and we check the DLP policy on every connector an agent can reach.

architecture

Where a maker's app goes on its way into production

Makers build apps, flows and Copilot Studio agents in a development environment. Pipelines carry them as managed solutions into a managed production environment. There, DLP rules decide which systems they're allowed to reach.

use cases

Typical Microsoft Power Platform projects

The work teams usually bring us, and the platforms Microsoft Power Platform has to talk to while we do it.

POW-01 Hundreds of personal flows run in the default environment and nobody owns them common request
POW-02 A business team wants an app this quarter, and IT's backlog says next year common request
POW-03 HR wants a Copilot Studio agent that answers from internal policies, and security wants to see it first common request
POW-04 Someone still exports solutions by hand and imports them into the next environment common request
POW-05 A legacy desktop system needs automation but has no API common request

Microsoft Power Platform · connected platforms

Microsoft Dynamics 365 Microsoft Fabric Microsoft Entra ID Salesforce OpenAI API

you keep

What a Microsoft Power Platform engagement leaves behind

These are working documents, written against your configuration, so your team can run them without us.

document01

Environment strategy that says which environments exist, which are managed and who owns each one
yours to keep
code02

DLP policies with every connector classified and a written reason for each block, so makers know why
yours to keep
inventory03

Inventory of apps, flows and connectors. The orphaned ones get flagged for a new owner or deletion
yours to keep
tests04

Pipelines for dev, test and prod, with environment variables set per stage so nobody edits values by hand
yours to keep
document05

Copilot Studio checklist we run before an agent ships: how it signs in, what it reads, what it can do
yours to keep

talent and delivery · microsoft power platform

Certified engineers, wherever you need them.

Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time

OnsiteUS business hours

Nearshoreoverlapping US hours

Offshoreovernight progress

Combinedhandover, not hand-off

certifications our engineers hold

Microsoft Certified: Power Platform Developer AssociateMicrosoft
Microsoft Certified: Power BI Data Analyst AssociateMicrosoft

roles we staff

Power Apps developer (canvas and model-driven)
Power Automate developer
Copilot Studio developer
Power Platform administrator (environments, DLP)
Power Platform solution architect
Power BI developer

due diligence · microsoft power platform

Questions to ask any partner, including us.

Put these to anyone bidding on your Microsoft Power Platform work. The ones who've done it answer differently from the ones who've read about it.

Q1
How will you decide what stays in the default environment and what has to move?
Moving everything breaks personal productivity, and moving nothing leaves critical processes unowned. The rule needs criteria such as business impact, data sensitivity and audience.
Q2
Which connectors will you block? And when a maker needs one, who do they ask?
DLP that blocks without a request path pushes makers to workarounds. Classifications should come with a documented exception process.
Q3
Will our Copilot Studio agents act as the signed-in user or as the maker?
If the agent runs on the maker's connection, users can see data they should never see. Make it sign in as the user and keep its actions narrow, and it stays inside that user's permissions.
Q4
How will solutions reach production, and who signs off each release?
Changes made straight in production are hard to audit and harder to roll back. With pipelines, environment variables and connection references, every release goes out the same way.
Q5
How will our admins hear about platform changes once release waves end?
Release Planner is gone by 15 November 2026 and changes now post to one rolling roadmap. Someone has to filter it for your apps each month, or the next deprecation shows up as an outage.

01Should makers build in the default environment?

For personal productivity, yes, as long as the DLP policies are tight. Anything a team depends on belongs in a managed environment with an owner, a solution and a path to production. We usually set that boundary early.

02Do we need Dataverse, or can we use SharePoint lists?

SharePoint lists are fine for a small app with simple data. Once you need related tables, row-level security, auditing or a link to Dynamics 365, use Dataverse. The licences differ too, so we price both before anyone builds.

03Our HR team wants a Copilot Studio agent on employee data. How do we keep it from leaking?

Make the agent sign in as the user, not as the maker. Then it only reaches what that person could already open. We also trim its knowledge sources and actions, and check the DLP rules for every connector it calls.

04Someone else built our Power Platform tenant. Can you clean it up?

Yes. We inventory environments, apps, flows and connectors, find orphaned or risky items, and agree an environment and DLP model before moving what should stay.

05When does the October 2026 Power Platform update hit our North America environments?

The weekend of 23 to 26 October 2026, starting Friday evening and expected to finish before Monday business hours. You can't postpone it. GCC, DoD and China environments get it a week later, 30 October to 2 November.

06We use developer environments and Dataverse for Teams. What happens to them now?

Unmanaged developer environments and Dataverse for Teams environments are both deprecated, and from 15 November 2026 nobody can create new ones. Managed developer environments carry on, one per user. Unmanaged ones get suspended from 15 December and deleted from 15 January 2027. Dataverse for Teams ones run until 15 September 2027 unless you upgrade them. Export the solutions you care about now and give each one an owner.

07What drives Power Platform licensing cost?

Mostly how many users need premium connectors or Dataverse, plus Copilot Studio usage and any capacity add-ons. Design choices such as Dataverse versus SharePoint change the bill, so we compare options against Microsoft's current licensing guide before building.

services

Related services

Projects on Microsoft Power Platform usually end up touching one of these, so they're worth a look.

you are hereMicrosoft Power Platform

fact-checked Checked against vendor and official documentation last checked 2026-10-23 content fingerprint 9f8021eb

01Book a 30-minute working sessionsenior engineer
02Talk to an engineer about your setupreply within 24 hours
03See how similar projects wentcase studies

Reviewed by the Cohash team Microsoft Power Platform is a trademark of its owner, used here to identify the platform. how we handle facts and data →

next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

Book a working session See the case studies

useful to bring

The platform and the version you're on
Where you need to get to, and by when
What's custom: rules, plugins, integrations
Any audit finding or deadline driving it

Makers keep building Power Platform apps. IT still decides where they run and what they can reach.

From the first call to a setup your own team can run.

Why teams reach out

How we solve it

Our approach

What changes

Our Microsoft Power Platform work

Environment strategy and governance

Power Apps development

Power Automate flows

Copilot Studio agents

ALM and deployment pipelines

Microsoft Power Platform situations we walk into

Microsoft Power Platform case studies

Classic RPA bots to agentic automation

Microsoft 365 Copilot or Gemini Enterprise rollout with real adoption

Dynamics AX 2012 to Dynamics 365 Finance & Operations

Self-hosted Dynamics CRM to Dynamics 365 online, where Microsoft runs the servers

Replacing a homegrown or Siebel CRM nobody wants to touch with Salesforce or Dynamics 365

Power BI Premium P SKUs to Microsoft Fabric F SKUs

How a Microsoft Power Platform engagement runs

Tenant inventory

Environment and DLP model

Build as solutions

Pipelines to production

Handover to the CoE

Where AI fits on Microsoft Power Platform, and where it needs guardrails.

Copilot Studio agents with MCP tools

Dataverse as an MCP server

App-builder skill for model-driven apps

Credit and DLP review

Where a maker's app goes on its way into production

Typical Microsoft Power Platform projects

What a Microsoft Power Platform engagement leaves behind

Certified engineers, wherever you need them.

Onsite

Nearshore

Offshore

All time zones

Questions to ask any partner, including us.

How will you decide what stays in the default environment and what has to move?

Which connectors will you block? And when a maker needs one, who do they ask?

Will our Copilot Studio agents act as the signed-in user or as the maker?

How will solutions reach production, and who signs off each release?

How will our admins hear about platform changes once release waves end?

Related services

Tell us what you're running. We'll tell you what we'd do first.