Form Layouts

Forms are everywhere in ServiceNow. Every record you view is a form and every form can have multiple views.

It’s so easy to edit a form, just right click on the header and go to ‘Configure > Form Layout’ or ‘Personalize > Form Layout’ depending on your version. Here you can add news fields to a section, or add a completely new section or even create a brand new view.

Adding the form layout to an update set is different to adding a standard record such as a business rule. With a business rule, the business rule (sys_script record) is added to the update set with an insert_update action along with all the columns on the table (and it’s parent tables). Form layouts on the other hand are far more complex and is a set of a number of tables. Editing the position of one field requires the whole form to be stored again in the update set, including all sections and fields. They get added to the update set using a custom processor. In addition to adding the form to the update set, it also clears the cache.

This 99% of the time works perfectly with no issues, that percentage goes down when working on domain separated environments (that’s a different story altogether!). But that one time it goes wrong, you navigate to a form that you’ve edited and just deployed, and it looks completely funny! Sections missing, fields missing. What to do?

Continue reading

Understanding Scratchpad Part 2 (Workflow)

Yesterday I wrote about the g_scratchpad object and what it’s used for. Today is about a different scratchpad, the workflow scratchpad. I started yesterday by explaining the scratchpad is for sharing data between different areas. It’s a lightweight way to store and share data. In the workflow, each activity is an individual container of functionality. They have no direct relationship with any of the other activities in the workflow, instead they are all connected via a parent workflow context record and also connected by the fact that the activities are all running against the same ServiceNow record. For the most part, that is absolutely fine, all activities are unique containers and don’t need details of the previous activity to be able to do what they need. But what if the activity required some information from a previous activity to do its job? Well this is where the workflow scratchpad comes in to play. Continue reading

Understanding Scratchpad Part 1 (g_scratchpad)

In ServiceNow, there’s two places where you can use a scratchpad to store data. The first is on form loads and the other is in the workflow. Each works differently and used for different purposes. In general however, they are both use to share information between different areas of the platform.

Today I’ll focus on the form loading which utilises onDisplay business rules as well as the g_scratchpad object. Just to get it out of the way, I think this is one of the most underutilised features on ServiceNow and I’m hoping posting an article about it will get it used (correctly) more often.

Continue reading

How ServiceNow Syncs Application Cache Between Nodes

ServiceNow’s infrastructure is one where multiple application Tomcat web servers all communicate with a single database. This is how everything is mainly kept in sync. However, despite indexing, database caches and all the other optimising you could do on the database, if ServiceNow had to query the database for every transaction it would grind to a halt. So for some of the most commonly used and static tables, ServiceNow puts them into the application cache on each of the individual nodes. Examples of this are system properties, ACLs and form layouts.

So for example, when you update a system property, the application knows you’ve just updated the system property and will invalidate and re-build it’s system properties cache (which is why you may have noticed when you update a system property, it can take a while to save sometimes).

All good so far and pretty standard stuff. Continue reading