“Continuous improvement is not about the things you do well — that’s work. Continuous improvement is about removing the things that get in the way of your work. The headaches, the things that slow you down, that’s what continuous improvement is all about.” – Bruce Hamilton

I’ve written previously about the power of the platform, and my belief in its terrific original design and flexibility. In recent years, in its push to create and sell products, ServiceNow has sacrificed enhancements to the platform which us architects, developers and admins have to work around and explain to our customers. In this article, I’ll discuss some of the enhancements I wish ServiceNow would implement now (and in some cases should have done long ago). While selfishly these would make my life and the lives of people who manage and work on ServiceNow easier, these are also features that will keep ServiceNow ahead of, or at least apace of, the competition. And let’s not overstate our selfishness – some of these are great for requesters and customers too.

Rich-text / HTML Comments and Work Notes

We don’t live in a plain text world any more. … ServiceNow should enhance Comments and Word notes fields to support rich text and HTML formatting. One of the important outcomes of having this feature is the ability to include inline images and marked up text, so that agents and customers can exchange examples in order to resolve issues more expediently. Consider any IT firm who is troubleshooting a customer issue via Customer Service Management. The ability for both the customer and the support agent to supply screenshots with text and arrows to explain the exact issue or fix is far easier to communicate and comprehend than a plain text explanation (“a picture is worth 1000 words”), or a text description of an attachment that don’t live together in the UI. This method is cumbersome and unintuitive. Additionally, the rich text / HTML notes can go out and be received via email – the bane of our existence but fundamental part of how “business is done” no matter how much we fight it or come up with alternatives. (I don’t know of any email system that doesn’t support this formatting.) Regardless of whether the customer is viewing these marked up notes in the Service Portal or via email, their experience is enhanced, and in best cases, their issue can be resolved faster.

Editable Comments and Work Notes

I’ll include this as a sub-header under the enhanced notes banner. If we’re going to make comments and work notes rich, let’s go ahead and make them editable after saving in select cases and to select people. I say the latter part because if an agent has entered an Additional comment and the system has informed the customer of the comment via email, it’s likely a bad idea to turn around and edit that note. However, there are plenty of cases where the ability to edit a Work note is useful, and sometimes security reasons why (someone has put a password in plain text in a note). I haven’t devised a hard and fast rule of what should be editable when and by whom; let’s start with the functionality and figure it out from there.

Enhanced Attachments

Attachment functionality has been basic since the platform originated: Users with write access to any record in the system can attach files to that record and users with read access can view those files. There isn’t much functionality beyond this other than the ability to add all the attachments to all instances of an outbound email notification.

Customers have been asking for years for additional functionality around attachments:

• Classifying attachments as internal (fulfillers or employees) and external (requesters or customers), much like Comments and Work notes
• Specifying more complex security around each attachment on a record
• Choosing particular attachment(s) to send with an email notification (in real-time)

I’m sure there are others but the point is made. Getting into the weeds on how attachments are stored in ServiceNow is a discussion beyond this article. Suffice it to say there is a great demand for greater flexibility around the classification and security of attachments, beyond “this attachment belongs to this record”.

Requested by and for at the Task* Level

*Assumes you understand the Task table hierarchy and inheritance.

This is one of the most common customizations implementers have been doing as long as I’ve worked on ServiceNow. The basic thesis is this: For every Task (every Task), the system should be able to record, track and report on who requested the work, and who it’s requested for. This seems so simple. I think the lack of this in the platform is residue from the early days when ServiceNow was primarily just an ITSM system, and as such, they put a Caller field on Incident, a “Requested by” on Change, a “Requested for” on Service Request, and then didn’t think past it. In subsequent applications, they added “Requested for” or “Requested by” on certain applications, but it’s not consistent across the platform.

(Some may say “what about the ‘Opened by’ field on Task?”. While it’s great that this field exists at the Task level, consider this: An administrative assistant calls in a request to the Service Desk for something for his CEO boss. The Service Desk opens the Request. In this case, the “Requested by” is the admin assistant, the “Requested for” is the CEO, and the “Opened by” is the Service Desk agent. I think this field is needed and serves a distinct purpose to the others.)

To this end, I’ve worked on many implementations and have often recommended these fields be added to the Task table and they are used as the defacto values on all Task forms, lists, reports, etc. In addition to having a consistent approach and data/field structure on all Tasks (work being performed), it also enhances reporting at the Task level, and can be used to report on organizational performance: How many requests is IT delivering to HR? And vice versa? Having your requesters and assignees all at the Task level, along with good core data, allows you to take your Service Management to the next level. But this should not fall on implementers to customize; ServiceNow should fix the platform so it’s “out of the box” this way.

More Granular Log Timestamps

This is a feature purely for admins and developers. Because the platform timestamps on all records in the Created (sys_created_on) and Updated (sys_updated_on) are granular only down to the second, it’s often hard to troubleshoot the order of processing execution. After all, many of these executions are happening at the millisecond level. For example, if you’re troubleshooting a complex script with lots of logging, when you view the Script Logs or the more general Platform Logs, because you can only sort down to the second, you can’t see exactly the order of your logging. Of course you can number your log statements, but you lose the order of other logging that may be occurring outside of your explicit statements. This is important when other things in the system may be impacting your code. In an ideal world, at least for logging, you could see the exact order of execution. Indeed, this was possible when I was working at ServiceNow and could elevate to maint access on the platform (access above admin only available to ServiceNow employees), and I can tell you from experience it made my troubleshooting much easier.

I’ll hedge my statements by saying this is only really necessary for logging – Task-based work and other auditing is typically fine at the hours:minutes:seconds level.

Other Quick Hits

Here are a few others that I’ve addressed in other articles or will be in the future:

• Complete Catalog Variable redesign (aka “Variables are the worst”)
• Upgrade Workflows or fix Flow designer to have a GUI approach like Workflow
• Stop creating so many scopes – how about 1 per application?
• Fix the out of box State model once and for all
• Create out of the box solutions that are less code-heavy, aka Drink your own “low code” Kool-aid. None of us want to try and troubleshoot by looking through dozens of undocumented function calls!

Conclusion

I’ve written about some of the most common areas of concern for customers, things I’ve learned from 13 years of ServiceNow implementation. There’s still plenty of power in the platform – it’s why many of us started working with ServiceNow and what keeps us evangelizing about its power. The ask is simple: ServiceNow should solicit feedback from its most experienced implementers, honing in on the most common platform concerns that birth customizations of all shapes and sizes, and devote some of their massive development resources to these changes and enhancements. I’m sure this can be done in parallel with licensed application development. So do it, and keep this platform great!