Nov 29 2018 08:57 AM
Nov 29 2018 08:57 AM
Effective February 1, 2019, the following capabilities will only be available with PowerApps and Flow Plan 1 and Plan 2:
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
Nov 29 2018 09:28 AM
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.
Nov 29 2018 09:50 AM
Nov 29 2018 10:33 AM
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?
Nov 29 2018 10:46 AM
Nov 29 2018 10:49 AM
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.
Nov 29 2018 10:51 AM
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.
Nov 29 2018 10:53 AM
Nov 29 2018 07:14 PM
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.
Dec 05 2018 12:09 AM
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...