#PowerPlatformTip 34: 'PowerApps V2'

TL;DR: Start flows from canvas apps with the Power Apps (V2) trigger. You define typed, named inputs (Text, Yes/No, File, Email, Number, Date), each required or optional, and you decide per connection whether the flow runs with the maker’s connection or the app user’s. Call it with CreateOrder.Run(txtTitle.Text, Value(txtQty.Text), tglUrgent.Value).

💡 Challenge

The older Power Apps (V1) trigger creates its inputs on the fly via “Ask in Power Apps”. The parameters show up in the app’s Run() call with generated names such as Createitem_Title, and it is easy to pass arguments in the wrong order as a flow grows. On top of that you need control over whose identity the flow uses when it writes data.

✅ Solution

Use the Power Apps (V2) trigger (in the new designer: When Power Apps calls a flow (V2)). It lets you declare each input with a type and a name, mark it optional, and choose for every connection in the flow whether it is embedded (the connection you configured) or provided by the user who runs the app.

🔧 How It’s Done

1. Define the inputs in the trigger.

🔸 Add inputs of the types Text, Yes/No, File, Email, Number or Date, and give each a clear name, for example Title, Quantity, Urgent.

🔸 Mark inputs that the app does not always send as optional.

🔸 Each input reaches the flow with its declared type. A Number input arrives as a number and a Yes/No input as a boolean, so the flow needs no int() or bool() conversion.

2. Call the flow from the app.

🔸 Add the flow in Power Apps Studio via the Power Automate pane, then call it in a behavior property such as OnSelect:

Set(
    varResult,
    CreateOrder.Run(txtTitle.Text, Value(txtQty.Text), tglUrgent.Value)
)

🔸 The arguments follow the order of the required inputs. When you type CreateOrder.Run(, the formula bar shows the input names you defined.

3. Decide whose connection the flow uses.

🔸 Open the flow’s details page > Run only users > Edit. Under Connections Used, choose for each connection:

• Provided by run-only user: the action runs as the person using the app. Each user needs access to the data source and creates their own connection.
• A specific connection: the action runs with that embedded connection, for example a service account that always writes to the same list, regardless of who uses the app.

🔸 After you switch a connection to the invoker’s, refresh the flow in the app (or remove and re-add it) and save the app.

4. Migrate an existing V1 flow carefully.

🔸 Replace the V1 trigger with the V2 trigger and recreate the inputs.

🔸 In the app, remove and re-add the flow, then save the app. Without that step the app keeps the old connection information and the call fails with a connection error.

🔸 Update every Run() call to the new inputs and test it before you publish.

🎉 Result

The app calls the flow with typed, named arguments, the values arrive in the flow with the right type, and the flow writes data with exactly the identity you chose.

🌟 Key Advantages

🔸 Typed inputs: numbers, booleans, dates, emails and files arrive as what they are.

🔸 Optional inputs: add parameters later without breaking every existing call.

🔸 Identity under control: embedded or invoker connection, per connection.

🔸 Readable calls: the input names show up while you write Run().

🎥 Video Tutorial

🛠️ FAQ

1. What’s the main difference between V1 and V2 Power Apps triggers?

V2 has declared inputs with types and names, optional inputs and file inputs. It also supports both embedded and invoker connections, which you set under Run only users.

2. Can I migrate existing flows from V1 to V2 triggers?

Yes. Swap the trigger, recreate the inputs, then remove and re-add the flow in the app and save the app. Update the Run() calls to the new inputs.

3. Does the V2 trigger need a premium license?

No. The trigger itself is standard. The licensing of the flow depends on the connectors used in its actions, the same as with V1.

4. Who needs access to the data when the flow uses the invoker’s connection?

Every app user. With Provided by run-only user, the action runs under the user’s own connection, so the user needs permission for that action, otherwise the flow fails.

🔗 Related Tips

🔸 Run Power Apps Connections with Elevated Permissions via Power Automate - the embedded-connection scenario in detail.

🔸 #PowerPlatformTip 126: ‘User Context for Automated Tasks’ - the opposite approach, running as the calling user instead of a service account.