---

Empowering Builders

Catalog Builder only surfaces a subset of functionality to the user. ServiceNow developers must do the rest. Unfortunately, developers are often busy and are often prioritized on things other than building catalog items. This can make it difficult for builders to get things done quickly.

Are you a Catalog Builder struggling to get things done without the help of ServiceNow developers? Don’t worry; you’re not alone. Many builders face the same problem. Fortunately, there are some tips and tricks you can use to make yourself less reliant on developers and get things done more quickly and efficiently. In this blog post, we’ll review some tips and tricks.

Hiding hidden variable values from approvers

When writing behaviours to hide fields, it is only logical to define your actions positively, especially when framed as an outcome. This is typical when creating a condition to show a field.

The problem is that hiding a variable does not clear the value. If you don’t clear the value, it will still show up as a populated variable in the approval record.

You don’t need a developer to write a client script or UI policy to fix this. Prevention is better than a cure.

To avoid this, set the action in the negative and select ‘Clear value’.

Don’t forget to reverse the condition:

This will ensure no value is shown to the approver to avoid confusion.

Showing the user a dynamic message

You want to show a message on the form when the user does something. But you also don’t want to wait 2 weeks for a developer. You can do this yourself through some creative usage of labels and behaviours.

Create a question of type Display label / Rich text with the desired message.

Create a behaviour on that question only to show when you want the message. Now you have the illusion of presenting the user with a dynamic message!

Dependent question values

Want to implement something like a Category/Subcategory hierarchy but don’t know how?

Create one question for your category, and another question for each category option to represent your subcategory. Give them all the same name and show/hide them with behaviours. For example, if your Category has 3 options, you would have 4 questions – one for category, and one for each option. Define a behaviour for each 3 to hide and clear value if any other category value is selected. It is important to define it in terms of when it is not visible to ensure any previously selected value gets cleared.

This gives the end user the illusion of two questions with dependent values. The drawback here is reporting. If you want to have a single reportable subcategory field, you will need a developer to do some scripting.

Managing custom data tables yourself

Need to store custom data to use on your form(s) but don’t want to wait for a developer to create the table and load the data (or worse, waiting weeks just for them to tell you that they cannot justify using a custom table for you)? With Catalog Builder, you can do this yourself without worrying about beaurocracy. Start by creating a new question of type Choice – Dropdown (Fixed values) on your Catalog item. Add your custom data to the question in the Choices tab.

Add a reference table to the field annotations if you need to store additional attributes.

If you want the information to be more broadly available, consider creating a Knowledge article instead, referencing it instead. This also has the advantage of giving the responsibility for managing the data table to someone else!

If the data you want to store is informational, rather than functional, this is a great outside-the-box thinking alternative.

Answering variables on catalog tasks

Sometimes you might want a fulfilment team to populate a task variable before closing to pass information to the next team or control which team/task is performed next. Similar to the old ‘For office use only’ section you would see at the bottom of a paper form.

To do this, create a new section called ‘To be completed by fulfilment teams’ or similar.

To hide it from the Catalog view, create a behaviour on the section and select the bottom two options on the settings tab.

If you want to make the ‘Stock available’ variable mandatory on the first task, you can create a behaviour similar to the above with only ‘Applies while viewing the catalog tasks’ selected.

Creating fulfilment flows with parallel/branched tasks

You are not able to do this in Catalog Builder fulfilment steps, which will require thinking outside of the box.

Create a catalog item for each branch, with that branch’s fulfilment flow represented in that item.

Fixing typos and small changes quickly

Thanks to Catalog Builder, making small changes is very quick and easy. Fixing typos. Adding additional choices to menus. Tailoring a description. Do we really need a developer to do these things and wait for them to deploy these things called “Update Sets”?

Changes to forms and behaviours can be previewed and tested before changes to the live item are made. Have an open conversation with the ServiceNow development team and change management and formally agree on what you can change in production using Catalog Builder without going through the normal change process. It’s also a good idea to make the same change in the development environment when you make even the small adjustments in production to ensure your quick changes don’t get overridden the next time a developer moves your changes to production.

For process changes or anything with technical risk, I would recommend going through the standard development lifecycle and applicable change/release processes. And, of course, do not make changes outside of the agreed technical scope.

Closing thoughts

Following these tips and tricks can make you less reliant on developers and get more done using Catalog Builder. Remember, Catalog Builder is a powerful tool that can help you create and modify catalog items, questions, form behaviours and workflows without writing code. With some creativity and these tips, you can quickly and efficiently expand your catalog item using Catalog builder with fewer bottlenecks.

Comment below if you have any tips and tricks of your own for reducing reliance on developers.