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]

Thank you for your feedback Greg!

[John Caruso]

For custom standalone apps, I'm definitely using scoped apps.

I would *love* to be able to package customization to things like Incident, Problem, Change as scoped apps, but there is a general lack of guidance on this topic.

You can search through community posts and pick up tidbits here and there, but there needs to be specific guidance on for example: Here's how to customize your Incident Management process entirely using a scoped app.

Covering something like, since I cannot change the dictionary entry for a global field (like task.business_service), how can I effectively add a reference qualifier to it within a scoped app?

I'm not even sure at this point if everything is possible. If not, that should also be documented. We should have a clear understanding, should we choose to go down the scoped app customization of ITSM global apps path, where the edges are. What must still be done in global vs what can be done scoped.

It would be great to see a series of articles or blog posts that cover the typical customizations for an Incident implementation all packaged as scoped app.

I'd wager the vast majority of dev work on the platform remains as ITSM (i.e., OOB global app) customization. If I am right, and your "platform business unit has the vision that we should all be building using scoped apps" then please, please tell us how we can do this for the most common development activity on the platform.

[Tim Woodruff]

1. The fact that scoped APIs are different from global API names is annoying.
2. I don't think it makes sense to build a "scoped app" for when a user wants a small enhancement to an existing application. I'm not totally clear on whether this is expected or not. Should all of this be scoped? Everything we do, effectively?
3. I guess I don't really understand the benefits of the above, if that is the expected way to do things.
4. Doing the above also makes a lot of weird scoping issues, such as.... "this isn't working, but I can't figure out why. it's probably something to do with scope, but I don't know how to check". A good "scope debugger" would be helpful here.

After having dug in and built a 5KLoC license management application in a scoped application, I can say that I LOOOOOOOOOOOOOVE the GIT integration, and the Studio. They're fantastic. But the rest, I just feel like I need a little guidance or direction from SN on how and when to use it. If I'm not building a new, custom app... if I've been doing things in the global scope since Dublin... what is the benefit of suddenly using scoped apps to contain small enhancements? should I even be doing that? under what circumstances should I use scoped apps and the studio?

I would really love to see a video that covered these questions -- especially the last one -- in great detail!

EDIT: One thing that occurs to me as a real problem that could arise from this, is the following scenario:

Dev-A updates the incident form layout as part of an enhancement ticket, in a scoped app.

Dev-B, as part of a different enhancement ticket, adds a field to the incident table. He wants to update the layout as well, but this is now in Dev A's scoped app?

Do we overwrite? merge? update? use both? how is this handled?

Honestly, I'm just not sure how SN expects scoped apps to be used. But I'd love to use them more! Seems like great functionality.

 On a related note, I've just posted this article about several ways that I think scope could be extremely improved. 

[John Caruso]

Tim,

I don't know how SN expects scoped app to be used either, but in the scenario you describe - two devs making changes to the incident form - this is how I think it could (should?) work:

Environment:

• a (purchased) sub-prod instance to integrate in
• Dev A has a personal dev instance (from develop.servicenow.com)
• Dev B has a personal dev instance (from develop.servicenow.com)

Dev A begins on the sub-prod instance creating an empty scoped app to house all Incident customizations (call it INC). The main reason to start on the sub-prod instance is to be able to create the app under the right company code, so it shows up in the company app repository.

Dev A immediately links the INC scope app to an empty git repo. This enables multiple devs to integrate (merge) their changes.

Dev A switches over to his personal dev instance, and imports the INC app from git.

Dev A makes his form layout change (which I believe means creating a new view in the scoped app to replace to default view, since all the OOB views are global).

Dev A first pulls latest changes from git (in case another developer committed something first). He merges those changes if needed, then commits his changes to git.

Dev A switches to the sub-prod instance and pulls the latest commits from git, then does integration testing.

Dev B is aware of INC scoped and its git repo and knows that all his changes must be done within the scoped app. From his personal dev instance, he imports the INC app from git. This will include Dev A's changes (as well as any other committed changes from other devs).

Dev B makes his change to the Incident form (using Dev A's new default scoped view) and adds his new (scoped) field.

Dev B first pulls latest changes from git (in case another developer committed something first). He merges those changes if needed, then commits his changes to git.

At this point the git repo contains commits by both Dev A and Dev B.

Dev B switches to the sub-prod instance and pulls the latest commits from git, then does integration testing.

At any point in time, the app could be "published" (made available to other instances) from the sub-prod instance. At this point I think the version number should be incremented and a git tag corresponding to the version be added to this git repo.

The tag will facilitate creating a patch branch in the future if that version of the app gets installed in prod and needs to be patched.

I am probably missing something here as I've not actually tried this type of process out, but I figured I'd share my thoughts and hopefully someone can build upon this as part of the guidance I've requested for both usage of scoped apps to do global ITSM customization and guidance on the usage of git in the same context.

John

[JusCuz]

I would think you would just have one scoped app 'Incident updates' and all such changes you described would go in there. Having a scope for each and every change to incident would be messy and probably not work very well.