Catalog UI policies and Domain separation

[Simon Christens]

Hi Community

I really hope theres a Domain guru out there who can help me.

Im working in a domain separation environment and im working on "Request nr 0".

Its a Catalog item from where some users are able to to request new Service Request.

Depending on the input my script creates a new Catalog item with the needed Variables, types etc. - works fine.

The challange here is that when my script creates a Catalog UI policy its forced into the Default domain because its Domain separated. (its marked as the default domain in the setup)

Neither Catalog items or Policy actions is domain separated though.

Im am not able to create the Policy in global through a script and as long its not in global (doesnt matter what domain its in) it will not attach to the item meaning that its not shown and doesnt work.

If I change the domain on the Policy manually everything works. (despite that the name of the actions is "empty" and its not possible to choose any variables in it - that i think is because the Policy cannot be "read" due to wrong domain.)

I have looked for Business rules etc for UI policy tables and globals, but theres nothing (this is also confirmed by manually create a Catalog UI policy - thats created in global if you are in Global).

I have tried to force sys_domain to 'global', '' (empty), null but nothing works.

Im afraid that theres some mechanism deep in Service Now that prevents this - i dont know if its intended though.

Anyone who have an idea on what to do ?

Best regards

Simon

UPDATE:

It seems like it takes the domain from req item and passes it to the catalog policy upon creation.

I dont know if in the "session" (non interactive) when the script runs or if there is a rule somewhere that determines this but i think its a rule because if req item is in 'global' it sets the policy domain to the 'default' domain and not global.

[Michael Fry1]

If the catalog item is launched from a child domain, does the RITM gets the child domain? and thus the Cat UI policy also gets the child domain?

Are you launching from another domain and trying to create in another domain?

Are you using workflow to drive all of this?

Are you using scratchpad to capture the domain and push into the workflow?

[Simon Christens]

Hi Michael

The cat item is launched from global.

The ritm is created in global and therefor the workflow starts in global.

Theres a cat task that determines if the new cat item should be created manually or automatic. Before i close this task i can set the domain on the ritm. If left in global the ui policy is created in default. If i set the domain on the ritm to a child then the policy is created in the child domain. It doesnt matter what the domain the cat task is in as far as i can see.

I do not pass any info through scratchpad.

The workflow creates everything if automatic creation is chosen.

Regards

Simon

[Michael Fry1]

So the only problem is if you don't change the domain from global, it creates the Cat UI policy in Default? Can you screen shot of workflow?

[Simon Christens]

Hi Michael

I have tested some more and...

As a "logged in user" if im NOT in global domain and runs the cat item - RITM is created i global (because the field that detemines the domain is not set).

When the script runs and creates the cat item, policy and actions it creates the policy from the domain the user is in and not from the RITM domain - i missed some combinations of creation i guess.

And this works. - the policy is shown in the list and apply to the cat item.

If the user is in global the policy is forced into default and will not apply. No matter what domain i change to in the policy is will not be shown in the cat item - unless the domain is global.

The next thing is that the name is "empty" even though it works

When entering the action it is indeed attached to the Policy but no Variables are available on the list. - even though this same action is actually working on the "whatever field" its attached to.

So the conclusion os far.

This actually works as long as its not a user in global who orders the Catalog item

Thanks for the help so far