Automations that still run after the person who built them leaves.
Most Power Automate estates start with a few useful flows owned by one person's account. We build flows and apps on Power Platform properly, move them into solutions, and set up the environments, connector policies and service identities that keep them running after that person leaves.
Makers and developerssolutions · source controlDeployment pipelinesdev · test · prod
02 · Power Platform
Power Automatecloud flows · desktop flowsCopilot Studio agent flowstools for agentsDLP policiesbusiness · non-business · blocked
03 · Identity
Service principalsEntra ID app registrationsCredential vaultAzure Key Vault · CyberArk
04 · Target systems
Dynamics 365DataverseSalesforceSalesforce FlowLegacy desktop appsgreen screen · no API
Microsoft Power PlatformMicrosoft Dynamics 365SalesforceMicrosoft Entra ID
in short·15-second read
Workflow automation replaces manual steps such as approvals, data entry and hand-offs between systems with automated flows.
Cohash builds automations on Microsoft Power Platform, including Power Automate cloud and desktop flows, Power Apps and Copilot Studio agent flows. We also set up environments, data loss prevention policies and service principals, so automations are governed and don't depend on one employee's account.
you probably need this if
A production approval flow stops working when the employee who built it leaves.
Makers can connect any connector to any other because no DLP policy exists.
Flows sit in the default environment instead of in solutions.
terms on this pageConnectordefinitionThe integration between an identity platform and an app. It's how the platform reads and changes accounts and access in that app.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Workflow Automation, 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 · workflow automation3 open
openA production approval flow stops working when the employee who built it leaves.
recurringMakers can connect any connector to any other because no DLP policy exists.
blockedFlows sit in the default environment instead of in solutions.
exposure
Power Automate cloud flowsDesktop flows for legacy appsCopilot Studio agent flowsEnvironments and DLP policiesService identities and connectionsSalesforce Flow and…
startrehearsehandover
Inventory
Prioritize
Build and govern
Operate
we are here
ready to hand over
If one person leaves, the approval flow keeps running, and failures get to someone the…
Business data can no longer slip into consumer services by accident.
The password is in a vault and the bot's actions show under its own account.
Automation inventory with owners and risk
chapter 01 · where it hurts
Why teams reach out
A production approval flow stops working when the employee who built it leaves.
Makers can connect any connector to any other because no DLP policy exists.
Flows sit in the default environment instead of in solutions.
chapter 02 · what we change
How we solve it
Power Automate cloud flows
Desktop flows for legacy apps
Copilot Studio agent flows
Environments and DLP policies
Service identities and connections
Salesforce Flow and cross-platform work
chapter 03 · how it runs
Our approach
Inventory
Prioritize
Build and govern
Operate
chapter 04 · where you end up
What changes
If one person leaves, the approval flow keeps running, and failures get to someone the same day.
Business data can no longer slip into consumer services by accident.
The password is in a vault and the bot's actions show under its own account.
Automation inventory with owners and risk
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Approvals, notifications and system-to-system updates built in solutions, with error handling, retries and run history someone actually monitors.
Some green-screen and desktop apps have no API at all. We automate those with RPA and keep the credentials in a vault rather than the flow.
We build deterministic agent flows for agents to call as tools. Some existing cloud flows are worth converting too, but only when billing against Copilot Studio capacity makes sense.
Development, test and production environments, data loss prevention policies that group connectors, and a managed path for makers to request new ones.
Flows shouldn't run as a person. We move them to service principals or dedicated service accounts and track connection ownership, so a resignation doesn't take production down with it.
If the process lives in Salesforce, we build it in Salesforce Flow. Power Platform or an API only comes in where it's actually needed.
capability 01 / 06in production
Power Automate cloud flows
Approvals, notifications and system-to-system updates built in solutions, with error handling, retries and run history someone actually monitors.
We build deterministic agent flows for agents to call as tools. Some existing cloud flows are worth converting too, but only when billing against Copilot Studio capacity makes sense.
Flows shouldn't run as a person. We move them to service principals or dedicated service accounts and track connection ownership, so a resignation doesn't take production down with it.
We pieced these together from Workflow Automation situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Invoice approvals stopped when the flow owner left
composite · not a client story
Beforethe situation
One analyst's account ran the invoice approval flow. When they left and the account was switched off, approvals simply stopped, and finance only found out because suppliers started chasing money.
What we dothe work
Reassign ownership to get it running again. The flow then goes into a solution with connection references, the connections move to a service principal or dedicated account, and failed runs alert a mailbox someone watches. Then find every other flow owned by one user.
Afterwhere you end up
If one person leaves, the approval flow keeps running, and failures get to someone the same day. Check the register for other flows with the same exposure.
case file 02
A default environment full of maker flows and no DLP policy
composite · not a client story
Beforethe situation
Everyone built in the default environment, and there are hundreds of flows there now. No DLP policy exists, so SharePoint and Dataverse data is flowing into people's personal Dropbox and Gmail.
What we dothe work
Write the DLP policy first, tenant-wide, with business and consumer connectors split. Then test it against the existing flows to see what it breaks before enforcing anything. Business-critical flows move into solutions, in dedicated environments for the teams that own them.
Afterwhere you end up
Business data can no longer slip into consumer services by accident. Makers keep building, and the flows that matter live in environments that have owners and backups.
case file 03
Desktop flow typing a stored password into a terminal app
composite · not a client story
Beforethe situation
Claims get keyed into an old terminal app by a desktop flow, because the app has no API. The password is sitting in a flow variable. And it runs attended, on one person's PC.
What we dothe work
We move the flow onto an unattended machine group. Its credential goes into Azure Key Vault and gets pulled at runtime through Power Automate credentials, and the bot gets its own account in the terminal app. We add screen checks so that if a field moves, the run fails instead of typing bad data.
Afterwhere you end up
The password is in a vault and the bot's actions show under its own account. The flow no longer depends on one desk.
How governed Power Platform automations run across your systems
Flows and agent flows are built in solutions and promoted through development, test and production environments under DLP policies. In production they run under service principals, not personal accounts, and connect to Dynamics 365, Salesforce and legacy apps.
01 · Build
Makers and developerssolutions · source control → Deployment pipelines · solution export
Deployment pipelinesdev · test · prod → Power Automate · managed solution
Makers and developers → Deployment pipelines: solution export
Deployment pipelines → Power Automate: managed solution
DLP policies → Power Automate: connector rules
Service principals → Power Automate: connection identity
Power Automate → Dynamics 365: Dataverse connector
Power Automate → Salesforce: Salesforce connector
Credential vault → Power Automate: desktop credentials
Power Automate → Legacy desktop apps: desktop flow
Copilot Studio agent flows → Dynamics 365: agent flow actions
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Inventory
Pull existing flows and apps from the Power Platform admin center. Record owners, connectors and failure rates.
step 02
Prioritize
Processes ranked by volume, error cost and how much they depend on a single person.
step 03
Build and govern
Automations get built in solutions and deployed through pipelines. The environments and DLP policies go in at the same time, not after.
step 04
Operate
Monitoring, alerting and a maker support process so the estate stays healthy.
you keep
What you're left with
We write these for your Workflow Automation setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Automation inventory with owners and risk
yours to keep
guide02
Environment strategy and DLP policy set
yours to keep
code03
Solution-packaged flows and apps with deployment pipelines
yours to keep
inventory04
Service identity and connection ownership register
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.
Put these to anyone bidding on your Workflow Automation work. The ones who've done it answer differently from the ones who've read about it.
Q1
Who will own each flow's connections after go-live?
Flows break when the person whose connection they run on leaves. Each connection should belong to a named service identity and sit in a register.
Q2
Which connectors will our DLP policies allow together?
Without DLP connector groups, any maker can wire business data straight into a consumer service. Agree the policy design before more flows get built, not after.
Q3
Should this process be a Power Automate flow or a Copilot Studio agent flow?
Agent flows consume Copilot Studio capacity per action, and you can't undo converting a flow. Decide on volume and licensing. Novelty is a bad reason.
Q4
How will failed runs be noticed, and by whom?
Run history nobody reads hides failures for weeks. Ask where failure alerts go and who answers them.
Q5
How will flows move from development to production?
Flows edited directly in production can't be rolled back. Move solutions through pipelines and you get versions and an approval step.
01Should we use Power Automate flows or Copilot Studio agent flows?
Both are rule-based flows. Microsoft documents that agent flows consume Copilot Studio capacity for each action, while Power Automate flows use Power Automate licensing, and converting a flow to an agent flow can't be reversed. We compare your volumes and licenses before choosing.
02Our flows are owned by individual users. Can you fix that?
Yes. We move flows into solutions, change connections to service principals or service accounts where the connector supports it, and set up a register of who owns what.
03How long does it take to govern an existing Power Platform estate?
Depends on how many environments, makers and flows you've got. The environments and DLP policies are usually the quick part. Moving business-critical flows into solutions is slower, and we do it in batches, most important first.
04Do you also build Power Apps?
Yes. Canvas or model-driven, usually on Dataverse, and we build the flows behind them at the same time.
05Can our citizen developers keep building once the estate is governed?
Yes. Governance is there to make building safer. It shouldn't stop it. We set up a maker environment with sensible DLP and a request path for new connectors. When a flow proves useful, there's a way to promote it into a supported solution.
related
Often paired with
Projects on Workflow Automation usually end up touching one of these, so they're worth a look.
