Moving Changes for an OOB Scoped Application

[chrisshellhamme]

I recently activated the GRC Plugins on my NonProd instances.   This created several OOB scoped applications.   I need to make configuration changes to some of the associated objects that I will want to move through the environments.   What is the best practice for doing this?   Should I be using the Application update process or should I create an update set in the chosen Namespace and then move it through the environments using the standard update set process?

Thanks,

Chris

[Chuck Tomasi]

Hi Christopher,

I've been asked this recently and now it appears here. While I don't have a 'certified' answer, I've asked our platform product manager for guidance. I'll let you know what I find out.

FWIW, I also plan to include it in a larger document I'm working on.

[Pradeep Sharma]

Hello Chris,

If the intention is to simply install the application for testing or use on the target instance, then yes, utilizing the 'make app available to other instances' UI action, followed by 'installing' the app from the company repository, is the preferred method.

However, those that wish to move an app with the purpose of continuing development on the target instance, going forward, must move the application through update set by using the 'Publish to Update Set' UI action followed by exporting the newly created update set to XML via the 'Export to XML' UI action. This method is the only way to move an application in its entirely with the purpose of moving where further development of the app originates from.

[Chuck Tomasi]

HI Pradeep,

I don't know if we read this differently. I read it as he activated an OOB scoped app (GRC) and now wants to add changes. What's the recommended way to move those changes from dev to higher instances? Should he create a new scope and build on top of that using the publish feature? Should be use update sets (either global or scoped?)

Your answer sounded more applicable to starting a new scoped app from scratch. Let me know if your answer is applicable to extending configuration on a scoped SN app or if we read it differently. Thanks.

[Pradeep Sharma · Accepted solution]

Hello Chuck, Chris

Thanks for the update. Here is the info I got from the team.

If there are major changes to be modified in the scoped SN app then the best practice is to create a new scoped application and capture all the changes within that application scope. All the SN app artifacts can be inherited by creating a dependency with in your custom scoped app. This way you get the option to publish an app on multiple instances via "make the app available to other instances". On the other hand, if the changes are minor then you can create an update set in the same SN app scope and move the changes through the update set.

Please let me know if you have any questions.