Power automate send notification to co-creator

(1) Share

Report

Posted on by khedidja90

Hi,

I have a Power Automate Cloud flow, my flow should send notification to user who execute flow, but sometime, the notification is sended to co-creator flow, why ?

Categories:

Building flows

I have the same question (0)

All responses (4)

Answers (0)

Sort by

André Arnaud de Cal... 667 on at

Like (0)

Report
Copy link

Link copied!

Hi khedidja90,

Can you help us with a translation of the details into English? Is Propriétaire the Owner? If so, what exact variable did you include?

Was this reply helpful? Yes No
Suggested answer

11manish 2,943 on at

Like (0)

Report
Copy link

Link copied!
Instead of relying on the flow's execution context, always:

Capture the actual user explicitly (email or Azure AD Object ID).

Retrieve the corresponding Dataverse systemuserid.

Set the Notification Owner to that user.

This removes all ambiguity and ensures the notification is always sent to the correct person, regardless of who owns the flow or whose connection is being used.

Was this reply helpful? Yes No
Suggested answer

Valantis 6,378 on at

Like (1)

Report
Copy link

Link copied!

Hi @khedidja90,

This happens when the trigger or notification action runs under a shared connection owned by the co-creator rather than the actual triggering user.

For flows triggered by a Power Apps button or form, the user who triggers it is captured via the trigger context, not the connection owner. If your notification step uses the connection's own identity (e.g. Send notification via the flow's connection) instead of the dynamic trigger user, it defaults to whoever owns that connection often the co-creator who set it up.

Fix: explicitly capture the triggering user's email instead of relying on the connection identity.
If triggered from Power Apps: pass the user's email as a parameter from the app (User().Email) into the flow, then use that value in your notification action's recipient field.

If triggered from a SharePoint or Dataverse event: use the trigger's Created By or Modified By field instead of any connection-based identity.

For the actual notification action (Send a notification to a Dataverse user, or Mail to a specific user), bind the recipient field directly to this captured email/user ID rather than leaving it on a default or connection-based value.

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
Suggested answer

Haque 3,446 on at

Like (1)

Report
Copy link

Link copied!
Hi @khedidja90,

It depends how the flow identifies the "current user" or "triggering user" in different contexts.

Let's analyse the user context:

Trigger Context vs. Run-Only User

If the flow is manually triggered by a user, the trigger context usually contains the user who started it.

However, if the flow is run by another user on behalf of someone else (e.g., a co-owner or co-creator running the flow manually), the flow’s context may reflect the person who actually triggered the run, not the original intended user.

Run-Only Users and Shared Flows

When flows are shared, the "Run-only user" permissions and connections can affect who the flow sees as the executor.

If a co-creator runs the flow, the flow’s triggerOutputs()?['headers']['x-ms-user-name'] or similar user context may show the co-creator, not the original user.

Using the Wrong User Property

Sometimes flows use dynamic content like "Created By" or "Modified By" from a SharePoint item or other data source, which may not correspond to the current flow runner.

To notify the user who triggered the flow, you should use the trigger’s user context (e.g., triggerOutputs()?['headers']['x-ms-user-name'] or triggerBody()?['user'] depending on the trigger).

Delegated vs. App Permissions

If the flow uses connections with delegated permissions, the user context is preserved.

If it uses app-only permissions or service accounts, the flow may run under a different identity.

Possible Fix:

Use the trigger’s user context to get the email or user ID of the person who started the flow. For example, for manual triggers, use the User() function or trigger outputs that contain the user’s email.

Avoid relying on static user fields from data sources unless they represent the flow runner.

If the flow is triggered by Power Apps or another system, pass the user’s email explicitly as a parameter (I agree with Valantis ) .

Check the flow run history to confirm which user is recorded as the trigger initiator.

I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!

Was this reply helpful? Yes No