Are you still developing in the global scope?

[Chuck Tomasi]

I'm hearing more and more that a lot of people are still developing their solutions in the global scope despite all the great development advancements we've built in to the platform (e.g. Git integration, Studio, delegated development, publish/install, etc.). Our platform business unit has the vision that we should all be building using scoped apps. This includes new apps as well as extensions to existing applications (even in the global scope.) I'd like to know what's keeping you from realizing that vision. Examples may include:

• There is a scripting API that is not available to scoped apps
• Our requirements force us to use synchronous Ajax
• We are still on Eureka
• I love update sets!
• I just don't know enough about creating scoped apps (and that's OK.)

Specifics are always appreciated. Thanks!

[Chuck Tomasi]

Scoped applications have quite a few benefits. Here's a highlight list

• Design time and runtime data protection
• Code protection
• Use of the built-in Studio IDE and integrated source control
• Delegated development
• Publish/Update applications instead of transferring, previewing, committing update sets
• Name spaces to avoid conflicting scripts, properties, tables, fields, etc.

[JusCuz]

Hello, sorry about resurrecting an older thread, but I do have some questions around scoping. I'm currently looking into what we can do around utilizing git and scoping for a lot of the work we do. Utilizing git definitely addresses a number of issues I have with just using update sets alone.

In the beginning of this thread, you mentioned using scoping for changes to ITSM applications, I'm intrigued by this, but have a number of concerns.

• when building out a new instance, there are a number of things that need to be done to make an instance production ready, simple things like making certian fields read only (number, created on, created by, etc...) and other simple changes like that. We really would not be able to check the 'read only' box on the task table using a scoped app, we cannot create a dictionary override for a field on the task table, so that leaves us not being able to make global changes such as this
• This would then have us created scopes such as incident_updates, definitely doable, but requires a change in thinking on the part of all developers that would touch the system
• The platform run time license is a HUGE question to all of this. We need clarity on this.

[Chuck Tomasi]

HI Jason,

To get to a "scoped development" environment, you may need an initial global update set to get the instance ready. Like you said, for some of the global changes to get out of the way - do it once and leave it be. Once those are done, you can continue making mods to your global apps in a scope and take advantage of the IDE, source control, publish/install, etc.

As for licensing, it's best to talk with your account manager. I refrain from what little I know here as it may change and don't want to get in to the 'Well, back in 2017, Chuck said xxxxxxx on the community.'

[meg6]

Hi Chuck,

We are planning to use servicenow for asset management. since we cant use git with global scope,I started exploring scoped app. Which one will be better for asset management(global/scoped app)?

How about having only one scoped app that will be replica of global and we build upon that as scoped application?

Please do suggest a better way to start with.

Thank you 

Megha

[William Busby]

I've only been a full-time ServiceNow developer for just over 3 years but I am seeing a very slow adoption rate for scoped apps. I've drank the koolaide because I'm sick of dealing with the issues of keeping several developers from stepping on each other and/or having bits of my work allocated to the wrong update set because I forgot to switch them to work on that little tweak.

As to others, from what I observe the issues impacting adoption are:

- Lack of consistent message/guidance from ServiceNow support. Recently members of a team I support were told to use Studio/scoped apps to develop new apps but update sets should be used to customize/add functionality to existing apps (incident, problem, etc.)

- There are so many script includes that are still locked to global and accessible from the global scope only. Why hasn't ServiceNow made those accessible for scoped apps?

- ServiceNow does a great job delivering new tools/functionality but less than stellar job or communicating why we should care or invest in adopting them. Good example is the new Kingston Flow Designer. Looks cool but it clearly duplicates functionality available in workflows. Is this 'Workflows Lite'? The new workflow paradigm and what I've spent the last three years learning is becoming legacy? You spent a lot of time and effort developing it, what's the problem it was intended to address?