Way to tell what tables can be domain separated?

[jhelebrant]

Hey all,

We're working on standing up our ServiceNow instance and are using Domain Separation. On the wiki, it states that starting with Fuji, the following tables are restricted from DS:

• Access Control [sys_security_acl]
• Script Include [sys_script_include]
• System Property [sys_properties]
• Security Black/Whitelist Entities [sys_security_restricted_list]
• Dictionary Entry [sys_dictionary]  
• Dictionary Entry Override [sys_dictionary_override]

Does that mean that every other table can be? Is there a way in the tool to determine if a table is domain separated? When we roll out different modules of SNOW, we'd like to ensure that specific client information can't be seen by others. Thanks!

[coryseering]

Hi John,

Pretty much any table can be domain separated, but (as you noted) some tables shouldn't be. The list you pasted (and which is reiterated in the Domain Separation wiki) are the tables which can severely break instance functionality if you force domain separation.

You add Domain Separation to a table by adding the sys_domain field. This is also pointed out int he wiki. Any table which has a sys_domain field (or who's parent int he extension model chain has a sys_domain field) is domain-separated. For instance, Incident, Change Request, and Problem are domain-separated because their common parent, Task, has the sys_domain field (when the plugin is activated).

If you have a custom table that you want to be domain-separated, add the sys_domain field to the table.

When dealing with Domain Separation, always always always test in a non-production instance first. You can't really deactivate the Domain Separation plugin, so you want to make sure that you know what you are doing when you roll it out to Production. You do that by validating on non-production instances first. If you want to experiment with adding domain separation to additional tables, do it first in a non-production setting and test the heck out of it to make sure you are getting the results you want.

Domain Separation is a very powerful tool for managing record access. That power comes at a cost- you need to understand the scope of your changes when you modify domains, add domain separation to tables, and so forth- or else you might make your instance very user-unfriendly.

[Deepak Ingale1]

Thumb rule

Do not domain separate the tables which are not domain separated by plugin itself.

In addition to tables you have mentioned catalog items are not domain separated

Those are controlled by user criteria in Fuji and entitlement fislds in Eureka.

sys_domain filed on table will indicate that table is domain separated for records.

sys_overrides field along with sys_domain field on table will indicate that table is intended for process separation. business rule and client script tables are the example of process separation table.

[jhelebrant]

Hey guys,

Thanks for your responses. I'm hearing two different things though. One of you says to add the sys_domain field to a table we want domain separated, and the other says not to domain separate tables which are not separated by the plugin itself.

We are currently looking into rolling out the Asset Management piece, but it's crucial that the forms and records associated with Asset can be domain separated. Again, thanks a lot for your assistance.

[coryseering]

Hi John,

I am telling you what is possible. Deepak is explaining Best Practices. You can domain-separate tables which aren't separated by default when the plugin is activated. If you decide to do so, you need to test your changes very thoroughly to ensure you maintain functionality.

I am not familiar with the specifics of the Asset Management plugin, but you may find that it is already properly domain-separated when the plugin is activated. If it isn't and you have "Domain Separation of Asset Management" as a requirement, then you can add it as described previously.