- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-18-2017 04:55 AM
I've developed a scoped application that contains a service portal but I'm running into issues moving the application between company instances (using System Applications > Applications > {name of application} > Make App available on other instances), specifically with updating the application after it's been installed on the target instance.
When I remove a widget from a SP page in DEV, then move the application from DEV to TEST, the widget remains on the SP page in TEST. As far as I can tell, all the other changes I make to the service portal are being changed in the target instance, but removed widgets (or containers) still appear in TEST.
According to all the documentation, this should not be happening because the scoped application should be capturing all these changes as I develop. I've been able to work around this by uninstalling and reinstalling the application on the target instance each time there's a version update but it's a clunky workaround that isn't practical for production.
Has anyone else run into this problem, and perhaps found a solution? Thanks community!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-18-2017 07:31 AM
Hey Chris,
Sadly, scoped apps do capture the deletes, but they do not propagate them to the target instance when the app is upgraded. This is especially troublesome for service portal, where you can end up with dozens of deletes when updating pages/containers/etc. The best way to propagate those changes purely via the scoped app is through uninstall/reinstall like you're doing. Another alternative is to track your changes in an update set within the app scope. You can then apply that update set to the target instance where the app is installed. Because update sets do properly propagate deletions, your results should be better.
Many of us are hopeful that a future version of scoped app functionality will enable better handling of deletes!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-18-2017 09:30 AM
Hey Pradeep - That's a great guide for typical configuration records. However, most Service Portal records do not have 'active' flags - they either exist or they do not, and can't simply be turned off.
Do you have any best practices around removal of records that cannot be deactivated, or is fix script the typical solution? Also, isn't it necessary for the customer to manually run a fix script in these cases? Is there any automated way to kick-off the clean-up process?
