Scoped app migration problems

patricklatella
Mega Sage

Hi everyone.

Has anyone experienced issues with using the "Make App available on other instances" method of migrating a scoped app to a TEST (of PROD) instance?   What I'm seeing is the following:

When I migrate a scoped application I've built from DEV to TEST it is not creating a mirror image in TEST of the application that exists in DEV. Here's more detail. I've created a scoped application in our DEV instance. I am using one specific update set to hold all the updates. To migrate the application to our TEST instance I'm using the System Applications>Applications module. I select the application from the menu. I then update the "Version". I then click "Make App available on other instances"...then "Submit". I then go to our TEST instance, System Applications>Applications module. I then see the red circle in the "Updates" tab at the top. I click on it and it shows my scoped app, and I click "Update".

However when I compare the application in TEST it does not match the application in DEV. Specifically the exact setup of ACLs on the application in DEV did not transfer to TEST. And as well a list view of records from a module did not transfer.

It was my understanding that this method of migrating a custom scoped application had the same functionality as migrating update sets...where the target instance shows a mirror image of the the DEV instance (for the changes within the update set).

Anyone have experience with this?

1 ACCEPTED SOLUTION

I didn't know that you deleted the artifacts in the new version. If that's the case then it is expected behaviour. I've shared more info in my blog here.


A guide to deleting records in scoped applications and retrieving them


View solution in original post

39 REPLIES 39

Hi Paul,


thanks again for your feedback.   So I'm seeing there are nuances to using the "Make App available on other instances" method of migrating updates to a scoped application.   So I believe I get it...don't "delete" anything in DEV, rather set to "inactive" when possible.   As well I see how to see what updates are set to "Replace on upgrade".  



That said, when I look at my list...I'm seeing "false" for every edit I'm making to my application...however some edits are going through and some are not.   Is there more logic I'm missing to how to make certain changes go through?    



find_real_file.png


one specific edit that is not going through is when I set some of the choices for a field on a table in my scoped app to "Inactive=true", this does not pass to the TEST instance when I do an update.



find_real_file.png




find_real_file.png


In other news...



The 'Replace on upgrade' and 'Customer update' fields are now deprecated in the Metadata table.



find_real_file.png



ServiceNow Nerd
ServiceNow Developer MVP 2020-2022
ServiceNow Community MVP 2019-2022

Thanks for the update Patrick. As I mentioned in my blog "For "sys_properties" table, we don't have an active field in the base system. For those records which don't have an active field we recommend you to just update the description field with the message, "This file is deprecated and is no longer required." The same steps will be followed for any records which don't have active field in the base system.


thanks Pradeep,


do "User Interface Properties" (System Properties>UI Properties) not transfer with a scoped application publish either?


Hi Pradeep,


I asked Paul the same thing...what's your take on this question:



And another question I have is...after V1 goes live (in either TEST or PROD), do you continue to make updates (no matter how small) using the "Make App available on other instances" method?   Is there ever a case to use update sets to move changes to a scoped application?