Flow – Requesting approval from an external user

From time to time, there is a need to involve users outside the organization in processes. For example, applying for a parking space in the parade ground in front of the office. The application process could be automated using Power Platform tools, for example as follows:

• The applicant applies for a parking space using MS Forms.
• Cloud flow automatically saves the application to a SharePoint list
• Flow sends the request for approval (flow’s approval action) to the person responsible for the parking spaces
• After approval, flow sends the request to an external actor
• An external party will confirm that everything is complete. But how?

Everything is straightforward up until the last point. But how do we automatically record that external party’s approval that everything is done?

Let’s try!

Option 1 – Approval function

First, an approval request is sent to an external user who has a Microsoft365 account in their own organization.

It fails immediately. An approval request can only be sent to users in the same tenant.

What if we add this external user as a guest user?

It’s coming through!

However, by clicking on the option (Approve / Reject), you first log in (to the tenant that sent the request), after which you confirm the given answer.

Not a particularly smooth experience.

Utilizing the Approval feature works, but using it requires adding external users to our environment as guest users.

Option 2 – Send email with options function

Next, let’s try to send an email with a options (send email with options action). Let’s send it as a test to an M365 user outside the organization. The end result is interesting. After a short wait, the Send email with options action returns the choice as Rejected.

The problem is that the recipient of the email hasn’t made a choice. They haven’t even opened the email in question.

It gets weirder when you try different reply options. Sometimes the action returns the first option, sometimes the second, and sometimes the third. The reply always comes before the recipient receives the entire email.

But… sometimes the same user is able to select an answer option and it is saved correctly.

We send the request to another tenant for testing. When we send it there, it always fails.

The action works more reliably if the email is sent to a Gmail address, for example.

You can also send an email to another tenant’s shared mailbox. In my test, the first message went astray (flow concluded the response before the message even arrived). Messages sent after this worked as they should.

I don’t dare build anything on top of this until I better understand when this really works and when it doesn’t. In a situation where the answer should come from outside the organization.

Option 3 – Interpreting the response with a custom prompt (cloud flow)

What if we let an external user freely respond to an email they receive? When the response arrives, we interpret the action using custom prompt .

The flow starts when an email arrives. Limit the flow to start when replies come from predefined addresses.

Let’s add a custom prompt to the workflow, asking the AI ​​to extract the information we’re interested in from the email response:

• Which user’s request is being processed?
• What is the response (request processed or rejected)
• If the request has been rejected, the reason for the rejection

The prompt receives the body of the received email as input.

In practice, the external actor receives an automatic email to which he can respond in a free-form manner.

When the response arrives, the flow starts and AI takes care of the rest!

Let’s also try a negative answer.

The end result is correct.

However, it’s good to take a breather at this point. And test with an answer written in several different ways that the AI ​​interprets it correctly.

Finally, you can still consider whether this is a process that can withstand possible misinterpretations by AI.

Option 4 – Interpreting the response with an autonomous agent

Agents are the thing these days. What if we implemented the previous option as an autonomous agent? Let’s create an agent and give it the same instructions that we gave to the prompt.

Let’s add the When a new email arrives action as a trigger for the agent. Just like we did in the workflow.

Testing with incoming email.

And that’s where it comes from.

Compared to cloudfFlow, it is a bit more laborious for the agent to save the parsed response to a SharePoint list, but it can still be done.

Adding the necessary actions as a tools to the agent

• SharePoint – Get items. This finds the row to update based on the user id
• SharePoint – Update item. This updates the data in the correct row.

Yes, they will go there.

Option 5 – Creating and processing an HTML form with cloud flow

We can of course send an external party a link to an html form, where the user confirms how the parking space ended up. The form is generated using a cloud flow that starts from an http call. The responses sent via the form are processed in the same way.

I have wrote posts about this devious method, for example, in this post.

Summary

So how would I solve the problem in this example? If I could, I would add external users to the environment as guest users and use flow’s approval action. Quick and easy. And no chance of the AI ​​misinterpreting the answer.

If adding a guest user is out of the question, I would proceed with flow and my own prompt. If we can tolerate the fact that AI may sometimes misinterpret messages. I would not go for an autonomous agent at this point, because this workflow does not otherwise benefit from AI features. They only make the implementation of the basic workflow a little more difficult.