Scoped app migration problems

[patricklatella]

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?

[The SN Nerd]

You want to Navigate to the Application Record and view the Application Files related list.

[patricklatella]

Hello Pradeep,

I've gotten some information from Chris Lo at ServiceNow about how migrating scoped applications using the "Make App available on other instances" method works, and I believe I have a good understanding.   It operated more like an instance upgrade, where all customizations are preserved...and with a scoped app it treats the whole application in the target instance like a customization.   So changing or deleting objects in my DEV instance, and then doing an update via "Make App available on other instance" doesn't transfer the changes, it ADDS those changes.

So Chris said that it is fine to move the initial application via the "Make App available on other instances" method, and then to migrate small edits (like deleting choices) using an update set within that application scope.

However when I did this for an edit to a list layout, when I migrated my update set, it "doubled" the columns in the list view.   Do you know what would explain this?   And how would I correct this?   I know I can just edit the list layout in TEST, but I want to be sure the list layout will transfer properly to Production when we move the application...and this behavior is just odd.  

[Pradeep Sharma]

Thanks for the update Patrick. I came across this issue while I was working with one of the partners. Before I give you solution, I have a quick question for you. Is this a custom table extended from OOTB table? Please confirm.

[The SN Nerd]

I think with scoped apps, it would be good practice to lock down any configuration that has the potential to change, so it the customer can't change it and you won't find yourself being unable to upgrade certain things.

[patricklatella]

yes, it is a custom table extended from Task