Is this considered "multiplexing?"

[jake]

I am having a hard time determining whether this scenario is considered multiplexing, or if it falls within the standards of acceptable use. Can anyone well-versed in Flow licensing please shed some light on this for me?

Context:

A business group wants to run a mobile-ready approval workflow on certain business documents.

Requirements:

After documents are approved, they must be stored on-premise in a secure, read-only location.

Functionally, this works quite well. Before we can consider this as a development pattern, we need to know if this will result in our organization getting hit with true-up licensing costs at the end of each contract year.

[Brad_Groux]

Per your design, it looks like you'd need a Flow license for the designer of the Flow, and a SharePoint and Flow license for the users accessing the Approval Flow through SharePoint.

This is within standard licensing for most of the Business and Enterprise Office 365 SKUs, as both Flow and SharePoint licenses are included with those SKUs.

So, if all of your users have an Office 365 license, it covers both of these scenarios fully. Assuming of course that you are also properly licensed for your on-premise SharePoint 2016 environment. 

If this reply has answered your question or solved your issue, please mark this question as answered. Answered questions helps users in the future who may have the same issue or question quickly find a resolution via search. If you liked my response, please consider giving it a thumbs up. THANKS!

[jake]

Thanks @Brad_Groux for the quick reply.

All of our users are E5 licensed for SPO and SP2016 on-prem, and would use their Microsoft Flow for Office 365 license for the primary Flow in this example.

The single admin account handling the on-prem storage of the documents over DMG would be operating w/ a Flow Plan 1 license.

That is the rub - everyone is licensed, but it's a blended approach. What I'm trying to determine, is that a valid use of the Flow platform? I think it is, but we are gunshy about getting hit with massive true-up costs if we make this a development pattern without understanding the multiplexing clauses baked into the licensing guide.

[Brad_Groux · Accepted solution]

Yes, it is allowed to have a blended approach - that's the reason the SharePoint connector can connect to both an on-premise farm or SharePoint Online. I use Flows on both that also traverse both as well. 

Mutliplexing is more about stopping people from using Flow, without most of their users having Office 365 licenses. Basically they could license 1-2 admins, and get all of the benefits of Flow and SharePoint using their private SharePoint environment.

Every Office 365 license includes a Flow and SharePoint Online license. You're good.

If this reply has answered your question or solved your issue, please mark this question as answered. Answered questions helps users in the future who may have the same issue or question quickly find a resolution via search. If you liked my response, please consider giving it a thumbs up. THANKS!

[jake]

Bad news. Decided to run this by our Microsoft support rep before we put this idea into practice:

@Brad_Groux - FYI

This stinks.

It seems unreasonable to me that we should have to pay a monthly licensing fee (in addition to the existing E5) for every Flow user just to internalize our company data/documents and archive them on-premise.

[Brad_Groux]

---

@jake wrote:

Bad news. Decided to run this by our Microsoft support rep before we put this idea into practice:

@Brad_Groux - FYI

This stinks.

It seems unreasonable to me that we should have to pay a monthly licensing fee (in addition to the existing E5) for every Flow user just to internalize our company data/documents and archive them on-premise.

---

Thanks for the update, @jake.

Are you certain the rep passed on the fact that you also had E5 licenses? In the many meetings I've had with Microsoft about PowerApps for my company and our customers, at no point have I ever been told that working with or accessing on-premise systems requires additional licensing, SharePoint or otherwise - with the exception of Dynamics.

Flow allows you to connect to hundreds of services that reside outside of Office 365 at no additional licensing cost, so why would an on-premise SharePoint be any different? Not to mention, that you are already paying for those SharePoint on-premise licensing costs at both the server and user level. 

I've worked at Microsoft as a Platforms PFE, and even then if I asked 10 people about licensing I'd get 10 different answers. This doesn't make sense to me, so I'd continue to press for more clarification from others at Microsoft. In fact, this is an area where I would be willing to fight it.

Also, one thing I've definitely found out is that the product groups are not the right people to ask about licensing - licensing is determined at the business and legal levels. The truly baffling area to me is that your on-premise access is could done via REST/HTTP - so why in the world would that be licensed? It's a standard API request. 

I'm a bit of "I stand on principle" guy, so this is one of the times I'd be willing to challenge one of the most powerful companies in the world - because if it is as they told you it is, that's BS. I'd make a huge issue online about it online, and if they stood their ground I'd make sure that they'd have a PR nightmare. 

If they then stood their ground, I'd just build my own custom API to the on-premise SharePoint using Postman and calling that from Flow, and kindly telling them to kiss my ass. Sorry for the rambling, this is just infurating to me. 

[jake]

It's a bit maddening here as well, so no need to apologize for the rant. I'm with you.

"If they then stood their ground, I'd just build my own custom API to the on-premise SharePoint using Postman and calling that from Flow, and kindly telling them to kiss my ass."

Got a good laugh out of this one! (not the suggestion, but the phrasing)

[jake]

@Stephen since I quoted you via screencap earlier in this thread, I figured I'd @ mention you to make you aware, and also to give you a chance to respond.

I agree with Brad - we're already paying for SP2013 + SP2016 on-prem, company-wide, and have E5 licenses for all employees for O365 and SPO work. It's unreasonable (or outrageous, even) to have to pay an additional $5-7 per user, per month, just to have the ability to have those two platforms integrate.

[Stephen]

Hello - use of an On-premises Gateway or a Custom Connector requires a Microsoft Flow Plan 1 (at a minimum), as called out here: https://techcommunity.microsoft.com/t5/Office-Retirement-Blog/UPDATED-Updates-to-Microsoft-Flow-and-... 

SharePoint on-prem or E5 does not contain the full set of Flow or PowerApps capabilities. We do include some basic, limited, workflow and process automation capabilities for free with various Office 365 plans (up through E5), but ultimately, the full power of Flow or PowerApps requires an organization to purchase one of the Flow or PowerApps plans for its users. I hope this clears up the confusion. 

[fugixi]

Even though this is an old post, I'll reply here in case someone else will find it useful, since I still see this discussion coming up in my day to day work.

To get around the licensing issue in a case like this would be to have the Utility flow part to not run as a Power Automate flow, but rather as a Logic App in Azure.

The licensing model for Logic Apps does not have the concept of standard vs premium licenses, but rather a straight up consumption based licensing model (they still use the concept of built-in, standard and premium connectors just like Power Automate does, but for Logic Apps this will just determine the cost per action in your flow). Just make sure to calculate the number of actions within your flow to determine your monthly cost so you then can compare that with the monthly licensing of Power Automate (you can use the Azure calculator here: https://azure.microsoft.com/en-us/pricing/calculator/)

If you have already built your flow within Power Automate, you can export it as a .json file, which you can then import as a Logic App in Azure.