Query on Data visibility in Domain separation

[Suggy]

Hello,

I have  a query on Data visibility in Domain separated instance.

Below is the domain map 

Cloud Ops domain has no visibility to any of the above parent domains.

I have written a BR in TOP domain like below (triggers upon each update for testing purpose)

var gr = new GlideRecord('incident');
gr.initialize();
gr.short_description = '123';
gr.caller_id = '5a7ed4341f1310005a3637b8ec8b7092'; //user from Initech domain
gr.company = 'c94cf9c54a36231201e14142cf24f5ee'; //sys_id of Initech company
gr.sys_domain = 'c94122494a362312007f2ce5bd78768f'; //sys_id of Initech domain
gr.insert();

As per the process flow, above BR will be applicable and runs in 'Cloud Ops' domain as well.

What I did is, I logged into 'Cloud Ops' domain as 'Test cloud user' and udpated an incident which triggered the above BR and then an incident for created in 'Initech' domain.

So for the newly created incident, the created by/opened by is 'Test cloud user' and the company and doamin of that incident is 'Initech'.

Question - the 'Test cloud user' user does not have visibility to 'initech' domain. but just by triggering the business rule, (here the BR ran as 'Test cloud user' user) and it created the incident with caller from 'Initech' domain.

In UI, 'Test cloud user' cannot see data elements from 'Initech' domain , but via script, 'Test cloud user' created the incident with data from 'Initech' domain.

Is that expected behavior in Domain separated environment?

[Ryan Duce]

Yes, it's expected behaviour. As is often the case in ServiceNow, just because you can do something doesn't mean you should. Hard-coding sys ids in any business rule is a bad idea, especially if they reference data in other domains that the user can't see, and in most processes on a domain-separated instance you'd want to use something scalable like gs.getUser().getCompanyID() to fetch the right company sys id based on the logged-in user.

Also in terms of user experience the above would be jarring, because the user would create the record, and then it would be immediately invisible to them. UX like this is the responsibility of the implementer to resolve.

In addition to dom-sep not restricting create operations, it's worth noting that until a new record is committed to the database, the domain of the record defaults to the domain that the user is currently in because domain-setting business rules haven't run yet. A very frequent gotcha in every domain-separation project I've been a part of.

[Suggy]

Hi @Ryan Duce I absolutely agree that we should not hardcode the sys_ids.

Infact to tell you, our scenario is totally different. We are using a custom application which requires a record to be created in parent domain by a user in child domain automatically under certain conditions.

As its a custom solution/application, I did not want to share all the details and just simulated the scenario by considering Incident mangement.

This solution was already developed before I joined the project. My current role is to clean up the instance WRT all the flaws/issues/bad scripting etc and I came across this scenario.

I always thought a user from child domain, who does not have visibility to parent domain can never CREATE/READ the records in parent domain by what ever means it is.

But I see that through scripts, it is possible to do so, which is a very big surpise to me.

[KevinBellardine]

Even with a sys id you wouldn't be able to read, script or no. But technically yes, you can create them.

[Suggy]

Hi Kevin, With sys_id, I am able to read and do the queries.