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

Writing an Application in a Scope requires a different mindset.



You have to think in the perspective that your app is out in the wild, in use by other customers. Even if it isn't.


Therefore, once a v1 is published in the wild, you should never, ever, be deleting ANYTHING.



ACL's should never be deleted. They should be modified or made inactive.



In your 'Application File' list, you will see two flags:


  • Replace on Upgrade


You need to make sure this is set to True for all Application Files you want to apply over OOB.



I have found weird behaviour around these default values, so I recommend always checking them before publishing a new version.



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

Thanks Paul,


yes...seeing that logic now about how publishing using the "Make App available on other instances" to a scoped application works differently than using update sets.



One question, when you say:



In your 'Application File' list, you will see two flags:


  • Replace on Upgrade


Where is that?


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?


and one more question, thanks again Paul.



Do changes to list layouts not migrate with a scoped app?   These screen shots are from DEV.   If I make a change to the list layout, and then migrate an update (using "Make App available on other instances", should these changes move with the update?



find_real_file.png



find_real_file.png



find_real_file.png


If the List Layout is in the list of Application files, and is set to 'replace on upgrade', i would say that it *should* (but have not personally tested myself).



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