Designated App Owner AD Best Practices

[ericonline]

Hello, 

Calling @timl, @wyotim, @Anonymous, @mr-dang, @v-monli-msft, @CarlosFigueira and all PowerAppers. 

I'd like to show our admins the power of the PowerApp community by crowdsourcing some experiences here if possible.

We're doing longetivity planning for PowerApps within our organization and I'd love some community input on the best practices for the following considerations:

• Is anyone utilized AD "service accounts" or the like, for app authoring instead of individual user accounts? 
  • Ex: "powerapps@mycompany.com" vs. "eric@mycompany.com"
  • If so, what are some considerations before embarking?
    • AD Security
    • Account permission issues
    • Connector issues
    • Governance experience, etc.
• Is anyone utilizing different PowerApps environments for specific purposes? 
  • Ex1: Dev, Trial, Prod
  • Ex2: Environment for each department or team
  • If so, what are some considerations before creating these env's?
    • We found one already: On-prem Data Gateway only works in the Default env. 

Your insights are really appreciated!

Thank you

[wyotim]

@ericonline, it is an honor to be called out, especially given the others you mentioned as well. Thanks for that!

Unfortunately, I have little to add as we don't currently use separate environments or service accounts, though the service account idea is on my radar. Full disclosure: the company I work for is pretty small and I am the sole tech/data employee. As such, I have only used my company account to create things in PowerApps as it was just easier to do so. 

That said, I will offer one practice that I have been using in lieu of environments. One way I track what level of access the app is by the color of the app icon. Pretty simple but it is decently effective. For example, our field supervisors get red apps, our office apps are blue, and test apps are yellow. Incidentally, I do a similar thing with our PowerBI reports by using color schemes.

I also have a similar practice to @Anonymous when it comes to publishing apps. I found that things would get a bit funky for our field employees when I would make changes to apps and not publish them. So I started the practice of having parallel test apps where I can develop changes or add features at my leisure and then replace the production versions when things were ready to go out. This gives a bit better version control as well and could make for easily segmented test and production groups if needed.

Great topic and I look forward to learning from what others are doing!

[ericonline]

I definitely respect the answers you've given in the past @wyotim! These are great best practices! I hadn't before thought about the simple method of color coding apps. 

While the iron is hot:

• How have you handled the data sources connected to your "V2", "V3" etc apps? 
• @KickingApps recently shared a method for exporting production Sharepoint lists as templates then importing them in a test list for V2 dev. That was really awesome way of supplying realistic testing data.

[Anonymous]

Hello ericonline mr-dang  and wyotim 

I am actually encountering an issue now that I am working with a service account in addition to my account:

There appears to be an issue when apps are working with caches.. I will need to find out where PowerApps stores its caches, but ever since I am using the service account the LoadData and SaveData functions give me an error.

At first I assumed it is because the cache names are the same in the two apps sitting in my account vs the service account, but even renaming the caches in the service account does not work. The error sais something about the function is expecting a table rather than a value (however this same function has always worked before).

Strangely, the cache functions in apps sitting in MY account also error but when using those apps the cache still works. When using apps sitting on the service account, the cache function does not work.

Any ideas on this?

Carlos Aguilar - I saw your post on offline app capability, perhaps you can comment on this?

[wyotim]

@AnonymousWhile I haven't tried a service account, I have encountered similar issues with caching data that had to do with when and where the caches were being defined.

For my scenario, if I would cut out the code that set up the cache (the SaveData and ClearCollect/Collect functions, etc.), save and close the app, reopen and reinsert the code, it would work until I changed something that related to the cache in some way. Then I would have to repeat the process. 

*edit for spelling*

[wyotim]

@ericonlineI typed up a reply to your follow up questions but it failed to post for some reason. 

My current approach isn't a great practice but it works for now, given our small size and scope. Basically, I connect to production data for everything that is a read-only or reference item. For things that are being written to the data source, I do one of the following depending on the app/scenario:

• export a SQL table to Excel or make a mock-up in Excel to connect to
• write to a collection in the app and verify/validate
• connect to a production table if it is a new, empty table

(Concerning the last bullet, that scenario happens more often in our company than it would in most I imagine. Before I was hired our company ran almost exclusively on paper so I have been developing apps and data sources in tandem at times.)

When I am satisfied with the behavior, I connect it to the production data and ship it out. This approach seems to give the best balance of protecting our data and speed of development. We mainly use Azure SQL DB, Outlook (for automated emails), and some SharePoint (primarily for document access) so it is a fairly simple environment and again, I have a bit more flexibility as the only person handling all of the data and apps.

Honestly though, just typing this (for the first and second time) caused me to really think about how much I need to improve our development pipeline. We don't currently have a dedicated test environment and I have struggled with justifying one for our size/resource level. My goal has been to never let our size dictate our quality of practice and this is one area that I need to build on. I am very interested in the SharePoint exporting method you described for testing data. Thank you for mentioning it! 

[Anonymous]

Hi ericonline and others, 

Adding to the topic of using 'service accounts' to host all organizational apps, another key consideration I have run into is with regards to the number of flows required.. I currently use an O365 E3 license which offers 2000 flows per month, however this will not be enough soon. Option is to purchase a separate Flow Plan 2 that provides 15,000 flows. 

However depending on the size of the organization, even that may be a limitation, especially the more apps you build and the more users start using it. I posted a question on this topic into the flow community, link below. 

https://powerusers.microsoft.com/t5/General-Flow-Discussion/Options-to-increase-monthly-Flow-limit/m...

Cheers 🙂

Daniela

[wyotim]

@AnonymousI have wondered how this would work myself. I am just getting into writing Flows for some of our processes and have used my account to set them up. Now, for our little company 2000 Flows a month may be plenty but I was questioning how other similar connections would work.

Big question: Is there a way to delegate the login for a data connection to the user for some things but not others?

@ericonlineMaybe this is what you were referring to earlier with data connections to test/production apps and I was in the wrong mindset with my response? If so, my response probably showed where I am with that anyway. 

[mr-dang]

Thanks for sharing, everyone. 

You may all be interested in reading more about governance in a whitepaper we released recently:

https://powerapps.microsoft.com/en-us/blog/powerapps-enterprise-deployment-whitepaper/

And new connectors are now available for Admins and Makers of PowerApps and Flow for management of all things 🙂

https://powerapps.microsoft.com/en-us/blog/new-connectors-for-powerapps-and-flow-resources/

What I like most about this topic is that industry newcomers like myself are learning about these top-level best practices we had no concept of previously.