---

While recently working to improve a customer’s Service Catalog, I had a technical requirement to make variables mandatory upon closure on a Catalog Task. With the rapid pace of growth on the ServiceNow platform, adding new tools to the developer’s toolbox with every release, and the steady stream of technical blog content coming through the community, I thought it was worth checking out how others have solved this technical challenge. While I have tackled this solution before, it is healthy to review standard technical design patterns to see if ServiceNow has a better way, or if anyone has come up with a better solution. This had me challenging my own design and I went off in search to see if there was a better way. 

There doesn’t seem to be an intuitive method to complete this requirement through configuration alone, which is validated by a quick search of the forums. This problem has a few solutions rolling around the community but I wasn’t really happy with any of them. Some involved a fair degree of coding, some resulted in a poor UX, and nothing revealed any new configuration tools that I wasn’t already aware of.

I am passionate about finding new technical design patterns for common ServiceNow problems that provide a better User Experience (UX) for end-users and fulfiller users alike. I have been down this road before when I explored technical design patterns to make attachments conditionally mandatory on catalog forms (see Making Attachments Mandatory in SP: The Ultimate Guide), where I challenged the standard method of counting the number of attachments to come up with an approach for a better UX – only to be later trumped with a no-code solution introduced by Paris through attachment variables.

Before we begin my journey down this new rabbit hole, let’s discuss when and why you would want to make a variable mandatory on closure in the first place.

What problem are we trying to solve?

When trying to solve any technical problem, it is always important to take a step back and understand the business problem you are trying to solve. Sometimes the cost of the solution (time and maintenance) is greater than the value of the problem it solves, and it is easy to lose that perspective with development tunnel vision sets in.

So, why would you even want to make a variable mandatory on the closure of a Catalog task?

Remember the days of exhaustive, lengthy paper forms, that ask for every piece of information imaginable. You might even still see them in doctors’ surgeries or in your own office! Near the end of the form, you breathe a sigh of relief when you realize you don’t need to fill out the last section (or page) of the form, as you stumble up a break in big bold letters – OFFICE USE ONLY. The form is over for you (the end-user), but it has only just begun for the back-of-house staff – be it administration, or IT support.

It is not just fields populated by end-users that drive workflow. In reality, the process has only just started! These fields are then used to capture process-specific details that continue to drive a process. The paper form now bounces from team to team – department to department – until the process is complete and you are notified (if the form isn’t lost along the way!) Using the power of workflow and digitization, this data can now be used to drive workflow for teams, deciding which task goes to which team based on these variables.

Take the example of device repair. The faulty device is assessed to determine if the issue is within warranty or caused by general wear and tear. The output of this assessment (within warranty or not) will determine the workflow that follows, which may result in the end-user having to purchase a new device or pay for repairs. This may have been an ‘Office use only’ field in the past, but now is a variable for support staff to complete in ServiceNow. 

Setting up ‘office use only’ variables in ServiceNow

Digitizing paper-based forms isn’t just an exercise of “like for like” – otherwise you might end up with something like this:

 We don’t have to show the ‘office use only’ variables to end-users. Here is how we can do this: 

• Create an “Office Use Only” Variable set to contain your variables. For each variable within:
  • Set Variable visibility to stand alone so Variable details won’t show to end-user on their ticket in Service Portal
  • Hide the Variables on the Catalog Item by UI Policy, checking only “Applies on a Catalog Item view”
  • Hide the Variables on Request Items forms, checking only ‘Applies on Requested Item view’
  • Consider adding ‘itil’ role to Read and Write (permissions tab on Variables record)
  • Add the variable to display on the Catalog Task in which it needs to be populated

Now that the variable is showing on our Catalog Task, how do we make sure the office staff fill it in? If the value of the variable directs the path of the workflow, we must ensure it is filled in. But there isn’t initially a clear way to make it mandatory.

These variables aren’t terribly useful if they aren’t populated. We need a way to make sure they are populated before the Catalogue Task is closed, or our workflow won’t work as intended. I want to make my ‘office use only’ variables mandatory before a particular Catalog Task is closed. But how?

The path of realization

• Catalog UI Policy?
  • Variables can be made mandatory, read-only, hidden or cleared using Catalog UI Policy 👍
  • This can be applied to Catalog Task 👍
  • Catalog Task values are not available in the condition builder 👎
  • There must be a better way… 🤔
• Catalog onSubmit Client Script?
  • Applies on submit of Catalog Task 👍
  • Can check State is Close Complete using code 🤓
  • Can set variables mandatory using code 🤓
  • The form still submits after making variables mandatory 👎
  • Have to manually check variables are populated using code 👎
  • There must be a better way… 🤔
• UI Policy?
  • Can configure conditions based on form values without code 👍
  • Cannot check for Requested Item Catalog Item without code (OOB Item field is not on form) 
  • Added “Requested Item.Catalog Item” to form (using Configure > Form Layout)
  • Cannot make variables mandatory in field action 👎
  • There must be a better way… 🤔
• Client Script?
  • Need to put sys_id of Catalog Item in code 👎
  • Work with state numbers 👎
  • Code not very readable 👎
  • There must be a better way… 🤔
• UI Policy with Script?
  • Can write a client script (catalog or form) in UI Policy 🤓
  • Catalog Item and State check-in condition clear and readable 👍
  • Using a script, only requires one line of code to make all variables in variable set mandatory 👍
  • Only show variables on task that needs to be populated, they will always be mandatory
  • Low code, readable and maintainable, OOB solution 👍
  • I no longer feel dirty about the solution! 😊

The final configuration

UI Policy Conditions

Ensure the Item field is on the form, or it won’t work!

And Toggle ‘Advanced’ to make the script fields show.

Scripts

Execute if true

function onCondition() {
    g_form.setMandatory('office_use_only',true);
}

Execute if false

function onCondition() {
    g_form.setMandatory('office_use_only',false);
}

Conclusion

ServiceNow is undoubtedly moving towards more low-code no-code solutions. This is further demonstrated by the release of the Service Catalog Designer in Quebec, with further improvements expected in Rome (Safe harbor), and the ongoing updates to Flow Designer. As a result, it is wise to keep a constant eye out for solutions that use less code, which have less impact on upgrades. I feel the solution I landed upon that minimizes coding, using OOB configuration options, is the way to go. Is this the best way? Well, that probably depends on your situation and unique set of requirements.

How have you been meeting this requirement?

Do you have an approach that uses less code or even no-code?

Or perhaps you have a different approach entirely…

Comment below!