4 Ways to Publish a ServiceNow Application

Did you know there is more than one way to publish a scoped application? There are at least 4 methods that I know of, so let’s unpack them!

As a quick re-cap, scoped applications are ways to bundle configurations to ServiceNow, into a protected application scope. They can then be deployed to other instances outside of the one they are developed in via a Publish to create a new version and then a deploy.

#1 Native Studio UI

The most common way that everyone does it - through the native UI in studio.

#2 Using a Script

The undocumented mechanism to install a scoped app would be through a script.

publish: function(appID,version,devNotes){
	var trackerID;
	try { //run install command
		var progress_name = "Upload to the App Repository";
		var worker = new GlideScriptedHierarchicalWorker();
		worker.setProgressName(progress_name);
		worker.setBackground(true);
		worker.setCannotCancel(true);
		worker.setScriptIncludeName("sn_appauthor.ScopedAppUploaderAJAX");
		worker.setScriptIncludeMethod("start");
		var g_req = new GlobalRequest();
		g_req.setPreference('sysparm_sys_id',appID);
		g_req.setPreference('sysparm_version',version);
		g_req.setPreference('sysparm_dev_notes',devNotes);
		g_req.setPreference('sysparm_username', gs.getUserName());
		g_req.setPreference('sysparm_password', '');
		g_req.setPreference('sysparm_publish_to_store', 'false');
		g_req.setPreference('sysparm_target_upload_URL', '');
		worker.putConstructorArg('g_request',g_req);
			
		worker.start();
		trackerID = worker.getProgressID();
	} catch (err) {
		gs.error("Encountered error installing scoped app " + appID + ".\nError: " + err.message, this.type);
	}
	return trackerID;
},

var GlobalRequest = Class.create();
GlobalRequest.prototype = {
    initialize: function() {
		this.parms = {};
    },
	setPreference: function(key, value){
		this.parms[key] = value;
	},
	getParameter: function(key){
		return this.parms[key];
	},
    type: 'GlobalRequest'
};

#3 Update Sets

While it is officially documented, I feel like many people don’t know about this feature. You can publish a scoped app to an update set, which captures all the changes. Also a key benefit to using this method is that whichever instance you install the update set into, you can then open the app up in studio there.

#4 Using the CI/CD Spoke / API

For several releases now, ServiceNow offers a spoke and API for being able to publish an application.
Spoke Actions

• Publish Application With ID

• Publish Application With Scope

API: POST /sn_cicd/app_repo/publish

Publishes the specified application and all of its artifacts to the application repository.

State of Scoped Apps in 2022

My third most popular article since founding this blog was my “Scoped Apps, the good, bad and ugly”, and there have been quite a few changes in the space since 2019, it’s a bit overdue to revisit! I’m not going to re-hash my old sentiment, since I think it mostly still holds true (except for the workflow issues that have kind become old news with the explosion of Flows). Instead I’ll be focusing on the “new” things, either new in general or new to me!

Scoped applications are merely a encapsulated way to build applications on top of ServiceNow, instead of building everything in the default space. We continue to see more and more ServiceNow created scoped applications as time progresses (notable ones being HR and SecOps).

Note: At the time of writing this, I’m in a Rome Patch 4 instance.

The Good

1. CI/CD Spoke. If you haven’t seen ServiceNow CI/CD spoke yet, and all the automations available, you’re missing out. This has the potential to automate the entire scoped app release pipeline, from publishing, installing, scanning and testing, it can do it all. Except for update sets.

2. Flow Designer Improvements. With Flow designer blowing up, and so many new spokes available, and a re-designed UI layout, it’s better to use than ever. You can create re-usable actions in scoped apps and use them anywhere across the instance - it’s amazing.

3. Uninstalling. I should have covered this in my original post, but a major advantage that Scoped Apps have over other development, is that you can simply uninstall an app (and have options to leave the data). You can’t do anything that quick on regular global development to revert everything. If you need to sunset the app down the road, there is a clear path to do so.

The Bad

1. App Builder. I think the idea was good, but the implementation is poor, and I find it more of a hindrance and myself skipping the options as quick as I can. I would suggest instead of a “builder” approach, switch to a “template” approach, since most scoped application can be generalized in a couple of different ways. Also if people could create and publish their own templates, this would be an amazing win for the community.

2. Many still discourage it’s use (among ServiceNow and major partners). I’ve gotten involved on setting up new ServiceNow instances, and have had a chance to work with various professional services developers. The resounding message I get is that most don’t want to work in scoped applications. There isn’t much push towards scoped applications in the industry still.

3. Don’t Make Catalog Items in Scopes. One of the bigger pieces of best practice I’ve picked up on, is to not make catalog items in Scoped applications. There is too much value for re-use in variable sets, and in Flows for putting Catalog items in scoped to make sense. It’s better to build the catalog in global.

