#PowerPlatformTip 135: 'One Flow, Many Users'

TL;DR: Make one Power App the trigger hub for your shared flows and send Adaptive Cards that link to it, every user runs the flow in their own context, with no per-user permissions or duplicate flows.

🧰 Free tool: Not sure how your recurrence trigger schedule reads? Get it explained in plain language (frequency + interval, not Unix cron): Recurrence trigger explainer.

💡 Challenge

You’ve built an awesome flow, but now everyone should use it. The problem: Outlook-based flows need permission setups or even a duplicate per user. That’s messy, slow, and hard to maintain. The root cause is how a flow’s run-as identity is fixed: a scheduled (recurrence-triggered) flow always runs as whoever owns it, so if that flow needs to act as different individual users, the only options are granting the owner delegated access to every mailbox/resource involved, or literally cloning the flow once per user, both of which get worse as headcount grows.

✅ Solution

Make one Power App the trigger hub for your shared flows, then send Adaptive Cards (e.g. every morning) with a link to the app. Users click the card and trigger the flow in their own user context, no extra permissions needed.

flowchart LR
    A["Scheduled flow"] -->|sends| B["Adaptive Card to each user"]
    B -->|user clicks link| C["Power App (trigger hub)"]
    C -->|runs in the clicking user's context| D["Shared flow executes as that user"]

🔧 How It’s Done

1. Create a Power App

🔸 Add a simple button or menu to trigger your flow(s).

2. Build a scheduled flow

🔸 Use a recurrence trigger to send an Adaptive Card via Teams or Outlook at 7:00 AM.

3. Link the Power App

🔸 Include a deep link or app URL inside the Adaptive Card.

4. User clicks = flow starts

🔸 The flow runs in the context of the signed-in user, not the maker. Technically, this works because the flow is triggered by the Power Apps (V2) trigger rather than a recurrence trigger: whoever calls YourFlow.Run(...) from inside the app becomes the identity the flow’s own connections execute as (for connectors configured to use the trigger user’s connection), the app itself is just the delivery mechanism, the actual run-as context comes from the trigger type, not from the Adaptive Card or the button.

🔸 This is also why it’s a different mechanism from #PowerPlatformTip 34’s “PowerApps V2 trigger with a service-user connection”: that pattern deliberately pins the flow’s identity to one fixed service account regardless of who clicks the button, useful when you want a consistent execution context. This pattern does the opposite on purpose, letting the identity vary per clicking user, useful when the action genuinely needs to happen “as them” (e.g. sending an email that should appear to come from that person, or writing an audit record attributed to them).

5. (Optional) Add guardrails

🔸 Add confirmation screens or multiple flow triggers inside the app.

6. Plan for auditing across many identities

🔸 One side effect of per-user execution: run history is no longer consolidated under a single owner. Each user’s click produces a run visible in their own flow run history (and to an environment admin via the admin center), not in one central dashboard the way a single-owner scheduled flow’s runs would be. If you need centralized visibility into who ran what and when, plan for it explicitly, e.g. have the flow log a row to a SharePoint list or Dataverse table on each run, rather than assuming you’ll find it all in one place later.

🎉 Result

You’ve got one centralized setup, and everyone can use it without breaking permissions or duplicating logic. Each employee triggers their flow when needed, all clean and compliant.

🌟 Key Advantages

🔸 One flow, multiple users, clean and efficient

🔸 Runs in the secure context of the signed-in user, driven by the Power Apps (V2) trigger rather than the app itself

🔸 Avoids Outlook or shared-mailbox headaches

🔸 Centralized but flexible execution

🔸 Easily extendable with more flows

🔸 Complements (rather than duplicates) the fixed-identity, service-user pattern from #PowerPlatformTip 34, use whichever matches whether the action should happen as the user or as a consistent service account

🛠️ FAQ

1. Can I still use this if I don’t send Adaptive Cards?

Yes! You can share the Power App through Teams, SharePoint, or email, the Adaptive Card just makes it smoother.

2. What if the user needs to confirm something first?

Build a confirmation screen into the app, you have full control over the experience.

3. Can I trigger more than one flow?

Absolutely, add multiple buttons or logic in the app to handle different scenarios.

🔗 Related Tips

• #PowerPlatformTip 111: Adaptive Cards for Dynamic Approvals, build richer, interactive Adaptive Cards for your triggers.
• #PowerPlatformTip 68: Power Apps and Power Apps for Teams, choose the best home for your trigger-hub app.