Among the most important Service Catalog enhancements in Jakarta is the full feature support for variable editors on records created via record producers. (Those who have HR or Customer Service case management active on their instance, or have created custom apps that extend the task table, must have gotten excited by now).
Before I go into further detail about what we did in this enhancement, let me first explain what a variable editor is.
What is a variable editor?
On a catalog item, or generically speaking on a requestor form, variables are used to collect specific information from the requestor. For example, I have an item to make requests for data backup. I am asking two questions from the requestor: 1) What needs to be backed up? (options are computer, database, or packaged media) and 2) What special requirements are needed? (a free-form text field).
Once a request has been submitted, variable editors are used to display those variables and their corresponding values on the Requested Item form, Catalog Task form, or, generically speaking, the fulfiller forms, so that the fulfiller has visibility into what requestor has entered for those questions.
If your forms do not have variable editors enabled, you can do so from the Configure Form Layout option:
It is helpful for the fulfiller to know what is entered by the Requestor in response to the questions (variables) asked at the time of submitting the order or request.
You can define catalog UI policies or client scripts to manage the behavior of these variables on catalog forms (for example, make a variable mandatory, make it read-only, etc). This applies to variable editors as well. For example, if you do not want the fulfillers to be able to edit the values that were entered by the requestor, then you can add a catalog UI policy to make the variable read-only on fulfiller form. Or if you are hiding a variable on requestor form, the same variable can be hidden on the variable editor with one common catalog UI policy by selecting either or both of these check boxes: "Applies on Requested Item" or "Applies on Catalog Tasks."
*I took the example of catalog UI policies but other platform features like catalog client scripts, catalog data lookups, reference qualifiers, and dependent reference fields can be applied to variables in variable editor on fulfiller forms the same way it applies to a variable on requestor form.
However, keep in mind that the variable editor used for catalog items (VEditor) is different from the variable editor used for record producers (Default). The default editor is applicable for Incident, Problem and Change tables; for others tables you can configure one. You can learn more about the two variable editors here: Service Catalog variable editors
Why two variable editors?
From Service Catalog, there are two ways to generate records:
- Through catalog items: Catalog items generate requests, requested items, and catalog task records.
- Through record producers: Record producers generate records in the target table for which they are defined. For example, a record producer can generate record in task extended tables such as Incident, Problem, HR, or any custom app that extends task table.
Variables' values from catalog items are stored in the sc_item_option table and variable values from record producers are mapped to respective fields in their target tables. This is the reason we have two types of variable editors.
What is the variable editor enhancement all about?
Until Jakarta, the above statement that "platform features like catalog UI policies, catalog client scripts, catalog data lookups, reference qualifiers, and dependent reference fields can be applied to variables in variable editor" was ONLY APPLICABLE TO "VEditor," which meant it was only applicable to request items (RITM) and catalog task (SCTASK) records generated by catalog items.
If the record was generated by a record producer, however, this statement did not hold true.
For example, if you used a record producer to create an incident from Service Catalog, and you hid some variables on the record producer form using a UI policy, they would be hidden on the record producer form. However, there was no option to apply the same policy to the record it created in an Incident table. So, when you open the record by going into the Incident module, you would see the hidden variable exposed on the form - because the default variable editor takes effect here and not VEditor.
New in Jakarta: Full support for record producers on both variable editors
In the Jakarta release we have provided the same support for catalog UI policies, catalog client scripts, catalog data lookups, reference qualifiers, and dependent reference fields on both the VEditor and default variable editors.
In Jakarta and beyond, if you are defining a UI policy and the item selected is a record producer, you will see a different checkbox called Applies on the Target Record.
If you are looking for a way to apply UI policies on variable editors for the records generated from record producers, then you will be happy to see this enhancement in Jakarta.
It is very common to see variable editors on records created by record producers for HR tables, customer service tables, or a task extended table from custom apps. Being able to apply the platform features such as UI policies, client scripts, etc. will be a huge help.
Comments to this blog are open in case you have any feedback or questions about this. Suggestions for improvements or enhancements are also welcome.
2 Comments
