ServiceNow is nothing if not flexible. It certainly gives you options for achieving your business and development goals; some of these are obvious and well documented, and some feel like they’re on the “secret menu” for the die-hards only. Regardless, ServiceNow was designed as a flexible platform.
Over the years I’ve seen this flexibility used in a myriad of ways, some really clever and some head-scratchers. Most fall somewhere in the middle. It’s also been the impetus for the rise of good and best practices, from tribal hearsay to attempted codification. But one thing I feel strongly about is using the pieces of the platform in the best way possible for maintenance by non-coders. This is my good practice.
One of the elements that exists all over the platform is the ability to script your way to a solution. Often times it’s an “advanced” option on a particular element – think Business Rules and Transform Map scripts. For people with a coding background, there’s also ways to use object-oriented concepts to build classes and extensions and call them from most anywhere you need them. What we’ve seen in recent years is ServiceNow itself has moved into this for much of its new product development. Anywhere advanced logic is needed – something that requires logic that can’t be contained in a single core element – ServiceNow development is building advanced, decomposed scripts (usually in standalone Script Includes) and calling them from script blocks in platform elements: ACLs, Business Rules, UI Actions, etc. The issue with this is it requires a coding background to either understand the logic flow, or to make changes required for your business.
(I’m going to go on a slight rant here. If you don’t care to read my angst and just want my good practice suggestion, skip to the next paragraph.) In my opinion, this is simply poor design and is indicative of turning ServiceNow over to coders and not critical thinkers. The founders of ServiceNow gave us all the elements we needed to create code-light solutions but they aren’t being used. I often say to customers, “you can code your way to anything, but this isn’t good design”, but I also see a lot of customers whose admins or outside contractors working on their instances just write code until a problem is solved. Great. So now any troubleshooting or changes require going through mountains of code to try and solve. This is not a sustainable maintenance model and should concern anyone making budget decisions about paying for ServiceNow development and maintenance.
So what am I getting at with this article? What I’m suggesting is that if one is smart with designing solutions, these solutions can be maintained through configuration and not code. The solution looks something like this:
In this scenario, the UI Element is out of the box, and the code and config are created by the developer. What’s important to note is that the code is written once, as part of the development of the solution, and changes to the logic are done through the configuration. In other words, the code is simply a mechanism to connect the business logic to the front end, and the logic is contained in configuration.
Let me go through a more specific example of this. I’ve worked with quite a few customers who are using Customer Service Management (CSM) and ITSM and need them to work together. From a business logic standpoint, CSM Cases need to integrate to ITSM records (Incident, Change, Service Request) when non-CSM teams are needed to solve an issue or fulfill a request in order to complete a Case. The Case remains the purview of the customer and the CSM Agent teams, but backend teams and processes are needed to “finish the job”. I call this a Process Integration or intra-ServiceNow integration – it works much the same as a ServiceNow to other system integration (or SN instance A to SN instance B), but is managed wholly within a single instance and works to integrate disparate records and processes rather than systems.
ServiceNow has recognized this need and created a Service Management integration plugin (check name), but this solution is all code, 100%, down to the field level. If you need your process integration to work any differently than what ServiceNow has provided, you have to write your own code to make it work.
To me, this is clearly not ideal. So what I’ve done is something that looks like this:
The key is that we use mapping records to maintain what should go where, when. The code simply is middleware between the maps and the application – it is kicked off when needed by the application, does lookups against the maps and updates records accordingly. The map records tells the system the following:
- What record and field to pull from
- What record and field to push to
- When the transaction should occur*
- Any field value translations required
* If you’re really slick, you use condition builders on the map records to determine the when. For example, you may only update the Case State to resolved when the integrated Request completes. Rather than building lots of Business Rules or writing If/Elses into your code, you build it into the mapping record. Now customer admins and even “admin-lites” can maintain business logic in configuration records and not code!
The elements described above can be extended and used for any Task integrations required across the platform. The steps are:
- Create Task Mappings as required
- Create Business Rules on the source tables – I usually just add a condition that the source record has to have a related Task-type record – that call the Script Include and pass the source and destination information to them.
I don’t consider any of this out of left field. Why? ServiceNow has already provided a model for this type of solution: Transform maps. While they were designed for importing data into the system, the use case is the same: We need to get data from one place to another, and we need allow for transformation of that data and logic to say when the data should be inserted, updated, or ignored. So why not use the same model for a process integration?
I’ve described a specific use case, but if you’re thinking along with me, you realize this way of thinking can be used for other development scenarios. For example, I’ve seen quite a few consultants and customers (including myself) develop Service Request fulfillment lookup tables for Approvals, Tasking, routing and other data points. The goal is not to have to maintain dozens or hundreds of workflows (flows) or to have to checkout and edit a workflow every time a simple configuration change is needed. Ultimately, the lesson is this: when you’re designing a solution to a business problem in ServiceNow, always think, “Can I build this in a way that a non-coder can maintain the solution? Does it have to be solved with code only?” I suggest the answer to the latter is rarely “yes”.
Happy designing!
