The CreatorCon Call for Content is officially open! Get started here.

How to package multi-scope changes into a single installable app (I accept other methods too)

jordimsant
Tera Guru

Hi everyone,

 

My team and I are planning to create an application in Application Studio that encapsulates all the common configuration changes we normally make in our customers’ instances — so that by simply installing this app, all those changes are automatically applied.

 

However, we’ve run into the following problem: as far as I know, an app can only modify configurations within one scope. In our case, many of the required changes span multiple scopes (for example: Incident for Service Operations Workspace, Employee Center Core, Request Management for Service Operations Workspace, etc.).

 

Our goal is to have a single installable package that applies all basic configurations to an OOB instance instantly, so our questions are:

  • How could we build such an app given these scope limitations?
  • Is there a better or more suitable way to prepare and package these common instance changes

Any advice, best practices, or examples from your experience would be greatly appreciated.

 

Thanks a lot, community!

1 ACCEPTED SOLUTION

@jordimsant 

If you want to make some changes going forward and supply to your customer then

-> capture it in correct scope update set in your main instance

-> export that update set and import in customer instance

Note: this is the only way and it might cause issues if your customer already did some customization to the component you are trying to supply later. you will get error while committing update set which you need to carefully review

OR

You can create multiple scoped apps and publish to Store and then ask Customer to install all of those. with this you can have control on app versioning as well

💡 If my response helped, please mark it as correct and close the thread 🔒— this helps future readers find the solution faster! 🙏

Regards,
Ankur
Certified Technical Architect  ||  9x ServiceNow MVP  ||  ServiceNow Community Leader

View solution in original post

3 REPLIES 3

Ankur Bawiskar
Tera Patron
Tera Patron

@jordimsant 

that's correct.

app can only directly modify artifacts within its own scope

Then create update sets in respective scope and deploy to customer instance later.

💡 If my response helped, please mark it as correct and close the thread 🔒— this helps future readers find the solution faster! 🙏

Regards,
Ankur
Certified Technical Architect  ||  9x ServiceNow MVP  ||  ServiceNow Community Leader

Then, what you’re proposing is that the best approach would be to create separate update sets for each scope, store them somewhere, and install them whenever we start a new customer project on a new instance, right?

 

I had also considered this option, but what happens if we need to apply some additional changes after the initial package is created? With applications, we could always modify and update them easily through Application Studio — isn’t there a more maintainable or “updatable” way of handling this?

 

Maybe it would make more sense to split the configuration into multiple scoped apps and maintain them independently?

@jordimsant 

If you want to make some changes going forward and supply to your customer then

-> capture it in correct scope update set in your main instance

-> export that update set and import in customer instance

Note: this is the only way and it might cause issues if your customer already did some customization to the component you are trying to supply later. you will get error while committing update set which you need to carefully review

OR

You can create multiple scoped apps and publish to Store and then ask Customer to install all of those. with this you can have control on app versioning as well

💡 If my response helped, please mark it as correct and close the thread 🔒— this helps future readers find the solution faster! 🙏

Regards,
Ankur
Certified Technical Architect  ||  9x ServiceNow MVP  ||  ServiceNow Community Leader