Domain Separation - Best Practice for MSPs

[Jamsta1912]

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.

[jberk]

A couple of things:

- You will find that working in the global domain will make things easier as an admin of the SN platform. That being said your users that are employees of the MSP should be in a separate domain with the correct contains/visibility relationships with the other domains they manage.

-You should find an option in the context menu and in the related links on most forms to "Expand domain scope". This will allow you to see records in domains outside of the one your user account resides in.

-Remember that the company will set the domain. Try to avoid setting the domain directly and rather let the company designation set what domain the record lands in.

-I would avoid putting things in global wherever possible. The power of domains is the ability to utilize the TOP domain for any wide reaching rules, then you can define alternative versions in the child domains and use the override capability to ensure that the proper rule is being enforced in the child domain.

-Become familiar with the domain picker as you will need to use it often. There was an old SN Guru article about moving the picker into the banner bar and I was able to tweak that to only happen for admins which was helpful.

[Michael Fry1 · Accepted solution]

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.

[jberk]

Michael brings up a good point that I neglected to mention. Make sure you are setting up and understand the difference between process level domains and data level domains.

You can see all the records on a table regardless of domain by going to the module for example, Business Rules, in list view while in the global domain and expanding the domain scope. This should show you all business rules for all domains.

Also, you can set a local password on the user record for any user that is using SAML/LDAP/SSO and then login at the side_door.do URL with those local credentials.

[Jamsta1912]

Hi Joshua, Michael,

Thankyou for this advice.

We're set up in the 'standard' way. We have a TOP domain which is parent to the MSP domain and also to our clients' domains. The MSP domain contains TOP.

If I'm understanding your points correctly, it would make sense for us to make the majority of process updates in TOP, as these would then apply to the children (Unless we override). And this avoids working in Global. So I think it may make sense for system admin user records to be associated with the TOP domain so that by default our business rules, client scripts etc are associated with TOP. And yes, I can see we're going to get used to using the Domain Picker

Jamie.