Answered

Power Automate - Actionable Messages Migration from EAT to MS Entra AAD Authentication

(2) Share

Report

Posted on by stephanbergh

Good morning,
Microsoft will be completely retiring EAT Tokens as a method of authenticating Actionable Messages for Outlook (With Adaptive Cards) as of 15 May 2026.
We need to migrate our existing Actionable Email Developer Dashboard providers to MS Entra.
When migrating, we are prompted the following:
"Is this a power automate scenario?". Upon selecting yes, and ensuring everything is correct, I still get "The remote endpoint returned an error (HTTP '401'). Please try again later."
Things to note:
- My adaptive cards are fine, it renders perfectly.
- I have "Authorization" as a header and the value is set to "" as per the documentation (Within the Action.HTTP POST of the adaptive card)
- On button click, a flow is called, this flow is set to "Anyone in tenant"
- I have a trigger condition as per the documentation on this flow: @equals(triggerOutputs()?['headers']?['Provider-Id'], 'your_actionable_email_provider_id')
- My originator does match the provider ID, in the flow that sends the HTTP POST request and in the flow thats triggered.
 
I cant find any documentation online that delves into detail for power automate, can someone please assist?
Thank you!

AM_Provider_Confi...

Your file is currently under scan for potential threats. Please wait while we review it for any viruses or malicious content.

Categories:

Building flows

I have the same question (0)

All responses (8)

Answers (1)

Sort by

Suggested answer

11manish 1,918 on at

Like (2)

Report
Copy link

Link copied!
The 401 error occurs because Power Automate’s HTTP trigger does not support the Entra-based authentication model required for Actionable Messages.

Even though your configuration is correct, the endpoint cannot validate the token sent by Outlook.

Recommendation

Do NOT call Flow directly from the Adaptive Card

Introduce an Azure Function (or API layer) to handle authentication

Was this reply helpful? Yes No
Suggested answer

Valantis 4,793 on at

Like (2)

Report
Copy link

Link copied!

Hi @stephanbergh,

The 401 is almost certainly caused by the AppIdUri not being correctly configured in your Azure app registration. This step is mandatory for the Entra token validation to work and is the most commonly missed part of this migration.

Here's what Microsoft docs confirm you need to do after creating the app registration:

1. Go to your Azure app registration > Expose an API
2. Under Application ID URI, add the AppIdUri that was auto-generated when you created the provider registration in the Actionable Email Developer Dashboard. It looks like: api://auth-am-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
3. Add a scope under Add a scope (e.g. Global.Test)

Without this, the AM service sends a bearer token that references an audience your app doesn't recognize, and it returns 401.

For Power Automate specifically with "Is this a Power Automate scenario" selected: the flow's HTTP trigger URL becomes the target endpoint.

The AM service will POST to that URL with a bearer token in the Authorization header. Your flow then validates it using the Provider-Id trigger condition you already have. The Authorization header value of `""` in the adaptive card Action.HTTP is correct the AM service injects the actual token, you don't set it manually.

Also confirm: has your tenant admin granted consent in the Actionable Email Developer Dashboard? For tenant-scoped registrations they need to click Approve on the Admin Consent Dashboard. Without admin consent the token validation fails with 401 even if everything else is correct.

Ref: https://learn.microsoft.com/en-us/outlook/actionable-messages/enable-entra-token-for-actionable-messages

Was this reply helpful? Yes No
Suggested answer

stephanbergh 18 on at

Like (1)

Report
Copy link

Link copied!

Hi @Valantis and @11manish :)

Thank you so much for your prompt feedback.

Ah okay, I got confused with the "Is this a power automate scenrio?" question in the AM provider config.

I thought, since it takes away the ability to enter an App reg ID (when selecting Yes), that it handles it for you automatically.

But now I understand that some form of api layer between outlook actionable messages and the flow must exist.

I will set up an app registration and hook it up properly with the AM provider.

And yes, it is approved by our global / exchange admin.

Thank you so much to both of you!

Last one, is there any other documentation on how to make use of a validation layer / api layer, that is not specified in these documentations:
Create an actionable message in Power Automate - Power Automate | Microsoft Learn
Security requirements for actionable messages - Outlook Developer | Microsoft Learn

Enable Microsoft Entra ID token for Actionable Messages - Outlook Developer | Microsoft Learn

Or is this enough to get me on the right track? Just dont want to miss anything, also, sometimes the documentation does confuse me or feel "empty".

Thank you!

Edit: Does this mean that each AM provider needs its own App registration, since APPIDURI will be unique to each AM provider?

Was this reply helpful? Yes No
Verified answer

Valantis 4,793 on at

Like (2)

Report
Copy link

Link copied!

Hi @stephanbergh,

Those three docs are the right ones and cover everything you need. The three docs together give you the full picture.

On the validation/API layer question: you don't need a separate Azure Function or middleware. The validation happens directly in your Power Automate flow.

The AM service sends the bearer token in the `Action-Authorization` header (note: Action-Authorization, not Authorization). You validate it using trigger conditions. The approach from the community is:

1. Add a trigger condition checking the Provider-Id header (which you already have)
2. Optionally decode the JWT from the Action-Authorization header to also validate the appid claim (The AM service always sends appid: 48af08dc-f6d2-435f-b2a7-069abd99c086 for EAT, but for Entra the appid will be your own app registration's client ID)

For the Entra migration specifically, the security requirements doc you linked is the key reference for what claims to validate.

On your last question - yes, each AM provider registration needs its own app registration. The AppIdUri is auto-generated and tied to your specific provider ID. If you have multiple providers (e.g. different adaptive card scenarios with different flows), each one gets a unique AppIdUri and therefore needs its own app registration in Azure. The good news is the app registrations are lightweight you just need the Expose an API config and a scope, no permissions or secrets required.

You're very close to having this working. Once the AppIdUri is wired up you should stop seeing the 401.

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
stephanbergh 18 on at

Like (1)

Report
Copy link

Link copied!

@Valantis I appreciate your help so much.

Thank you thank you!

Have a wonderful day.

Kind regards,

Stephan

Was this reply helpful? Yes No
Valantis 4,793 on at

Like (2)

Report
Copy link

Link copied!

@stephanbergh i am happy that i was able to help man. Thank you and have a nice day too :)

Was this reply helpful? Yes No
BH-18091742-0 6 on at

Like (1)

Report
Copy link

Link copied!

Hi all,

I’m trying to get an Adaptive Card with Approve/Reject actions working via Power Automate using an HTTP trigger and I’m running into a few issues. The card will sometimes render, but then stop rendering after I make provider changes. When it does render, clicking the buttons returns either a 401 or a generic “An error occurred” message. I’ve tried both approaches where I set Power Automate Scenario to Yes with no Entra app, and also No with a full Entra app registration including App ID URI, scope, and authorized client, but the Entra path is now hitting a consent error saying end users cannot grant consent to newly registered multitenant apps without verified publishers. My flow trigger is set to Any user in my tenant and I’m using the api-version=1 URL. I’m unsure if I’m mixing two incompatible setups here. Is the recommended approach still to use Power Automate Scenario set to Yes without Entra, or is Entra now required? Also should the Target URL be the full flow path or just the base domain? I’d appreciate any guidance from someone who has this fully working, and I’d be open to a quick call if anyone is willing.

Was this reply helpful? Yes No
Valantis 4,793 on at

Like (1)

Report
Copy link

Link copied!

Hi create a new question please for people to see and be able to help@BH-18091742-0

Was this reply helpful? Yes No