Unanswered

Multi-customer or multi-partner solutions

(0) Share

Report

Posted on by mhomol

122

We have a solution that is hoping to implement what might have traditionally been called a multi-tenant or multi-customer solution. In this particular situation, they are referred to as partners. These partners have their own unique data for all of our master tables. In other words, if I had a people table where email was a unique field - it could be found multiple times associated to each partner. This would be true for any object in the hierarchy, regardless of how they all related to each other.

We originally were thinking of using a unique environment for each partner, but what they are hoping to achieve is ability to manage data across these partners within a single environment.

This feels like it needs to be a pervasive table that sits atop all other objects. It would be referenced as a Lookup from each table and should also be used as a combo key for records and the other alternate unique keys. Am I correct in this assumption? I've got database design skills, but this one is on a next level for me.

Is this essentially what business units are doing for us and should I immediately be thinking of how best to leverage business units in this way? I think of business units as strictly related to security. While its true that we may need also display only 1 partner-worth of data based on the role of the user, there are also situations where users will have a role that should allow them to traverse different partners and hopefully keep as much of that partner context as they are using the model-driven app.

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (2)

Answers (0)

cchannon 4,702 Moderator on at

Like (0)

Report
Yeah, it would be easy to overengineer this, but you've already hit on the straightforward answer, which is to implement a mature, well-planned security model, including BUs. Let me elaborate on a few of the capabilities of BU security that will be helpful here:

BUs have a hierarchy of their own. So, the fact that a user in BU A cannot see data from BU B and vice versa doesn't preclude a user in BU C (parent to A and B) from seeing both.

BU membership is not the only way to get access to the BU's records. Although a user will only be a member of one BU, they can be a member of an arbitrary number of teams, and those teams can be members of any BU.

And teams are only one workaround for this: you can also let exception cases get around BU walls with Access Teams, record sharing, and retained ownership

Role assignment is scoped by BU, so even where a user has access to records in a BU other than their own, they will only have access according to the roles they were assigned for that BU, so they don't necessarily have the same access they would in their 'home' BU.

The problem you will have here is that idea of uniqueness within a 'partner' but not across partners. A primary key is a primary key, and there's no security scope to it. If you want true uniqueness of a record to be based on email for example, then that cuts across the entire environment without exception. However, you can have semi-uniqueness by creating Duplicate Detection Rules, and those rules can respect the boundaries of BUs. Downside here: Dupe Detection requires human review and resolution (the UX with these isn't great) or else some very careful code (I actually just the other day stumbled on an old blog post by @a33ik about a coded approach to record merge here - should still be relatively close to recommended practice, although it was from the 8.2 API).

Was this reply helpful? Yes No
mhomol 122 on at

Like (0)

Report

@cchannon ,

I can't thank you enough for your reply. I know this is getting into complex territory and it took me forever to even think about how to describe my problem. I had started to think I just wasn't going to get a response on this one. And yes, I'm very worried about overengineering this one.

I haven't had an opportunity yet to review the links you posted but intend to tonight.

I have been going down a path of trying to treat the business unit as the home for partners, using the vernacular of our customer. In the context of visibility and security and leveraging the buiness unit heirarchy, I think I'm all good or at least I'm understanding how to leverage it. However, in the context of leveraging it as a critical component to the overall structure of the database, I have concerns based on what I've tested out so far.

When an owner of a record is changed, it automatically changes the owning business unit. So it seems like I can’t untether those 2 fields from each other. This makes business units much more of an entity strictly related to visibility and security, not actual data hierarchy, in my mind so far.

Is this behavior you're familiar with and is it something that can be changed or is it core to the functionality?

In my mind, this means I would definitely HAVE to have a central table that relates to everything. Would you tend to agree with that? Is this a structure you’ve tried to achieve before? I’m curious if it would be best to simply have it as a referential field to every table, in order to keep the hierarchy to a minimum, or if I should try to have it as a parental reference to all of my core tables? Again, please set me straight if you see flaws in my logic, as I really want to keep this as simple as possible.

Was this reply helpful? Yes No