Domain Separation - Best Practice for MSPs

Jamsta1912 · ‎08-02-2016

Hi everyone,

We're an MSP, and up until now we've been using company separation, but we're now about to migrate to domain separation.

I have a couple of questions related to delegated adminstration. Initially, I think any new business rules, client scripts etc I create when we're using domain separation, will be in the Global domain. But I can see the power and usefulness of being able to write scripts that run only in a particular domain (or a particular domain and its children).

My own user record is associated with the domain associated with the company record representing the MSP. So by default when I log on, I'm working in that MSP domain. So to write a business rule (for instance) in the global domain, I have to either remember to set the domain = global with the domain picker, or else manually set the domain on the business rule record when I create it. If I update my user record to be associated with the global domain, it means I become visible to all our end customer users.

So my first question is: what is the best practice way to default new business rules etc to the global domain, if my own user record as system admin is in the MSP domain, if indeed it is best practice to do that at all?

Second question, given that down the line I think I will want to create business rules, client scripts etc in domains other than the global domain, how do I view all business rules (for example) in one view; ie see all business views across all domains without having to flick between domains using the domain-picker? So basically, as a system admin I want to be able to view all business rules etc at one, regardless of their domain and regardless of my own domain.

Jamie.

Michael Fry1 · ‎08-02-2016

I rarely work in global, thus if I'm changing an out of the box rule, I'm creating an override in the domain I need it to be in. Overrides are something to learn and understand. Add the fields domain & Override to your forms so you can quickly tell which domain the rule applies too and if it's an override.

Since customers are tied to my process domain, that's where many of the changes take place. Most form changes are in TOP. Certainly if you needed to make a rule in customer domain, you could do that from higher domain or in customer domain.

If you leave global alone, I could spin a new customer process domain off of global, and their domain under that, and they would get out of the box functionality.

I also created a .local account for myself just in case something happens with LDAP/SSO. What if the server crashed and they built one with new name, etc. I can log in with .local account to make the changes and restore authentication.

While it might be nice to see all rules for the system, regardless of domain, I don't think that's possible unfortunately unless there are no overrides.

View solution in original post

Michael Fry1 · ‎08-03-2016

Agree . . . though you will have to switch to global to Preview & Load update sets.

Jamsta1912 · ‎08-03-2016

Great, thanks again Michael.