Licensing change / HTTP custom action

[Interlock]

I understand from this blog post that from February 1st, 2019, it'll be necessary to have PowerApps and Flow P1 or P2 license in order to use "HTTP custom actions integrated into Flow outside SharePoint and OneDrive".

I'm assuming that this means that in most circumstances it'll be necessary to have a P1 or P2 license in order to use the Action called "HTTP" (which has a lime green icon in Flow).

What I really need to know, is whether this licensing change also affects the "When a HTTP request is received" Trigger.  Clearly this is a Trigger rather than an Action, so to me this suggests that this Trigger will continue to be available to users with Office 365 licenses, without the need to add a P1/P2 license.  Can someone please give me a definitive answer on whether my understanding is correct?

[v-bacao-msft · Accepted solution]

Hi @Interlock,

There is a mention in the blog : ” capabilities will only be available with PowerApps and Flow Plan 1 and Plan 2--HTTP custom actions integrated into Flow outside SharePoint and OneDrive”

According to my understanding, the HTTP action should be still available to use, but if those HTTP actions has not been used with the source outside of SharePoint and OneDrive before, then it should be not available to use it with that purpose.

As for "When a HTTP request is received", there should be no similar restrictions.

The restriction here should be mostly focused on the data and the corresponding API access.

Best Regards,

[Interlock]

Great - I wanted to be absolutely sure as this affects a customer's purchasing decision.  Thanks for getting back to me.

[crf200]

I've got a message card posted to teams channel thru the HTTP Action. I'm trying to get the card to ActionHTTP Post back to a Flow Trigger {When a HTTP Post is received} - I get an error in Teams saying Action unauthorized.

Is this because of the licensing change?

I used a cURL to test and got this:

• {"error":{"code":"DirectApiAuthorizationRequired","message":"The request must be authenticated only by Shared Access scheme."}}'sp' is not recognized as an internal or external command,
  operable program or batch file.
  'sv' is not recognized as an internal or external command,
  operable program or batch file.
  'sig' is not recognized as an internal or external command,
  operable program or batch file.

[LozzieD]

Since Flow runs in the context of the author of the Flow, not the runner of the Flow, is it only the author of the Flow that needs the P1 licence if the Flow has an HTTP action in it, not the runner of the Flow?

Or does the runner of the Flow need a P1 as well even though the Flow is not running in the runner's context but rather in the context of the author of the Flow?

[LozzieD]

Also, if the Flow – we’ll call it A - that has the HTTP request action that calls a web service "out there" is authored by a P1 user, but then the runner user actually runs another Flow – we’ll call it B – also authored by the P1 user, and Flow B  calls Flow A (Flow A has an HTTP response trigger which doesn't attract a P1), how will Microsoft trace the chain of P1 authored Flows back to the non-P1 runner who initiated it all?

[hayden]

@LozzieD did you ever get an answer to this question, we have a couple flows triggered by an HTTP request but as it is running in the context of a service account I would assume only the service account needs the additional license

[LozD]

@hayden  Not sure, I'm afraid.  The subscription licensing changed again October 1st 2019 with the per user and per app Plans and all the P1 and P2 connectors going in there leaving the Office 365 Plans with just the SharePoint and OneDrive connectors.  I've no idea where the HTTP trigger responses and HTTP action requests fit now.  Nor did I get an answer as to how it was before.

It's now so sickeningly complex I don't bother trying to understand it anymore.  My approach is: as each requirement comes up I do a "hello world" type prototype of the solution, with just the use cases of connectors and HTTP triggers and actions needed for a test end user and developer logon.  Then see what works or what squeals for a licence and feedback the result to management.  I would never dare *infer* a logical deduction from the licensing documentation these days.  You never know when something like "the moon's in line with the sun, it's your birthday, your favourite colour, divided by the number you first thought of ..." means boom! - every end user needs a PowerApps / PowerAutomate Plan rather than their Office 365 Plan when you thought otherwise and you're shafted.

Sorry I can't be of more help.

[BillSull]

Based on Microsoft's response HERE, I think everyone who uses it needs a license no matter if its running as a service account. 

"Do users who run flows need to be licensed, or do only users who create flows need to be licensed?

Any end user running a flow will need to be licensed either by the per user or per Power Automate plans."