Update Sets or Applications?

[chadcrawford]

Do I capture my work in an Update Set or an Application now?

Because honestly, I have no idea which to pick anymore. I've been using ServiceNow since Berlin. Back then the choice was simple because there was no choice, you captured your work in update sets. Now we have options. The ServiceNow application creator lets you, " develop custom applications to meet your business needs." Sure. But so do update sets.

I'm a modern guy. I'm not afraid of change. I was early on Firefox, and later Chrome. I even bought a MacBook back when the only people using OS X were graphic designers and video editors. But these are choices of preference and of minor consequence. Choosing an update set when I need an application or the reverse could potentially have a huge impact for me, resulting in lost hours of productivity and potentially rework. So how do I know which to choose?

I'm going to list what I see as the pros and cons of each, but I'm really looking to hear from the community here, so please weigh in.

Pros / Cons	Advantage
Update sets are familiar. I know what to expect from them.	Update Sets
Update sets have a proven track record. Their use to capture development work is well established.	Update Sets
Applications can be exported in fancy ways and even published to the ServiceNow Store (although this doesn't apply to my situation).	Applications
Applications seem to package up all development work nicely.	Applications
Tables named automatically and can get really messy in applications (Example: x_foce_widget_integration_widget_integration_change)	Update Sets
Same with roles.	Update Sets
When what you're trying to build needs to touch something out of scope, you'll still need to create an update set.	Update Sets
I've experienced an issue creating an inbound action that only exists when using Application Creator. Are there other known issues?	Update Sets

Incidentally, ServiceNow's opinion on the matter can be found here: When to Use the Application Repository and When to Use Another Deployment Option

[Katie A]

Hi Chad, I am relatively new to ServiceNow (6 months) and we recently upgraded to Fuji. When we started in Fuji I began working with with the Application builder because it was much easier to store updates and move all of the artifacts to a new instance. However, I ran into an issue where scoped applications are limited in terms of accessing certain functions.

Here are some issues I ran into:

* getXMLWait is not available in scoped applications, making it difficult to perform client-side validation when using AJAX especially for date checking   Access to getXMLWait is not available in scoped applications , what is workaround ?

* List Collector on variable set in a scoped application can't access global tables Unable to access User table via Catalog Item list collector

As a result of these limitations (especially with the List Collector) I went back to global update sets for the time being. If possible in the future I would like to use the Application builder again as it is a more consistent technique to store updates.

[Uncle Rob]

You may want to check out what jason.mckee said when I asked the same question.
Are Scoped Apps of any value to customers?

[jason_mckee]

tl;dr of my post:   You have to make your table/role/script include...etc. names globally unique anyway, the app scope prefix does that for you automatically and in a consistent fashion.   And with all sorts of other bonuses, like being able to filter a list of any entity in the system to just the ones used by your app.

Applications (both scoped and global) still boil down to update sets, so you can still use your existing deploy processes to move them around, but with the added bonus of not having to deploy all previous versions in the right order.   So say you develop version 1 of an app, push it to test and find a bug.   You go back to dev, fix the bug, push it to test again and yup, one more bug, one more trip back to dev.   So now you have three versions of your app and you need to push the stable v3 out to production.   With update sets, you need to apply v1, v2 and v3 of your app in sequence.   With an application, you only have to push the v3 and it has all the previous versions already rolled up, it's a self-contained unit of distribution.   (And yes, technically you can merge the v1, v2 and v3 update sets together into one, but that's just more manual effort to replicate the built-in functionality of an Application)

With regard to functionality that's not available in Scoped apps, there's definitely functionality that's not available in scoped apps yet.   Yet being the operative word.   The calls made available in scoped apps in Fuji were prioritized by popularity/frequency of use.   As time goes on, the scoped API will grow.   In the mean-time, if you only need a couple calls that are only available in Global scope, there are work-arounds, see: Re: Re: Re: Re: Need a way to parse an attached Excel spreadsheet in a Business Rule or UI Action

[jason_mckee]

Another thing to consider is our roadmap, in which Scoped apps are the future of custom app development.   Nothing is happening to make global scope apps and update sets any harder, but there's a lot of effort being expended to make developing/managing/maintaining scoped apps much easier (there's some really cool stuff coming down the pipe in Geneva).   For anything new, unless you have a very strong driver to do otherwise, the best default choice is to build a scoped app.

Other bonuses for scoped apps:

• Dependencies - if you build a custom app that makes use of CMDB (or Incident or another custom app), that dependency is captured and you can see what other resources an app makes use of before you even install it.
• Isolation - when you are building a scoped app and try to make changes to a resource in another scope (including Global), the platform will flag that for you and you can respond accordingly.   How many times have you been working on one thing, forgotten to change update sets and accidentally included a change for something else?   Simply not a problem in a scoped app.
• Interfaces - You can now make a Script Include private to your application so only your app can access it.   Same thing with tables, what previously required a whole mess of roles & ACLs can now be achieved with a couple checkboxes.   You can make a table entirely private to your application or expose it for read-only while forcing updates to occur through a Script Include (think conference room scheduling, reading the rooms and their schedule by other apps isn't a problem, but to schedule a room, you can actually require a call to your Script Include which could check availability, priority and all sorts of other things before actually inserting the row)