What is the best practice around scope for new feature development

[Fred Jean]

Hello,

When implementing new features that are (a bit) related to a scoped application, but would not actually touch objects of that application, I am wondering what would be the best practice.
For instance let's say we have the HAM plugin and we want to create a new Catalog item with a bespoke flow working with Asset records, this could also involve some Business Rules; we have similar OotB flows that are in the HAM scope.

Should we :

• Do it in Global scope ?
• Do it in the scope of the existing application ? (for my example "Hardware Asset Management" or may be "Asset Management Common" ?)
• Create a new scoped application ?

[Community Alums]

Hi @Fred Jean ,

When i say it, it's the particular scoped app which you can choose from Application scope selector:

[Fred Jean]

Sorry, I don't see how this is answering my question.
I know what scoped applications are, I know about the application scope selector.

What I am trying to understand is when new feature developments should be part of Global scope, some Existing scope (and in that case which one) or New scope.

[Danny Mortensen]

Hi @Fred Jean,
You have a few options, but it's not always easy to pick the correct one. It will depend on the situation and the amount of changes you are making.

• Leading practice suggests that for more significant changes, create a scoped app as a container and use the App Repository for migration and deployment.
• Use update sets for small/minimal changes to OOB. Your scenario would probably not be considered significant.
• If you start app development using the app repository, continue to use it. Don't combine both update sets and App Repository.  It can lead to issues with deployments and rollbacks. 
• When using App Repository, the process for creating new app versions should be controlled to avoid untested code being included. This is especially relevant for larger teams. 
• One approach to address this risk is to combine Source (GIT) Integration and App Repository. Use the Source Integration feature to migrate code from DEV->TEST. Once testing passes in TEST environment, then create a new app version from TEST and use App Repository to deploy to later environments. This keeps untested code in the DEV environment from becoming part of an app version. 

I'm not specifically advocating it as a leading practice, but there are still plenty of ServiceNow customers and partners out there creating new artefacts such as Catalog Items and Flows in the Global scope and deploying them via Update Sets.

Update Sets work well with Agile development where your work is completed in Sprints. You can have a Parent Update Set for the Sprint, and each Story (or related stories) can be captured in an Update Set and linked as a child to the parent in a batch. This allows for uncompleted work to be removed from the parent and added to the next sprint. The child update sets can even be in different scopes as long as the parent update set is in the Global scope. Just make sure you keep track of everything in a deployment plan.

I'm still getting my head around the best approach for multiple developers working on a Scoped Application, but Source Control and branching seems the best approach, but that can be confusing for many.

If you wanted to extend the functionality of a scoped app or plugin that does not belong to you (not native to the instance stack) then you can use update sets but they will need to be in the scope you are working with. As mentioned above they can be deployed as a batch together with other scopes as children of a Global scoped parent.

At the risk of being controversial here, in your example, the development is not significant so Update Sets in Global scope (and other scopes where needed) would be fine despite what others might say. Some people just prefer to stick with the tried and tested Update Set process.

However, the leading practice would be to create a new scoped application to capture your changes so they are contained if work is significant.

When you create an application, you can choose to create it in a private scope (scoped application) or in a global scope (global application). So another option is to create a Global Application created in Studio where your updates are contained, but still in Global scope (which sounds a bit confusing). The downside of a Global application created in Studio is that you can't use the App Repository to deploy it, but you can use Source Control (e.g. Git).

Other considerations, though this possibly won't apply to your use case:
Security
If you were creating new tables do you want the data secure from other users or applications? If so a scoped application would be best.
Backing out changes
If you need to back out the changes, it is easy to uninstall the current version and re-install the prior version.   But you need to be careful if you have made any data changes as you may lose them when you back those changes out.  

With update sets, backing out of changes is tedious since you need to back out each update set separately. 
Keeping track of updates

Always document the changes you make to the scripts or artefacts of your applications for easier analysis during the upgrade process.
API's
ServiceNow provides JavaScript APIs for use within scripts running on the ServiceNow platform to deliver common functionality. However, not all APIs available in the Global scope are available in private scoped applications. This can trip you up if you are copying code from artefacts with in the Global scope.

Deployment Methods
You may end up using multiple deployment mechanisms for different changes depending on if you are doing update sets for one thing and publishing scoped apps via the app repository for another, and even Source Control. This can be tricky to manage so good governance is important.
A side story: One customer I worked with used BitBucket for all deployments. All Update Sets had to be stored in BitBucket as a single source of truth .. all deployments up the stack were from BitBucket downloaded and imported in. Update Sets were not retrieve via a lower instance in the stack. 
Cross-scope access
If extending gobal scope (e.g. ITSM) it's not recommended to use a scoped application as this can cause problems with cross-scope access for global artefacts. Use a global application to capture and track changes.

It's a big topic, with a lot of opinions so I'm surprise you only had one other person responding.

Caveat: This is of course my opinion based on my current knowledge so I'm happy to be corrected or hear different points of view. 🙂