cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
KMac1980
Level: Powered On

Apps & Flows getting built that go against DLP

So, we implemented a DLP policy in the Power App/Automate Admin center to prevent most 3rd party connectors AND to prevent ALL premium connectors. Normally, when a Flow was created that went against the policy it would suspend, and the apps just would work. PERFECT! However, we have a user that was able to create a Power App using CDS & SQL Server connections. His app looks great unfortunately, so I felt really bad going to him and telling him that he can't use it. He also built a Flow from the Power App that uses the SQL Server connection as well and it is running like normal and didn't suspend. 

 

Has anyone experienced this recently? We haven't had an issue until this month. 

 

I am planning on putting in a ticket, but wanted to see if I was losing my marbles or something before I waste Microsoft's time.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Yocomd
Level: Powered On

Re: Apps & Flows getting built that go against DLP

Right - you cannot completely block connectors, so if CDS or SQL connectors are in the non-business data group, they can still use them as long as the flow/app doesn't also use a connector from the business data group.

 

Our current contract has not yet expired, so I haven't experienced the new licensing and I've been reading conflicting messages, but my understanding (and someone can correct me if I'm wrong) is that per app licenses are not associated with a person or an app, but rather are pooled at the tenant level and Microsoft will do some magic calculations to determine how many standalone licenses you need based on how many apps are shared.  I'm under the impression that there will eventually be reporting that will tell us if we need to purchase more standalone licenses, so you wouldn't have to wait until true-up.  Hopefully that reporting will make it easy to determine which apps are using the licenses for charging back, if necessary.

 

We did have a huge concern about people creating model-driven apps in the default environment.  We didn't want hundreds of different makers each modifying the CDS with no knowledge of the others.  We did find that if you remove the Environment Maker role from each user in the default environment it doesn't remove the ability to create Canvas apps/flows in the default environment, but it does remove the ability to create model-driven apps from that environment.  Possibly also removing the CDS User role would prevent them from accessing the CDS from a Canvas apps in the default environment.  That could, at least, help you prevent random CDS connections?  (Note: the default environment works differently from other environments in relation to the Environment Maker role).

View solution in original post

5 REPLIES 5
v-siky-msft
Level 10

Re: Apps & Flows getting built that go against DLP

Hi @KMac1980 ,

 

Can you share more with your scenario? Do you apply DLP to all or selected environments? In which environment was that App created?

If the App is in the proper environment that have be applied DLP policy, and still can be able to use connector in 'No business data allowed' group, that must be something wrong.

Can you re-create a new DLP policy to see if the policy works for him?

Best regards,

Sik

Yocomd
Level: Powered On

Re: Apps & Flows getting built that go against DLP

Perhaps I'm misunderstanding your examples, but DLP policies don't block connectors from being used completely, they just disallow connectors in one group (business data) from being used in the same Flow as a connector in the other group (non-business data). So it would be entirely possible to create a Flow with one or more connectors in your non-business data group as long as it doesn't also have a business data connector.
KMac1980
Level: Powered On

Re: Apps & Flows getting built that go against DLP

The DLP applies to the default environment, no other environments are shared with other associates except our collaboration team.

 

The app and Flows were created in the default environment which has the DLP policy applied to it.

 

I have moved and resaved the DLP to see if that would help. He seems to be the only user who has been able to do this.

KMac1980
Level: Powered On

Re: Apps & Flows getting built that go against DLP

@Yocomd so nothing can prevent them from using SQL and CDS then? We will just be dinged when it's time for true-up? 

 

I guess I misunderstood it 😞

 

Is there not any way to completely block these premium connectors?

 

Highlighted
Yocomd
Level: Powered On

Re: Apps & Flows getting built that go against DLP

Right - you cannot completely block connectors, so if CDS or SQL connectors are in the non-business data group, they can still use them as long as the flow/app doesn't also use a connector from the business data group.

 

Our current contract has not yet expired, so I haven't experienced the new licensing and I've been reading conflicting messages, but my understanding (and someone can correct me if I'm wrong) is that per app licenses are not associated with a person or an app, but rather are pooled at the tenant level and Microsoft will do some magic calculations to determine how many standalone licenses you need based on how many apps are shared.  I'm under the impression that there will eventually be reporting that will tell us if we need to purchase more standalone licenses, so you wouldn't have to wait until true-up.  Hopefully that reporting will make it easy to determine which apps are using the licenses for charging back, if necessary.

 

We did have a huge concern about people creating model-driven apps in the default environment.  We didn't want hundreds of different makers each modifying the CDS with no knowledge of the others.  We did find that if you remove the Environment Maker role from each user in the default environment it doesn't remove the ability to create Canvas apps/flows in the default environment, but it does remove the ability to create model-driven apps from that environment.  Possibly also removing the CDS User role would prevent them from accessing the CDS from a Canvas apps in the default environment.  That could, at least, help you prevent random CDS connections?  (Note: the default environment works differently from other environments in relation to the Environment Maker role).

View solution in original post

Helpful resources

Announcements
thirdimage

Power Apps Super User Class of 2020

Check it out!

thirdimage

Power Apps Community User Group Member Badge

Fill out a quick form to claim your user group badge now!

sixthImage

Power Platform World Tour

Find out where you can attend!

Power Platform 2019 release wave 2 plan

Power Platform 2019 release wave 2 plan

Features releasing from October 2019 through March 2020

SecondImage

Difinity Conference

The largest Power BI, Power Platform, and Data conference in New Zealand

Top Kudoed Authors (Last 30 Days)
Users online (4,668)