(Spoiler: This article isn’t about how to get access to the hidden pages, just an explanation of them – sorry)
Let me start this one by saying that pretty much everything of what you see in ServiceNow is written in Jelly. Recently many of these Jelly scripts include AngularJS but the core rendering engine is still Jelly (no idea if this is ever going to change because it’d be a huge undertaking – but one I’d definitely welcome with open arms!).
This goes for every field on a form, every UI action, the whole navigation, every dialog page, everything.
So the next question is then if it’s all Jelly pages, where are they stored? Even if we haven’t thought of fields on a form as UI macro before, we’ve all seen a part of the UI that the client wants us to change, and we spend ages looking for it in UI macros and UI pages only to come to the conclusion that it’s magic and somehow ServiceNow just makes it happen.
Well, the truth of the matter is that there are multiple places where ServiceNow allows the storage of Jelly pages.
The first are the two tables we’re well aware of, UI page (sys_ui_page) and UI Macro (sys_ui_macro).
The next two are less obvious. The third place ServiceNow stores them is on the nodes themselves as flat files. And finally the fourth place is within the Java code itself. Either way, it doesn’t make much difference to us where these last two are stored, we haven’t got access to them anyway.
But… ServiceNow do. And sometimes, very very rarely, they will be willing to share a piece of code from the backend with you. Normally this is in response to you finding a bug in the code and needing a quick fix. They’ll amend the back end file to fix the code and send you the xml file to use.
How does this work then? Well it’s quite simple, the ServiceNow developers have allowed this as a workaround for issues. What the application does is when it’s loading a Jelly page, it first looks in the database for the record. If it can’t find it there, then it goes and checks it’s cache and finally if it can’t find it there it goes onto the server and checks for it there. So when ServiceNow give you a file, all they need to do is make sure the file is the same name as the one on the server and automatically that is the one that is chosen when loading the views.
A few of points worth remembering with this.
Firstly, ServiceNow will very very (very) rarely give you the hidden Jelly code. It’s usually hidden for a reason. They’ll make the call on whether it’s technically the right thing to give it to you or not, and the answer is usually that it’s not.
Second point, is you then need to be careful on upgrades. The issue is, because these files are distributed as part of the ServiceNow installation and not written to the database, there will be no ‘skipped’ records for the UI page or macro. It’ll look like it was all upgraded fine. So you need to keep an eye on this and check that the functionality still works as expected.
Thirdly, if ServiceNow have added new functionality to this ui page/macro, they would have deployed it to the backend file. They will not keep releasing the code for it so you will have three options available to you: 1) Revert back to their OOB record 2) Keep your existing code that hasn’t got all the new shiny functionality 3) Manually try and update the code to replicate what they offer.
Fourthly, it is EXTREMELY easy to revert back to out of the box with these files. All you need to do is rename the page/macro to something else (add a suffix to it for example) and it’ll no longer match the server’s flat file and therefore will not be rendered instead of the OOB page.
Fifth and finally, ServiceNow will no longer support this code. Even if you only changed one line in the page, ServiceNow will consider that you own it and it’s custom code. They will only support it if you revert back to OOB.
As a side note, ServiceNow is going through a major transition right now where you can see a lot of the pages are moving to utilise AngularJS more and more. Therefore as they work through these pages, you might notice that if you had any of these server overrides, they’ll very shortly stop working if they’re the older non-AngularJS versions. Just something to keep an eye on during your upgrades