Showing results for 
Search instead for 
Did you mean: 

Start Flow from Flow passing parameter

There are ways to start a flow from Powerapps, passing parameters.

It's a shame we don't have the same for starting flows from within flows.

This would make it really easy to start using flows as "functions" that can be reused.


Currently, I find myself reproducing parts of flows in several "copies" of the flow.

A (simple) example?

Suppose I create a logging SP list for seeing all the changes some of my important flows actually perform (this could be for debugging or for other reasons). I have to reproduce all the parameters of this "create item" step time and again, while I would love to just abstract it away in a flow called log_entry that I just pass some parameters to (the actual info to log).


Obviously this has the added advantage of better maintainability (if there is an error in my logic or if I want to change the way it works, I just have to make the change in one place).

Status: New
Level: Powered On

Agree that this would be useful feature.


The way I have overcome this is to use a sharepoint list to be the interface, in that I write the data that I want to pass to the new flow into a list and then have the Child flow trigger on a new row to the list . The Child flow reads in the data from the list and has that as its starting point, deleting the row when it has finished.



Level 10

I also really need this feature...

Here is my case : I have a flow that can be triggered whether from a list item OR from a small PowerApps app. As of now, I duplicated the flow since the triggers are different.

I would prefer to have one "BASE" flow and 2 small flows calling the BASE flow: one triggered from a selected list item and another one triggered from PowerApps. This way, when I need to update the way the flow behaves, I just change my BASE flow.

Hope this will come soon... 🙂


Level: Powered On

Hi @R3dKap 


I worked out a way to do this. Create an interface list that contains the parameters you want to pass between the flows. The parent flows write to the interface list being triggered with by powerapps or something else.


Your child flow which has the common code is triggered on a new row being added to the interface list. 


Last thing the child flow does is to remove the entry in the interface list to tidy up.


It works quite well and you have the arguments stored in the interface list t9 help with debugging 

Level 10

Hi @Jambo1,

Thanks for your post-back... In fact, I found an easier solution in another similar idea (

The solution is here:

I tested it and it works fine... 🙂



Level: Powered On

Dear @Jambo1

I do agree that your solution is a workaround that creates the effect I'm looking for.

Yet: that's exactly what it is: a workaround!

  • I have to create a new interface table for each case where I want to do this (more and more, actually)
  • It takes quite a lot of manual work for something that is probably straightforward to realize for Microsoft
  • The whole intent of frameworks like MS Flow should be to make things easy for non-developers. You probably are and hence were able to figure the workaround out, but it should be simply obvious, no?

That notwithstanding: thank you for your contribution. Maybe some people will find your suggestion and actually be able to use it.

Level 10

@Jambo1 : totally agreed ! 🙂

Level 8

@Jambo1 ,


Not sure I understand the request here.  Today, you can create Flows that have an HTTP Request as a trigger.  The trigger action can take input parameters in the body.  You can also have the Flow return results using the Response action.


Though it's not a function perse, it does give you the same result, no?

Level: Powered On

@haniel  - I agree with calling HTTP Request and I've done so.  However, it seems with the new licensing announcement, the HTTP request is becoming a premium feature.  I have heard they are going to create a new action which will allow calling another flow without doing an HTTP Request.

Level 8



Just today I inquired into the progress of such connector.  Let's hope we get it soon.

Level: Powered On

This feature was added on 11/2019. It is only available when used inside of a "Solution". Be sure to use the "Manually trigger a flow" trigger in your child flow to receive parameters from the parent. This actually works very well. 

It is definitely cleaner than the old raw HTTP request method.

Instructions here: