Note: I originally posted this article to the ServiceNow Developer Community forums. If you agree, please view it on the community, mark it as helpful, and voice your support in the comments there as well!

You can categorize the ServiceNow dev community into two camps: Those who love the idea of "application scope" and how it's been implemented, and those who think that scoped apps in ServiceNow are a bit broken.

As you may have guessed from the title of this post, I belong to the second camp, but hold on, don't go for your pitchforks just yet. I come with a peace offering: a few humble suggestions. Not to do away with scoped apps, but suggestions which I think might make scoped apps a little bit easier on all of us.

Disclaimer: I've received one or two private responses to this thread that contain sentiments like "If you don't like it, build your OWN platform!", so I'd like to take amoment and be really clear that I'm in no way disparaging ServiceNow as a platform. I think it's fantabulous. I've devoted my career toward it, I've written a few books on it, and I thoroughly enjoy my job working with it. I wrote this post, hoping to convey a tone that says "Hey guys, this scope thing seems a little wonky. What do you think about maybe trying it this way?", but with some humor thrown in. I hope that comes across, but in case it doesn't, just know that I think ServiceNow - scope, or no scope - is the best "ITSM+" platform out there by a generous margin, and I only want to contribute to it in a positive way.

As the title of this post says: If a genie popped into my life (presumably by way of a magical lamp) and gave me three wishes, I would use them all to - in my opinion - "fix" the issues with scope in ServiceNow. That's my dumb way of saying that I think the implementation of scope in ServiceNow isn't quite as great as it could be, and is the source of some frustration for myself and my developers; and suggesting some alternatives which might make sense to consider.

Hey, at least I didn't make it "Top 3 ways I'd change scope in ServiceNow - You won't believe #2!"

First Wish

I wish that I had the option to grant universal cross-scope privileges by default, unless explicitly protected.

Think of this as something like "allow by default". Specifically, while I'm developing in my own (that is, my company's own) instance. This one doesn't require much of a change to the implementation of scope, but is largely a matter of automation for the handling of cross-scope changes/updates. In fact, the thing that sparked the idea to write this article, was that I'm working on a tool that handles cross-scope changes for you (as much as possible) that would - if it works - behave a lot like the suggestions below imply.

Draw the scope lines however you like, put things in applications and whatever, that's fine -- but when I want to use an update set to modify one business rule for Incident, another business rule for HR cases, and another for Change tickets and so on, don't make me create three or more different update sets and swap back and forth between scopes to manage them.
Don't make me have to push all those update sets one at a time. Especially if it ends up that they're interdependent and I'm going to have to fix a bunch of errors by accepting remote update even though it can't find the record being referenced.
Don't make me make all my changes in a scoped app in Studio, then have one little change that has to go via update set just because it's to a record on the task table and in the global scope.
While I'm developing, just get out of my way, and let me make the changes I want. If some of it is part of one app and some is in Global, so what? I get the idea of delegated development - and it is indeed awesome in concept - but assuming I have access to both scopes, why do I need to go through this whole process to track and move my updates? This should've been a day-one feature, but it's years later now and I'm still playing musical update sets on a daily basis.

The platform knows what scope a record is in, so unless I'm trying to change that (which is often a nightmare, but I know ServiceNow has some stuff on the back-burner that might make that easier), just capture that scope data in the update set, and make the deployment script a little smarter and cross-scope-ier.

Second Wish

I wish that one scope could live inside of another, so I can grant access to a "parent" scope, and all its children.

When someone says "scope", I think of something nested betwixt some curly brackets, like this:

//This is the global scope.
ParentScope = {
    //THIS scope...
    ChildScope : {
        //...Encompasses THIS scope...
        GrandChildScope : {
            /* ...Which encompasses THIS scope... */
        }
        //...and therefore so does its parent...
    }
    //...which is this scope.
};

But in ServiceNow, it seems to be implemented more like this:

Global = { /* Some not-very-Global stuff */ };
sn_hr_core = {/* Some HR stuff */};
change = {/* Some Change stuff */};
//etc...

Or, to represent it visually:

What I would really love to see, however, is something more like this:

By allowing one scope to live inside another scope (which after all, is how scope has worked in nearly every context since time immemorial), you facilitate the scope model indicated in the second image. A couple things to note about this scope model:

First: see how there's a Default scope? That would take the place (and assume the functionality) of the current "global" scope (which... isn't very global at all).

Instead, the Global scope would be replaced with an actually global scope! One to which you can elevate. (Perhaps like you would elevate to "security admin"?)

Secondly, notice that while the current state has the "HR Service Portal" as effectively a completely separate silo, the second image represents it as part of the HR scope. In this model, if you have access to HR, you have access to the HR portal - because the HR portal is part of HR; but if you have access to the portal, you wouldn't necessarily have access to all of HR. You could even nest all task-based apps under a single "task" scope, while retaining their individual sub-scopes.

I don't see any reason why this should degrade any existing functionality, and it seems to me that this is more like what "scope" is really meant to be all about; not just in ServiceNow, but as a concept. Perhaps something like this would even make it far easier to silo extant ITIL processes in their own scopes without having to re-invent them or break anything? Maybe not, but I think it's worth looking into.

Third Wish

I wish that I could decide how scope is applied within my own instance, or at least that I could extend it and create my own custom scopes, inclusive of other scoped apps.

This one naturally follows, and is almost a logical result of the first two wishes. If the genie were being cool and just gave me this one, I'd use my third wish instead to be able to eat unlimited pizza but never gain weight or feel bloated. However, if that's not an option (because genies are sticklers), this would definitely be my third and final wish.

Imagine something very similar to the "suggested new scope' image above, including the ability to nest scopes, but where we can define our own custom scopes! That would allow for us to do super-cool stuff like this:

*Man, look at those mad MS Paint skillz.*

The blue line defines a custom scope, generated by the customer. They would simply "include" the scopes we'd like to have as part of their custom-scope, and suddenly, scopes make sense again, and are customizable.

---

Jokes aside, I wrote this not as an attack on the way things are, but as a humble suggestion for what I personally consider to be a better, and more intuitive way of doing things.

But it doesn't matter all that much what I think. I'm just one nerd. I would love to hear what you folks in the community think, and I'm sure SN would like to know as well; so please, reply with your support or criticism of this idea, and let me (and ServiceNow, with whom I'm not directly affiliated by the way) know what you think!