Using update sets with domain separation configaration - best practice?

[akosadravetz]

We are planning to implement a domain separated structure with several domains under the top, each having some unique configurations. Now we are only testing it in a developer environment, using one update set and backing it up regularly.

Normally (in a non-domain separated model) it is enough to export the update set and import it to another instance (e.g. other dev or a non-prod), and it works like a charm, but what about importing an update set from a domain separated structure? What is the best practice to do that? We've just had our first try, but ran into hundreds of errors. Does the update set contain everything about the domain separation? Or do we have to manually configure the hierarchy first before importing the update set?

Thanks for sharing your experiences!

[Deepak Ingale1]

Hi Akos,

When we talk about domain separation, sys_domain and sys_overrides are the fields which are Really important.

sys_domain field points to the sys_id of your domain, which will definitely vary from sandbox you are working on to the actual instance where you want update set to be deposited.

This is not the case working on non-domain separated instances. You will have sys_domain field but its value will always be global rather than 32 bit GUID or sys_id

Your update set entries are the sys_update_xml records which will point to the sys_domain record and hence this is the problem with domain separated instance.

You can follow what George and Michael has pointed to.

[akosadravetz]

Thanks for the feedback, we'll see how it works, and I'll get back to you with the results!

[michalewandowsk]

Hi,

As other community members stated - at first replicate domain structure on all your instances. Domain is considered data, so you have to export domain structure as XML file:

1. Activate domain separation plugin on all your instances

2. Cleanup unneeded domains

3. All domains you created on your DEV environment must be populated to all other instances. This must be done via export/import XML (only in this way sys_ids of domains will be the same everywhere).

4. As you may know - if you want to commit update set on your target instance you have to switch to global domain first (this is quite important)

After doing this you should have environments setup properly to move your update sets containing domain separated items.

But, this is not all. Development in domain separated instances is a bit more complicated. It's not about update sets - it's about target domain of items you customize. Anytime you customize domain separated part of the configuration (form layout, email notification, SLA, application menus/modules etc.) - please ensure you're in correct domain. If for example form layout's domain will be other than yours, system will save copy of an layout in your domain. The same for SLAs, email notifications etc. Golden rule - before you modify anything, think twice what will happen after Submit: check domain of the item being modified, check your domain (don't always believe domain picker if you use several tabs to open one instance).

[Deepak Ingale1]

check domain of the item being modified, check your domain (don't always believe domain picker if you use several tabs to open one instance).

I would give 100 points to this one liner. Dont always rely on domain picker if you have several tabs to open.

We had issue with this in past but fortunately we could discover that in UAT only.

[darpanap]

Hi Michal

Thanks for the helpful suggestion.

But i do have a question on how can i take an xml backup of all my domain structure from Dev instance to Prod.

Should i take xml backup of the domains one-by one of all the domains and then import it to Prod instance one-by-one.???

how can i ensure that the domains sys_ids now match once moved to Prod instance, is there any way that i can check on that because i dont get to see the sys_id details on the domain table of Dev instance.

Regards

Darpana