Domain Separation - Issue when quering the domain-table

[Fabian Kunzke]

Hello,

I found a weird behavior, where i cannot get a query onto the domain table to work. I reduced it to the code down below. The sys_id within the domain.get(); is the sys_id of a domain record. But insted of actually finding the record, the output is always "ain't found shit". Therefore, the glide Record seems not to return anything, despite a matching record existing.

	var domain = new GlideRecord('domain');
	if(domain.get('c1bfa49b4f98db00f11329001310c7c7'))
		{
		gs.info('found domain ' + domain.name);
		return domain.getUniqueValue();
	}
	gs.info('ain\'t found shit');

Now i have checked the acls and on query rules. It seems as if there is nothing in the way to prevent this. Also, just using the following line of code, a domain record is found.

	var domain = new GlideRecord('domain');
	domain.query();
        if(domain.next())
		{
		gs.info('found domain ' + domain.name);
		return domain.getUniqueValue();
	}
	gs.info('ain\'t found shit');

The reason why i am trying to use a glide record here is, because i do not like to hardcode any IDs. But at the moment i am out of outs. The line of code is performed within the highest domain scope (global).

Has anybody seen this behavior before?

Greetings

Fabian

[Gurpreet07]

It's explained here

https://docs.servicenow.com/bundle/jakarta-application-development/page/app-store/dev_portal/API_reference/GlideRecord/concept/c_GlideRecordAPI.html

[Fabian Kunzke]

Hello,

Thanks for the headsup. It does not answer my original issue, but that is indeed neat. Although i still do not understand the use case, where this function would be needed.

Greetings

Fabian

[mak1A4]

As far as I understand GlideRecord will only query the data from the domain of the active user session, so if you need access to data across all domains you can use queryNoDomain(). But I didn't have to use it (till) yet.

[Fabian Kunzke]

Hello,

Yes, thats what i expected of the function itself. But i think, that the only applicaple scenario would be an interface or a scheduled script since none of these are bound to an active user session.

Then again i would prefer to use a user in that case, which is properly setup via the user domain visibilty since it allows to change the general behaivior based on the executing user.

Greetings

Fabian

[Fabian Kunzke · Accepted solution]

Hello,

I have indeed found the reason to why this is not working. The visibility of the domainstructure does not allow a user to query the domain table in this context/way. Indeed it has to be ensured, that the user who is used to execute such query (in this case the user triggering the update of the record) can "see" the domain queried. This results in the following workaround:

The user used for this function call has to be granted visibilty access to the highest domain.

Therefore users used for interfaces or scheduled jobs have to be granted that visibilty.

Seems obivous, but i missed it. This originates cause a domain record itself is assigned to the same domain it is representing. Thus it behaves as any other domainseperated record. Therefore, the code infact is not incorrect, but rather the visiblity setting for the executing user.

tl:dr: When using domainseparation, the current domain scope of the user does not seem to matter. Instead the user domain visibility set within the domain-related-list on the domain record is checked.

Greetings

Fabian