HTTP Custom Action in SharePoint and OneDrive

[Paul Hunt - Cimares]

I've just seen @Chris McNulty's blog post around the licensing changes coming to Flow in Feb 2019 and am a little confused by one of the statements in the post.

Effective February 1, 2019, the following capabilities will only be available with PowerApps and Flow Plan 1 and Plan 2:

• Creation and publication of custom connectors in PowerApps and Microsoft Flow
• HTTP custom actions integrated into Flow outside SharePoint and OneDrive
• Integration of on-premises data through the on-premises  data gateway

Does this mean that if I author a Flow that is triggered from/by a SharePoint library by clicking the flow link in the library, then the HTTP Custom Action is available to call any webservices (including my own Azure functions) or is it just the HTTP request into SharePoint that will be available to use SharePoint REST services?

Tagging @Jon Levesque

[#2]

I'm pretty sure that is not the case.  I believe the specific call out for SharePoint and OneDrive is because there is a native action called "Send an HTTP request to SharePoint".  This action is NOT going to require P1/P2 licensing but the generic HTTP action will require additional licensing from what I understand.

[#3]

Yes, Brian is correct, the Http stand alone connector is going to turn premium. They did state however that you only need to be licensed for the flow creator and anyone using the flow itself doesn't need to be licensed so that's a relief cause if anyone using it needed P1 that would frustrating :).

[#4]

I guess I'd have liked to see greater clarity in the original blog post around that point, perhaps by calling the action out by name. I know there's a lot of clients using flow today that have fallen back on the HTTP Custom Action for SharePoint to call an PowerShell code in an Azure Function specifically to address areas that Flow was/isn't able to do.

To do this going forward we'll need to ensure those people creating the Flow have the P1, so not a major problem but clients will ask why are we being charged for this now?

[#5]

The SharePoint HTTP custom action isn't part of the P1 requirement.

[#6]

For Azure Functions you should look at using a queue trigger instead of an HTTP trigger as that works without the HTTP action, and using Azure Automation actions for PowerShell anyway

[#7]

yeah I meant the HTTP Custom Action within a SharePoint Flow to call a function that resides in Azure, so it requires the "HTTP Custom Action" not the SP version of the same.

And I'm not sure that the whole Author/Run statements we're seeing on Twitter is correct. I've seen conflicting information now where one statement says that P1 is required to both Author and RUN the flows.

[#8]

Fair point and an approach I'd use now to create separation. A lot of early samples were showing the use of the HTTP Custom Action to trigger the functions.

[#9]

Gotcha on the HTTP Action, what probably will happen is that one will be marked as premium and the one that actually has the SharePoint badge will not.

As far as the flow, it seems that way too because when you run a flow to accept the connectors or user your user context for them etc. you would think at that point it would check if your are P1 or not. Guess we will see more clarification on this soon.

[#10]

This seems a little bit of a stretch in my opinion for a basic function.  Especially when we already make significant investments in higher tiered licensing packages like E5.  I'm all for monetizing services, but it just seems like there are better ways to distinguish Flow services and capabilities. 

I've been working to kill a 3rd party that provides similar capabilities, but this just wiped that out.  To give the same capabilities (just a silly HTTP call for workflows) to our users would cause us to quadruple the investment that we are making in our 3rd party tool.  Or maybe I'll dust off some SPD2013 capabilities for a while when this goes into effect.

I'd rather see it take on something like an Azure Function type model where you pay for what you use other than forcing users to pay for a "Cable" model of 100's of "premium" channels that you'll never watch when you only really want the one channel.

Also, you kinda already did a good job of "distinguishing" between services if you look at your pricing page https://flow.microsoft.com/en-us/pricing/

Dont get greedy.

[#11]

Hi,

I asked the question if all users need a paying license if we are using this functionality. And the answer is YES, all users in the O365 subscription need to be in the same plan. So, ready to calculate what the cost is, and compare this to third party products that were rejected first before this was changed.

Answer I received is here https://powerusers.microsoft.com/t5/General-Flow-Discussion/Flow-licensing-question/m-p/188199#M1822...

Marc

[#12]

Have you tried Azure Logic Apps?