Are Scoped Apps of any value to customers?

Robert Fedoruk · ‎06-17-2015

So I've built Scoped Apps as a member of the TPP, so the value statement is clear for ServiceNow customers buying apps, or vendors providing them.

What about customers who are simply building apps once they sort out CreateNow licensing? Given how much of the platform is off limits to scoped apps, what advantage is it for a ServiceNow customer to create them internally? If there is no advantage, shouldn't it be easier for them to create apps in the Global scope?

Assuming the latter is true, why does the Create Application form force the use of a pre-defined scope and not allow us to enter "global"?

jason_mckee · ‎06-17-2015

So .. the namespaces are more for distinguishing components of apps between apps on the same instance, right?

Yup. And combined with the namespace of starting with your org code, as a byproduct, it makes it easier to guarantee that you won't have any naming collisions if your app is installed on another instance. Java's namespace standard of prefixing with the org's DNS name in reverse before jumping into the application's name, i.e. com.example.myapp, would be parallel to x_exmp_myapp in ServiceNow.

And it's not just useful for selling apps in the store. Consider if company Foo and company Bar who are both ServiceNow customers merge. You can imagine the challenges of consolidating apps in the global space into a single instance. Conversely, both company's scoped apps would be quite easy to consolidate into a single instance, you know for sure that x_foo_accounting won't collide with x_bar_accounting.

Going further down into the application level, consider the ever-common "Utility" class with it's grab-bag of functions that don't fit anywhere else you find in so many applications. When building in the Global scope, you have to make sure your Script Include name is globally unique, so you end up with AccountsPayableProcessingUtility. In a scoped app, you already know which app the Script Include belongs to, so you can simply name it Utility. Inside your Accounts Payable app (in Business Rules...etc.), you can say var util = new Utility(); use it and continue on your merry way.

Now let's pretend that our utility class has some value to another application, Accounts Receivable. It turns out Accounts Receivable was written by a different group and already has it's own Script Include named Utility. Assuming you've opened up Utility for use by other applications, you can still use it in a Business Rule by using the namespace: var aputil = new x_org_accounts_payable.Utility();

And because all components of a scoped app are associated with a namespace, it's not just table names, but everything that can potentially collide. Not just tables and Script Includes, but other things that can conflict and used to require effort to track down. Which URL would you rather start with to find where to make a change? https://myorg.service-now.com/contact_form.do or https://myorg.service-now.com/x_myorg_mycrm_contact_form.do? The later's namespace points you straight to the app you should investigate.

Coming from the developer background, the larger a project gets, the more important it is to have tools to break code down into isolated and manageable chunks. And when the environment doesn't provide that ability and you have to roll your own, things start getting messy.

For example, good old C has no concept of namespaces, every variable, function and data structure of a C program exists in one giant bucket and therefore has to be globally unique. Look at the source code for an Ethernet card driver in the Linux kernel: kernel/git/torvalds/linux.git - Linux kernel source tree, think you'll ever forget you're looking at the e1000 driver? (bonus points, try to find the definition of napi_enable()). See some parallels between that and what things would look like in a ServiceNow instance with 100 custom apps that were all in a Global scope?

The discoverability that scoped apps and namespaces provide makes it so much faster and easier to bring a new person up to speed and have them be productive. At a previous job, I had a team of 6 developers and was responsible for the care/feeding of 54 different applications. That's a daunting ratio of apps to developers to begin with, but if I had to get each new dev up to speed on all 54 applications before they could be productive, my group would never have been able to accomplish anything. And that's why I'm so excited about scoped apps, because when you can build an application in days and weeks instead of months and years, it's not hard to quickly build of a portfolio of apps that dwarfs the paltry 54 my old group maintained.

View solution in original post

Matt Saxton - G · ‎06-17-2015

rfedoruk,

Although i can't answer the "Why", i can however tell you i wish i had this earlier. A while back my company requested that i write a pretty lengthy custom application. I was still very new to ServiceNOW and it was a long engagement like 5 months to build. When i was nearing completion of the project the company decided to axe the project (after it was already installed in a my production instance). Now i'm stuck with an application which is mixed in and i can't simply "Uninstall it".

I think the ability to Uninstall even internally built applications can be useful.

Pradeep Sharma · ‎06-17-2015

Hi rfedoruk

The other benefits

1.Safe to develop and deploy

2.Runtime/design time protection

3.Can be uninstalled or deactivated.

4.Maintainability

5.With scoping applications all the table and field names created will be unique and will not contradict. It will be unique for your application.

.....

Robert Fedoruk · ‎06-17-2015

Hey Pradeep,

Thanks for stopping by my thread.
I'd argue most of those advantages are better for TPP developers selling apps to customers. Items 1, 3, 4, and 5 are already true when working under the global app. Its been true since the days when CreateNow was just called ServiceNow.

So if a customer wants to build an app that...

- will never be deployed to App store

- requires access to the platform that Scope will undermine

Then how do they create an App in global scope? Should they just build the old fashioned way? (Tables, columns, ACL's built manually and captured via update set)?

nsimha · ‎06-17-2015

Robert,

All the benefits of scoped apps for an ISV/TPP is equally applicable to a customer as well. The intent of scoped apps is make it easier for anyone to build, deploy and manage the lifecycle of applications. For customers that are building multiple apps, it is important to control the lifecycle of that app (upgrading, deployment) without creating unintended dependencies on other apps. For e.g, another app may start using a table you intended to keep private and changes to your app may break the other app. It is analogous to namespace in Java - would you consider every app in the same namespace? Unless it is a very small organization and one admin / developer knows and is responsible for everything in the instance, scoping is an absolute must.

Can you elaborate on "how much of the platform is off limits to scoped apps" ?

We are exposing more and more through the APIs.

Bobby Edmonds and David Gatley can elaborate more

ServiceNow Community servicenow community

Are Scoped Apps of any value to customers?