| Scoped Applications in ServiceNow are a powerful way to create secure custom applications which are completely separated from the rest of the platform. Unfortunately, this often leads to situations where certain artifacts (aka application files) have been created in the wrong scoped app (or worse: in a customized store application). Of course, you could delete such "stray" files and recreate them in the target app, but often this is not possible due to the numerous references that already exist. |
|
The better approach would be to move the affected artifacts to another scoped application - just as it is possible between global scoped applications. Unfortunately, there is no corresponding function for this OOTB and ServiceNow itself says in the KB article KB0820186 that this is not possible. Also the answers in the community are accordingly rejecting.
However, via a small detour you can achieve the goal and the corresponding solution, which is presented in this article, is so trivial that I wonder if the whole thing is possibly a security risk.
Challenge
In an FSM-based implementation you have to deal with a huge amount of configurations, and schedules play a central role here, because all calculations in the "Dynamic Scheduler" are based on them.
FSM agents each have an individual schedule in which they can enter personal appointments. These personal schedules are not created automatically with the creation of a new user, but only when the agent wants to create the first personal appointment. And depending on the scenario, it can happen on a DEV that the personal schedules are created in a scoped app instead of in "Global" when using a test user. But once created, there is no option "Move to Application ..." available in the context menu:
As a result, unwanted artifacts like these schedules are carried over to the next instance, which can cause problems.
Solution
When importing records previously exported as XML, no checks are performed and the data is imported as it is. This gives us the opportunity to manipulate the XML data before re-importing it, because the XML exports are simply text files and can therefore be edited in any text editor. And the affiliation to an application is represented in an XML export by the two XML elements <sys_package> and <sys_scope>.
For the above example record of a schedule, it will look like this:
These two XML elements now only have to be replaced with the corresponding values of the desired application. In my example, they should be moved into the "Global" scope. Therefore the two highlighted lines in my above screenshot have to be replaced with:
<sys_package display_value="Global" source="global">global</sys_package>
<sys_scope display_value="Global">global</sys_scope>
After saving and importing the modified XML file, you might get an error like this:
It took me a while finding out that in your application picker you have to choose the application your record to be moved is in currently. After selecting "Field Service Capacity and Reservations Management" the XML file could be imported without any problems and the Application columns now displays "Global"
This application file movement is not restricted to the "Global" target. I also tried successfully moving between two scoped applications!
With the same approach, you also can move all application files to another scoped application. To do this, go to the table "sys_metadata", select the desired application and then start an XML export. Then open the exported XML file in a text editor and use the "Find and Replace" function to perform the same replacement of the XML elements <sys_package> and <sys_scope> as before in the example with only one application file.
