Flow issue in a domain separated instance
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Friday
On the global domain:
- Decision table: RWG – responsible work
- Action: GetAssignmentTeamsForCI – calls a script include with a CI to get the assignment group from the decision table above
- Subflow: GetAssignmentTeamsForCI – calls the action above to make a few adjustments based on the uniqueness of the request record, most keep the action assignment
- Flow: Service Catalog – set to run as “System User” calls subflow above to get the assignment group
Two lower domains call for the catalog item A-Domain and B-Domain
A-Domain: returns the assignment group
Creates the task with the runtime setting the assignment group
But the actual task does not have the assignment group set
B-Domain: returns not found in the
But when running a test from the Action and the Subflow the values are populated with assignment groups.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Friday
For A-Domain I found that SN has a problem PRB1861596. I don't have access to see it, but one of the recommendations worked for the missing assignment group.
B-Domain is still not returning results at all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Saturday
The flow executes in that domain’s context by default which means lookups to a decision table or assignment group in the Global domain may return blank.......Because domain context governs both data visibility and flow execution, even if your action and subflow are in Global with Run as System, the task domain may prevent the global lookup from correctly resolving the assignment group.......To fix this you’ll need to either move or domain‑scope your decision table and assignment data into the domain where the task is created, or use a pattern such as creating a custom action (for example using ScriptableFlowRunner) or a Business Rule on sys_flow_context to force the domain of execution to Global when required.
If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.
Kaushal Kumar Jha - ServiceNow Consultant - Lets connect on Linkedin: https://www.linkedin.com/in/kaushalkrjha/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
6 hours ago
I found a post on community that says Xanadu introduced a problem:PRB1861596
I cannot see the problem, but I did get A-Domain to work with one of the proposed work arounds.
However, I'm still having issues with B-Domain. Why would A-Domain work, but B-Domain not work?
If I move the decision table to the B-Domain I'd have to duplicate the table and support two versions of the exact same thing. That doesn't make sense. I'm under the impression that you put common code at the higher domain so you can reduce code duplication.
