#PowerPlatformTip 51: 'Which Flow Calls Which Flow'

TL;DR: Map parent-child flow dependencies with Serge Luca’s free “Flows Call Flows” Power BI report, or answer “who calls this flow?” with one Dataverse Web API query on the workflows table. Turn on child flows before their parents.

💡 Challenge

Managing and deploying Microsoft Power Automate solutions with numerous parent-child flow relationships is complex. You need to know which flows call others to activate them in the correct order and assess the impact of any changes. Power Automate’s own UI doesn’t surface this: opening a flow shows you its own actions, not a reverse index of every other flow in the solution that calls it via “Run a Child Flow”.

✅ Solution

Use the “Which Flow Calls Which Flow” utility to analyze and map parent and child flows, or query the flow definitions in Dataverse yourself. Both work on solution-aware cloud flows, because a child flow and its parent live in a solution.

🔧 How It’s Done

1. Get the utility

🔸 Open sergeluca/PowerPlatform-Which-flow-calls-which-flow on GitHub (by Serge Luca and Isabelle Van Campenhoudt, updated April 2026).

🔸 The Application folder contains a solution package (WorkflowCallWorkflow_1_0_0_15.zip) and the Power BI report WorkflowCallWorkflows.pbix. The README links an installation video that walks through the setup.

2. Prerequisites

🔸 Power BI Desktop for the report, a Dataverse environment with your solution-aware flows, and permission to import a solution and read the flows in that environment.

3. Read the report

🔸 One view lists the parent flows on the left and the child flows they call on the right, another shows by which flows a specific flow is called. A caller type marks flows that start from a button.

🔸 Use the Power BI search and filter pane to jump to the flow you plan to change.

4. Plan the deployment order

🔸 Turn on child flows before their parents, and change a child only after you’ve checked every parent the report lists for it.

🔸 A grandparent → parent → child chain shows up as two one-hop links. Follow deep hierarchies one level at a time.

🔎 Tool-free alternative: query the workflows table

Every cloud flow in a solution-aware environment is a row in the Dataverse workflow table (category 5), and its full definition sits in the clientdata column. A “Run a Child Flow” action is stored there as

"type": "Workflow",
"inputs": { "host": { "workflowReferenceName": "<child workflowid>" } }

so the child flow’s workflowid is literally in the parent’s text. One Web API call answers “who calls this flow”:

GET https://<org>.crm.dynamics.com/api/data/v9.2/workflows
    ?$select=name,workflowid,statecode
    &$filter=category eq 5 and contains(clientdata,'<child workflowid>')

Shape of the response (shortened):

{
  "value": [
    { "name": "<parent flow 1>", "workflowid": "<parent workflowid>", "statecode": 1 },
    { "name": "<parent flow 2>", "workflowid": "<parent workflowid>", "statecode": 0 }
  ]
}

Tested in a dev environment with 109 cloud flows: the call returned the two parent flows that run that child (statecode 1 = turned on, 0 = turned off). The match is case-insensitive, an upper-case GUID finds the same rows. Replace the GUID with the string workflowReferenceName and you get every flow in the environment that has at least one child-flow action (four of the 109 here), which is the complete parent list in one request. The same $filter works in the “List rows” action of a flow or in a canvas app.

What this does not find, observed in the same environment:

🔸 Flows started over an HTTP trigger URL. The caller only stores https://<region>.logic.azure.com:443/workflows/<logic-app-id>/triggers/manual/..., and that id is not the Dataverse workflowid, so searching for the child’s GUID returns nothing. In one case the URL was not even in the flow but in an environment variable.

🔸 Flows started from a Power App or a Copilot, their trigger is "type": "Request", "kind": "PowerAppV2", and no other flow references them.

🎉 Result

You get a clear map of the “Run a Child Flow” dependencies, the right activation order for deployments and a fast answer to “what breaks if I change this flow?”.

🌟 Key Advantages

🔸 Visualize parent-child flow relationships instantly

🔸 Avoid deployment errors by following the correct activation order

🔸 Speed up impact analysis when modifying or refactoring flows

🔸 The Web API query needs no installation and runs inside a flow as well

⚠️ Good to Know

Both approaches see relationships through the “Run a Child Flow” action. A flow called over an HTTP trigger URL, started from a Power App or triggered by a Dataverse row change isn’t linked to its caller in the definition, so check these callers by hand.

🛠️ FAQ

1. Does this work with flows across different environments?

Each query and each report run covers one environment. A child flow is always called within the same environment, so analyze each environment separately.

2. Do my flows have to be in a solution?

Yes. Child flows must be created in a solution, and the parent flow has to be in a solution to use “Run a Child Flow”. Flows outside solutions can’t call child flows this way.

3. Can this help me identify unused flows?

Partly. A flow that appears neither as caller nor as callee isn’t part of any child-flow chain, but it can still run from its own trigger. Check its run history before you delete it.

4. Can I find the parents of one child flow without installing anything?

Yes. Query the workflows table with $filter=category eq 5 and contains(clientdata,'<child workflowid>') and select name,workflowid,statecode. The child’s GUID is stored in the parent’s clientdata as workflowReferenceName, so the call returns exactly the flows that run it through “Run a Child Flow”. Flows calling the child over an HTTP URL are not found this way, because the URL does not contain the Dataverse workflowid.

🔗 Related Tips

🔸 #PowerPlatformTip 36: ‘Static Result’ - mock a child flow’s action while you verify the parent-child map this utility produces.

🔸 How to Track the Current Progress of a Flow in PowerApps - once you know the call chain, surface its live progress back in the app.