Contents
Last year I was lucky to be accepted as a speaker at Knowledge22, the first in-person ServiceNow conference since the pandemic, and supported by my employer to travel to Sydney and present. Speaking about how to ‘Accelerate the Self-Service experience with Catalog Builder‘ drew a big crowd with lots of interest. I’ve recently had another opportunity to leverage Catalog Builder to improve and expand a customer’s Service Catalog with great success. With my renewed interest, I’ve noticed there is sparse practical online material on Catalog Builder. As a result, I have decided to write a three-part blog series (working titles) on Catalog Builder to document further what I have learnt and share it with the wider community.
As a ServiceNow Developer
Every servicenow developer
I want to spend less time creating Catalog items
So I spend more time doing cool development work
Are you a ServiceNow developer tired of spending countless hours creating Catalog items for your organization? You’re not alone. Catalog items are often low-code, including form design and basic workflow, which means that they can be created by non-developers using Catalog Builder. But not everything can be done in Catalog Builder, which means you still need to spend time either helping them out or working outside of the limitations of the product. But there are things you can do to reduce this dependency.
In this blog post, we’ll discuss some tips and tricks for making builders less reliant on you when it comes to creating Catalog items. By changing the way you work and applying some tricks, you can expose more no-code and low-code activities to Catalog builders, saving you time and focusing on higher-priority development tasks. This guide does assume you are already using Catalog Builder. So, let’s dive in!
Change your behaviour
In Catalog Builder, UI policies are presented as ‘Dynamic behaviours’. They work in pretty much the same way, with a few limitations. The big two are that you cannot write scripts, and the behaviour configuration is defined per field, meaning you only have one policy action per UI policy. UI Policy and field action is merged into one.
Alas, UI policies you create with multiple field actions cannot be seen or modified in Catalog Builder. If you want more of your items to be managed by your builders, you may wish to change your behaviour with respect to creating UI Policy. Consider creating them with no more than one field action to manage them within Catalog Builder.
Like most things, common sense should be applied to this guidance. Doing this won’t always make sense if maintainability is adversely affected.
Game, Variable Set, and Match
Variable sets are presented as Question sets in Catalog Builder. Existing variable sets can be added from within this interface but cannot be created or modified. While the builders won’t be able to create them on their own, and you still have to, this does present you with a unique advantage to win the long game. You can create Variable sets with preconfigured variables and scripts which can address some of the limitations of Catalog Builder.
For example, attachment variables cannot be created in the interface. As a developer, you can create a Variable set with a generic attachment variable inside it. Builders can now use attachment variables! If users don’t like the name of the generic variable, they can put it in a container with a title.
Similar story with Variable attributes. For example, adding autocomplete options to a variable is commonplace for a reference field. Create generic Variable sets for the most common ref types with autocomplete variable attributes pre-configured.
You may even wish to report on existing variables and create Variable sets for common occurrences. This will help the builders make items faster. Consider creating a Variable set for each common organisational data table (e.g. User, Department, Company).
And lastly, you can move common client scripts into script-only variable sets. Add a hidden label to the set with a description or a break to the set – variable sets with no variables won’t render in the UI.
Adding these question sets, while taking the time initially, will save you time in the long run and allow more items to be completely managed through Catalog Builder, by someone who isn’t you! You’ll be a winner, game, set and match!
A step in the right direction
Catalog builders can manage the item’s business workflow themself using Step based request fulfilment. This allows them to add tasks, custom and manager approvals to their workflow.
While this allows them to perform some basic fulfilment steps, a lot is still missing.
Did you know you can create your own steps, to do whatever you want?
If you want to learn how to create a basic one without input, read my blog post How to create custom fulfilment steps for Catalog builder. ServiceNow also outlines how to create one with inputs here. Stay tuned for a blog on this subject later this month.
The sky is the limit
While I am sure you are absolutely convinced by now that Catalog Builder is a great tool to give you more time to develop cool things, we must be honest with ourselves that Catalog Builder has limitations. ServiceNow has documented the limitations on its product documentation page.
But don’t fight them.
Go above them!
It is worth sacrificing some functionality to allow non-admins to manage Catalog items for themselves. Pre-build functionality they can’t do themselves into Variable sets. Align with supported form layouts. Check that your items can be opened in Catalog Builder. Create new fulfilment steps. I’ve created some that are even more powerful than what you can do in Flow Designer. How good is that! The sky is the limit.
Live on the edge
In Part 1 of this blog series, I outlined all the features that had been added to Catalog Builder since its inception. The product is steadily getting new features that expose even more of the platform’s Service catalog capability to our no/low coding friends. To put this functionality in the hands of our friends faster, we need to keep our system up to date. Catalog Builder is not managed via the app store, so we have to wait for quarterly releases (unlike the store, which is monthly). Stay on the bleeding edge!
In conclusion
As a ServiceNow developer, there are several things you can do to empower catalog builders and make them less reliant on you. By using Single Policy Actions, Variable Sets, and extending fulfillment steps, you can expose more no-code and low-code activities to catalog builders. These tips and tricks will help you save time and focus on more important development tasks.
It’s also important to keep the platform updated to ensure that the latest features and functionalities are available to catalog builders. As the platform evolves, it’s essential to keep up with the latest updates and features to provide the best possible experience for catalog builders.
By following these tips and tricks, you can work more efficiently and effectively with catalog builders, enabling them to create high-quality catalog items without requiring your direct involvement. This will help streamline your development process, increase your productivity, and ultimately benefit your organization. So, try these tips and see how they can help you and your team become more productive and effective! Comment below if you have any of your own.
