Power Platform Community Forum Thread Details

I'm relatively new to the Power Platform and I'm looking for some guidance on the best practice for model driven Power Apps and whether they should share the same Dataverse?

If I was developing an application outside of the Power Platform, the app would have its own dedicated database and would most likely expose a REST API to allow other applications to share data. I would also discourage allowing another application read/write to the database directly as this bypasses all of the business logic.

Do these same principles apply when developing Power Apps, or is it expected that there will be multiple Power Apps all sharing the same Dataverse and entities? Take this a step further and add Dynamics 365 to mix, and have a bespoke Power App which is creating records in the Account entity sharing the same Dataverse as Dynamics 365 Sales - Is this a good idea or a recipe for disaster?

Categories:

Microsoft Dataverse with Power Apps

Well, I'll give you the obvious (if not very helpful) answer, which is "it depends."

You have to weigh your pros and cons here and the specifics of what each app is trying to accomplish must factor in.

In favor of multiple Dbs:

No devs stepping on each other. If you have multiple teams running in parallel, there is no way they can break each other if they aren't working in the same db.
Easy to accommodate quirky business unit rules. The Accounting team only ever calls the payment account an account, but the sales team only ever calls the customer the account. in a single Db this is doable, but can be a real headache when it comes up for the 10,000th time. in separate Dbs, you never need to care about these distinctions.
Governance headaches. Getting all the kids to play nicely in the same sandbox can be a pain. If you have enough players involved, you might need a governance body that sets standards and enforces them. This can be a lot of overhead.

In favor of single Db:

No unnecessary integrations. Sure, just exposing an API is easy and should be easy for people to work with, but why do it at all if you don't really need to.
Business logic should be there anyway. Dataverse development allows you to enforce business logic at the table level through Plugins, so you CAN force business logic on other apps hitting your Db, even if they aren't using a specific entry point to get there.
Storage efficiency. a raw installed Dataverse installation with zero data already takes up over 2Gb of storage. Replicating key tables like Contacts and Accounts across all apps exacerbates this. This might matter to you if you're running on slim storage margins and thinking about a lot of apps (or it might not).
Avoid data synchronization issues. If you need to integrate many apps, you'll have to distinguish between the data that needs to be constantly in sync and the stuff that can wait. Both of those can be a real headache when you start needing to deal with reconciliation (App A updated Contact B's Phone number, but App C doesn't consider that change authoritative and App D Does. What do we do now?)

Personally, I will say that it would take one heck of an extreme circumstance to swing me toward isolated apps. The headache of synchronizing data is just too overwhelming and from a governance perspective once you hand out the keys to business units to build their own stuff, it's really hard to put that Genie back in the bottle. If you've been at this a really long time, like I have, you've probably seen a Lotus Notes disaster or two. LN was the original 'citizen developer' tooling and the orgs that really dove into it find themselves still saddled with it today because they have hundreds--maybe thousands--of apps all across the enterprise and absolutely no clue how to kill them off.