Moving from Update Sets to Scoped Applications

[adrianps]

Hi all,

I just need someone to check my understanding of update sets vs scoped applications.

After reading this article (When to use update sets) I've started thinking that a scoped application should be the preferred way to develop customisations in the future.

I've got a workflow that exists in the global namespace.  I want to create a customisation that will add a new field to the core_company table, and update the workflow so that it can make use of this new field.

FYI: The workflow in question manages notifications for SLA warnings and breaches.

So if I understand things correctly, in order to 'package' my customisations in Studio, I would need to delete my global workflow and replace it with a near identical scoped workflow in Studio.  I'd also add the new table field via the Studio application.

Does this sound correct?

Cheers,

Adrian

[Bozhidar Dimitr · Accepted solution]

Hey,

Unless you are developing for the ServiceNow Store you should not really use scoped applications. While they provide some sort of 'encapsulation' via configuration, they add a layer of unnecessary complexity, especially if you are developing on a customer's instance. Update sets are the recommended way to handle development migrations in this  case.

However, to answer your question: if you could create a table field in a different scope than the table itself (not sure you could do this, but assuming you can from your question) you should be able to read it from all application scopes like a normal table field, including workflows.

Could you provide any more info for a more adequate answer? 🙂 

Cheers!

[adrianps]

Hi Bozhidar,

Your comments reflect a suspicion of mine.  I'm not developing for the Store and I did suspect that using scoped apps would introduce complexity.

The idea of using Studio to have all changes in one place for a particular modification was appealing.

It would be nice, then, if Studio could be used to create and display the contents of an update set.  I'd then have the best of both worlds.

As far as my immediate requirements are concerned, I think I'll stick with using an update set after all.

Cheers,

Adrian

[Bozhidar Dimitr]

Yes,

The thing with scoped applications is that unless artifacts are configured properly (Accessible from all application scopes, cross-scope policies) they would require additional configuration and possible run-time errors due to cross-scope access to tables and other application artifacts. While the Studio is a really great tool, unfortunately we have to develop with the good old SNow UI and its different application modules if we want to use update sets 🙂

You could also publish an application to an update set, but you are still working in a different scope than Global, so I would not recommend this approach.

Right now ServiceNow are gathering developer feedback (there's a pinned post in the forums). A studio for Global scope would be a great suggestion in my opinion! 🙂

Cheers!

[Bozhidar Dimitr]

Hey Adrian,

Quick update (hope you have tackled your issue but for future reference).

In the Studio you can 'Start from Global'. This way you can use the studio to build applications for the global scope and benefit from the full power of the Studio. 🙂