The Ugly

1. Flow Issues. With Flows being the big new thing that ServiceNow is advocating, there sure are a lot of issues with flows and scoped applications. The main one being that flows being activated don’t move when you install a scoped application, it only moves in an update set. Additionally Flows are not always captured properly in a scoped application and can be corrupted. Just stick to update sets or Global if you want to use Flows.

2. Versioning. Something lacking overall in the ServiceNow environment is version control, and with the addition of GitHub syncing, it’s a god send. However there is a sore need to being able too roll back development versions, and start over from a prior time within the instance. I’ve seen way too many apps just abandoned because they got to a point it wasn’t maintainable, or someone deleted a table, and couldn’t revert it.

3. Cross Scope Permissions are Buggy. ServiceNow has a feature to allow cross scope access to tables, script includes, etc, and it’s stored on several tables in the instance. Typically you never have to mess with these records, and cross scope records are automatically generated the first time you try to run something. However more and more either these records don’t get generated correctly, or when you move an app, they don’t carry over. The only fix I’ve found is to delete them and manually re-create them to toggle the permissions.

4. Admins can’t do Scoped ACLs, but non-admins Can !? There is a weird bug existing in newer ServiceNow instances, where if you’re a scoped app developer for an app you can edit and update the ACL within that app. However if you’re an admin (unless you have security_admin) you can’t edit it. This just further complicates the lines on the developer landscape with the 3 levels of scoped app developer, admin, and security_admin.

Scoped Apps, the good, bad and ugly

I’ve talked with many developers and scoped app development adoption isn’t very high, and it’s pretty understandable since there usually isn’t a good reason to switch for smaller deployments.

I’ve been developing in Scoped Apps for a year straight now, and help support over 250 scoped apps deployed. I feel like I’ve seen just about everything I’ve needed to see.

Note: At the time of writing this I am on a London Patch 7 instance.

The Good

1. It scales really well. If you have a lot of developers, there is no way giving all of them admin is practical, so scoped apps is a good cop out. You can just keep making new scoped apps as new ideas and developers come up.

2. It’s pretty encapsulated. If I want my Script include to not be called by other scopes, I can restrict it. It’s pretty hard to really mess up the system by developing in a scoped app. This makes instance administrators and users happy.

3. Studio is the best thing since sliced bread. Code search, app file list, and freakin tabs! I don’t think I want to go back to global development after using this. It’s as close to an IDE as we are probably going to get in ServiceNow, and I like the direction.

The Bad

1. Scoped Apps don’t track deletes. This is by design from ServiceNow, so store apps can’t delete other files in your instance. Thankfully you can work around this by doing scoped update sets for deletes, or by doing an uninstall and reinstall of the app. But it isn’t ideal at all.

2. Scoped Server Side APIs suck. If I had a nickel for every time I copied some global code and tried to run it in a scoped app and it said ‘Method does not exist’ or ‘Scoped Access Error’ I wouldn’t still be working on ServiceNow. Thankfully there are again workarounds exposing a global script include, and calling REST APIs to cross scope. I’m talking about APIs like GlideEncrypter used to decrypt credentials.

3. That Application Manager interface is crazy buggy. I’m talking about that page you use to install and update scoped apps (and store apps). The search works after the 3rd or 4th time, and the refresh and loading is broken. It was at least bearable pre-London, but has gotten worse with the overhaul. Maybe it’s less buggy if you only have like 5 apps.

4. The Manage Developers option needs a scroll bar…. and support for search people with the same name. Just in general the implementation of the manage developers interface is bad. If you want to add more than 8 people, or like someone who’s name is John Smith, you can’t pick the right one (without modifying that user’s name to like John Smith1, and reloading).

5. The Create Application File is not complete. There are certain types that just don’t show up under the application file create option, and other things that don’t even show up in the app list as files in your app. This is pretty annoying whenever they come up. Thankfully they at least got most of the big things.

The Ugly

1. For Scoped Catalog Item workflows Uninstall/Reinstall (to fix tracked deletes) breaks all active contexts. And once the old contexts are deleted there is basically no good way to get them back due to the complex workflow relationships. Except doing a full instance back-up.

2. Scoped Restrictions isn’t really built out. You can’t lock down a table to not have like a business rule created on it from another scope. You can’t select what scopes to white-list and other ones to block. This makes security really difficult because it is all or nothing.

3. ServiceNow doesn’t treat delegated developers as developers. They took away the ability to make update sets with the London release from delegated developers. Additionally Scoped App developers can’t actually update ACLs even the ones in their scope. When we raised a HI ticket and asked, the answer was that they needed security_admin. Yeah that isn’t gonna fly. Scoped App developers should effectively be admins in their app.