State of Scoped Apps in 2022

in

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.