Health Scan finally going Public with Impact Health!?

For more than a decade, ServiceNow has sold a product called Health Scan, which allows you to check your instance against best practices. This product has always been proprietary, hidden, and only requestable on demand. Due to this, there have been many (myself included), invested in writing our own instance scan checks, or using 3rd Party applications that maintain the rule libraries themselves.

That all changes with the recent release last month, of Impact Health (store link) which includes 62 checks straight from ServiceNow. ServiceNow also intends (forward looking statements disclaimer) to get it closer to feature parity with Health Scan by one of the next feature releases.

Right now, of the 62 checks, they are all table and column level checks. The table level checks (24 of them) are transparent, but the column level checks/linter checks are protected (and we cannot see them). Given that trend it is highly likely that the remaining scripted checks will all be protected as well.

In Dec 2022 I developed 37 different health scan checks, to push for more open source checks to be available. Of those checks I developed, 5 of them made it into this release. Those checks are:

• Console.log in Client Scripts (day 8) comparable to HSD0001312 & HSD0001312

• JDBC Data Sources with "Use last run datetime" option unchecked (day 16) comparable to HSD0001554

• Synchronous Business Rules making SOAP or REST calls (day 23) comparable to HSD0001578 - mine is significantly better than theirs though

• Business Rules without function (bonus) comparable to HSD0003625

Closing Thoughts

I think this is a monumental shift though in the way ServiceNow is doing business, and I think some of the transparency is much appreciated, and will drive cleaner ServiceNow instances across the world. However, I’m annoyed that a majority of the code is hidden, and I really hope for more open source and transparency in best practices.

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.

Top 6 Wish List Features for ServiceNow Administrators

We can’t help but always want more! Here are my personal thoughts on 6 features that would round out the product and make ServiceNow’s administrator’s day to day life so much easier.

1. Restart a node

   I couldn’t count the number of times when some rogue Performance Analytic job got hung, and an entire node got hung. You have to reach out to HI, have them verify, and then they have to initiate the bounce. It’s 2021, and we don’t have the option to turn it off and back on in ServiceNow.

2. Trace a transaction, log, error, etc

   Something that an absolute pain in ServiceNow is figuring out something about a server side transaction, a log or anything, and trying to trace it down to what might be the root cause. You have to have multiple tabs open, recording timestamps, session ids, user ids, etc., to find anything at all. I would kill for some call stack type of technology, or better debugging tools.

3. Enhanced Self Monitoring

   ServiceNow actually has a self monitoring capability for Event Management, so it can manage itself. It would be great to take the step even further and build in self monitoring for nodes, database, event queue, email queue, or literally anything else besides just Event Management and MID servers resource alerts. I know some things are in the pipeline, but I just wish this formally gets expanded upon. So much potential.

4. AI DB Index Enhancer

   ServiceNow has some little tools to suggest database indexes, but wouldn’t it be great if it was smarter? Or you could set it up with some rules to automatically make suggested index tweaks on the fly? Some automation and algorithm to use indexes better could make a mediocre instance an amazing instance.

5. Workspace with quick actions dashboard for SysAdmins

   Workspaces are beginning to be all the rage, and they are great for so many different user personas. One such user persona is a ServiceNow admin. It would be awesome if there was a workspace that delivered to them their days work right in a single interface with powerful buttons and actions to manage that world. Simplify so many clicks. I know there are some good community dashboards and tools out there for sysadmins, so I hope this is just a matter of time!

6. Release Automation

   ServiceNow has been iterating on CI/CD for a number of releases now, but we still don’t have any automated capabilities for update sets, the backbone of ServiceNow instances for over a decade. I also hope they build some interfaces and flows for customers that want to use those CI/CD spoke actions, so they can get going fast.

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.