Using JSON to optimize Power Automate input parameters in the Power Apps trigger

This blog post is part of a 3-part series:

1. Understanding default naming for Power Automate input parameters in the Power Apps trigger
2. A uniform approach to Power Automate input parameters in the Power Apps trigger
3. Using JSON to optimize Power Automate input parameters in the Power Apps trigger (this post)

---

In the previous two posts I published, I described how input parameters for the Power Apps trigger are created in a Power Automate flow and a solution to provide uniform naming for all input parameters in the flow. However, this is not a flexible solution. It can present inconveniences when adding an additional input parameter, or changing the setup of your flow where a certain input parameter is used in a different context.

In this blog post, which is the last in this series, I want to share an approach to input parameters that allows a lot of flexibility in the number and names of input variables: using JSON as input in the flow.

The method

Instead of creating an input parameter for all of the inputs that I need in the flow, I’m going to create one input parameter of type text. This input parameter will contain a JSON object (passed as a string), which will have fields for each of the desired inputs. What does that look like?

First, I’m going to add an “Initialize variable” action immediately after the trigger in my flow. This will be a variable of type string with the name “Inputs”. Just as in my previous blog post, I’m renaming the action to the name of the variable and then adding the “Ask in PowerApps” dynamic content. This will create an input parameter for the flow called “Inputs_Value”.

This variable will be a JSON object. To get the contents of the JSON object, I’m adding a “Parse JSON” action after my variable initialization. The content to parse will be the variable that I created. I’m generating a schema by providing a sample JSON object that represents the input parameters I want to provide in my flow. Taking the same example variables as in the previous blog posts, this is the sample schema I’m adding into my flow:

{
    "ItemId": 1,
    "ItemTitle": "Title",
    "EmailSubject": "Subject of the email"
} 

The schema is generated automatically. If I now add another action into the flow, my input parameters will be available as outputs of the parse action.

If I add this flow into a Power Apps canvas app, there is only one text input variable needed, as you can see below.

The good and the bad

As mentioned before, this approach provides a lot of flexibility. If I need to remove an input, I remove it from the schema and don’t provide it in my app anymore. It will not still linger and be an extra input that I need to provide a value for even though it isn’t used anymore.

Adding an input is also relatively easy: I change the schema by adding a field and provide the extra input as part of the JSON string created in the app. This will have no impact on the trigger (it still expects one input parameter), and will not require me to remove and re-add the flow input my app before it works.

The main downside of this method is that if someone else is building the app and they are not aware that the input string should be JSON or which fields are expected exactly, they will not be helped by the hint in Power Apps studio. You can’t provide the correct inputs without having knowledge of the flow, or it being clearly documented somewhere.

Next to flexibility, another advantage of this method is that the trigger is completely separated from the logic in the flow. (The same goes for the approach using variables for each of the inputs described in my previous post.)  If you want to change the trigger of the flow to a different trigger (for example a manual trigger to be used as a run-only child flow with owner-provided connections), you don’t have to replace the input parameters everywhere in the logic of the flow. You only have to replace it once in the “Initialize variable” action. Every reference to that variable will remain intact, sparing a lot of work.

I believe this approach to input parameters provides a lot of flexibility that is currently missing for Power Apps triggered flows. Given good documentation, it can enable you to always have the right input variables available in your flow, without risks of breaking it or the app(s) it is used in when things change.