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?
Unfortunately there’s no easy answer to that and it depends where the issue is really. Sometimes you can fix it by manually creating the whole form again via the Configure > Form Layout option. But a few things with this:
- Sometimes even this doesn’t work
- Even if it does work, it’s a very manual task and depending on the size of the form, increases the risk of mistakes being made
- Again if does work, sys_ids will be all different across environments. With forms this isn’t as big an issue as with other tables, but this may come back to haunt you if this doesn’t fix.
The other option, and far more laborious way, is to actually go through the tables that make up the form structure, and find the difference between your development instance and the target instance. Usually it’s a case of a record missing from the whole structure or in a domain separated environment, a particular record being in the wrong domain.
Once you find the missing/faulty record, export the correct one from development and deploy it to your target instance. If you went straight to the form now, you’d see zero difference. Why? Because updating the table directly doesn’t force the cache to be invalidated and so ServiceNow has no idea that you’ve actually edited the form layout. So to overcome this, navigate to cache.do page and clear the cache, forcing ServiceNow to read from the tables again and reload its cache with the latest version.
As you’ll see, there’s quite a few tables and records associated with generating the form structure, these tables can get quite large and so querying them each and every time would cause a massive performance hit.
So what tables are involved:
sys_ui_form – The entry point to the form. Each form view will have their own record here.
sys_ui_section – The holding record for a form section. This is the actual section itself for a form, but does not itself hold any field data.
sys_ui_form_section – The many to many table linking the forms to the sections.
sys_ui_element – This is each of the elements on a section. It contains the position value so that they can be ordered in the section using that the position.
It’s important to bare these tables in mind for when (if?) a form breaks after deployment and you need to go check what’s not deployed correctly.