Should Variable Editor be used for HR Cases ?

[servicenow_dev]

Hi HRSD community,

Variable editor section in HR Case form is not available OOB, but can of course be added by creating a formatter and adding it to the form view of HR table. After creating this and adding to HR Case form, from my small testing variables get captured and work as well as they do for RITMs where this is available OOB.
HR Cases have this alternative solution where variable name/values from record producer come to description field, but it has its limitations, like the checkbox field coming despite it being hidden or not in form.

So my question is why Variable Editor is not available OOB for HR Cases too ?
Why this other solution of copying variable name/values in description for HR Cases ?
Does HR having its own Scope make Variable Editor functionality not work correctly, does anyone have any experience on this, having variable editor active in HR Cases ?

Would be great to know what your thoughts are on this topic.

[servicenow_dev]

Thanks @Susan Britt ,
My client has used HR for some years and Record Producers have evolved into long forms and some UI Rules and C scripts too. So they appreciate having variable editor section available. No plan for changing values.
Was just wondering if there any downsides to it, since to me it seems so much better. So good it should be OOB behavior in my opinion, but maybe I am just used to it from ITSM.

Regarding workspace, they are not using any HR workspace at the moment, they work in Core view still. 

[ASHU_1]

Hi Susan,

Can you explain this further pls?

1. If the requirement is that Agents should be able to change the value and it needs to be part of Audit trail - what is the recommended solution.

2. If If the requirement is that Agents should be able to change the value but no Audit trail required - what is the recommended solution.

3. There is no requirement for Agents to change the value, just read only - what is the recommended solution.

[JulianLemcke]

Hi there,

Very interesting discussion. I've thus far mostly advocated to use it. Why? Because a lot of times you will get more and more Record Producers and often HR is in need of having these fields also available on the HR Case and then you get into the discussion of "Custom Field" vs "Variables".

During my consulting times, I've advocated for it and I'm still hearing good feedback from them that they use the variables on the case table. And I've also soon customers having a huge amount of "custom fields" (even nowadays with the different CoEs).

We have also introduced a "Framework" that "Internal HR Cases" (opened by HR Agents) are getting created form within the Workspace over the Record Producer - I'm now exploring to use the "Generate HR Case" (OOTB) function in conjunction with a Business Rule to create the variables questions empty on the form so that they can still be used. 
We've also used the Variables for the "HR Agents inputs" and I like the scalability of it.

Cheers,

Julian

[servicenow_dev]

Thanks @JulianLemcke , very interesting take on this. 

[JulianLemcke]

Additionally on that: I'm now evaluating to create a script, that generates the "Variables" (empty) on the HR Case for those HR Cases that do get generated over the "Create HR Case" UI so to have both worlds: the variables to reduce the hr fields and the nice "Case Generation UI".