My entire experience with service catalog has been hindered by the UI policy's inability to cross variable sets. Let's start with one use case:
Background
- User variable set: contains user information, such as who the requested for is, their preferred contact method, etc.
- Shipping variable set: contains variables to get the shipping address. Multiple variables
- Billing variable set: contains variables to get billing address, billing #s, etc.
- Item options variable set: contains variables that show options for the item you're ordering (color, storage size, etc.)
- Eligibility variable set: a reference to select your corporate phone number. Hidden variable that gets a Yes/No if you are eligible to upgrade your phone now, based on a date on the referenced record.
If you select a phone that is not eligible to upgrade (ie. the date on the reference record is after today) then you can't order the catalog item. This is prevented by onSubmit script, but I wanted to hide all of the other variables that pertain to ordering the device (billing, shipping, options, etc.) so the user knows they can't continue. Start considering the user-experience.
Problem
The problem with this is that a standard UI policy cannot show/hide variables in another variable set, based on conditions of the current one. So, when the eligibility Y/N from the Eligibility variable set, you can't hide variables in the Shipping variable set. It simply isn't an option; ServiceNow blocks this for some reason. The only option is to use a catalog client script; while they do work it is not the recommended method and is brittle - changes to variables will potentially break the script.
Solution
I found a solution to this problem, and it worked well. It does, have a downside though, so I'll detail out my second solution that contians a more permanant fix.
Solution 1 - create the UI policy, then re-assign it
- The first solution I found was to first create your UI policy in the target variable set, for this example that would be the Shipping variable set. Don't worry about setting the criteria here, as you'll set that later. Right now, just add the UI policy actions.
- Once it is created, navigate to the Catalog UI Policies application in your left-side navigator (just type ui policies in the filter at the top). Personalize the list to add the Variable Set column if not already there.
- Filter down to find the UI policy you just created in step 1. Double click on the Variable Set column, and change it to your end-result variable set, in this case, the Eligibility variable set.
- Note, you can assign this to multiple variable sets first, before assigning it to the final one. I moved my UI policy to 4 different variable sets, added actions per set,
- Navigate back to your Eligibility variable set. You can now go in and set the criteria for when it will apply, based on conditions for variables that exist within the Eligibility variable set.
The downside of this solution: whenever you re-assign the UI policy to a different variable set, it breaks the application criteria. As long as you don't have to re-assign it after step 4, that is fine, however, when things change (as they always do) you will find yourself re-setting the application criteria from step 4. This leads to solution 2.
Solution 2 - remove ACL restriction for UI policy action applicable variable set
Solution 2 was driven as I found the downsides to solution 1, and wanted an even easier way to do this. You will see that when you're creating the UI policy actions, there is a read-only variable showing of what variable set the action applies to. This solution simply makes that editable.
- Right click on the label for Variable Set and select Configure Dictionary
- Un-check the Read only check box on the right side
- Save your changes
Now when you are creating a UI policy action, you can simply change the target variable set to the one containing the variable you want to target. Simple as that!
Why this Works
So you may ask, why does this work? The answer is the same for both solution 1 and 2 - the UI policy actions that run as a result of the criteria match are a hard reference to the variable's sys_id. Regardless of which variable set the UI policy is applied to, the sys_id of the action doesn't change.
Downsides?
Aside from what was listed above, I'm sure there are downsides to this - if there weren't ServiceNow likely would not have blocked it to begin with. However, I have not found any of them yet. It works flawlessly in both Service Catalog and the new Service Portal in Helsinki. If you know of any, post in a reply!
If you liked this, look for a similar posting from me soon on how to do an onChange catalog client script to target a variable from another variable set.
