Send from Shared Mailbox Failing - "Folder Not Found"

[AngryBatVoice]

I've got a flow which gets called from Power Apps and creates a file in Sharepoint, then emails the link to the created file via the "Send Email from Shared Mailbox V2" action.

This issue sounds identical that detailed here: https://powerusers.microsoft.com/t5/Building-Flows/Shared-Mailbox-Error-Specified-Folder-not-found/m...  However, that poster's workaround of giving Send As permission to the user triggering the flow does not work in this case.

I created the Flow, and when I run this as myself, it works without a problem.  However, when a secondary user runs the Power App and triggers the flow, the flow succeeds except for the step of sending the email.  The error that gets logged is:

"status": 404,
  "message": "Specified folder not found

After reading the above cited thread, I added Send As permission on the Shared Mailbox to the secondary user, despite the fact that the flow is using my account as the connection.  It still won't send and gives the same error.

The user has permission to the Power App and the Sharepoint Library, so that doesn't seem to be contributing.  And it still fails even if I view the failed run and Resubmit.

[Jcook]

Hello,

Unfortunately when the flow gets triggered from Power Apps, the flow uses the users connections. Instead of the connections you setup in your flow.

—Josh
If you like my post please hit the "Thumbs Up" -- If my post solved your issue please "Mark as a Solution" to help others

[efialttes]

Hi!

---

@Jcook wrote:
Hello,

Unfortunately when the flow gets triggered from Power Apps, the flow uses the users connections. Instead of the connections you setup in your flow.

---

What about using nested flows? so powerapps invokes first flow, this flow invokes a second one via HTTP, which is running with your own credentials

https://flow.microsoft.com/en-us/blog/build-nested-flows/

Hope this helps

[AngryBatVoice]

I was just researching this route, and it makes sense.  However the HTTP action is a Premium action.  If possible, I'm wanting to avoid going Premium to get around what really looks to be a bug. 

For example, clearly the "Send from Shared Mailbox" action behaves as @Jcook describes, since it is triggered via Power App, it is using the Power App user's connection (and despite the secondary user now having Send As permission on the Shared Mailbox, it appears I need to grant them "Full Access" which is not an option here).  However, earlier in the flow, the file is initially created in a folder in my OneDrive, then converted to PDF and saved in Sharepoint.  The secondary user doesn't have permission to this folder on my OneDrive, but that step still succeeds and the resulting file shows it being created by me, so in that case, it appears the OneDrive file creation action is using the flow's connection. All this with no visual representation of this inconsistency in behavior within the Power Automate UI, which tells me it isn't expected behavior.

I'm testing splitting the email function off to its own flow that is triggered when the file is created in Sharepoint.  However, this would be a workaround, not a solution to the underlying problem.

[efialttes]

Hi!

"I'm testing splitting the email function off to its own flow that is triggered when the file is created in Sharepoint.  However, this would be a workaround, not a solution to the underlying problem."

Totally agree... both nested flows approach and second flow triggering when a file is created are workarounds. Let's hope somebody else poin us to the right direction. But, at least we have a plan B.

Thanx for sharing!

[AngryBatVoice]

I just verified, the 2nd flow works.  

So flow #1:

1. Triggered by Power Apps app
2. Create HTML file in OneDrive
3. Convert HTML file to PDF
4. Save PDF to Sharepoint

Then flow #2:

1. Triggered by File Creation/modification in Sharepoint List from flow #1.
2. Sends email from Shared Mailbox to the user that modified the file.

Fingers crossed for an actual fix.  But in the interim, this'll keep us going.

Thanks @efialttes  and @Jcook  for your input!