Service table fields functionality not working?

alijubran
Kilo Expert

Is there somewhere other than the HR Service record that we indicate a field is to be used as a'Service table fields'? If I create a custom field that is needed for a service, I have added it to the Service table fields slushbucket but that field still shows up for all HR Services.

I am assuming I have to indicate somewhere that the fcustom field is a field that should hide/show based on HR Service.

1 ACCEPTED SOLUTION

Hi Ali and Ludijor



Sorry, I misunderstood Ali's initial question.   The HR Service Table Fields do react in the behavior you are both expecting.   They are designed for a user to designate the fields applicable to the HR Service during configuration.   When the HR Service field changes on a case, the "Show HR service fields" client script is triggered to show/hide the fields based on the new HR Service.



The problem you may both be encountering is that the client script only runs on field change and therefore the new field will display until another HR Service is selected and triggers the field to be hidden.   There is an additional piece of configuration necessary for these situations with custom fields.   The "Hide HR service fields and related lists" UI Policy is used to indicate what fields should be hidden on page load so you'll want to configure your new custom field to be not visible here.



Also, there is a known issue right now with not being able to select fields from a COE table since the UI Policy is set to HR Case.   A temporary workaround is to switch the UI Policy to the COE table, save, add your COE specific fields to the UI Policy Actions, and then switch the UI Policy back to HR Case.   We are exploring alternate solutions for this in future releases.



We realize this information is not well documented so I'll work with the team to ensure it is gets added to the product documentation.


View solution in original post

15 REPLIES 15

SanjivMeher
Kilo Patron
Kilo Patron

If Service is the parent table and HR service is the child table, any field you create in parent table will also inherit to child table. You will have to remove it from your form if you dont want to use it.



Please mark this response as correct or helpful if it assisted you with your question.

This question was within the context of the relationship between COE forms and the relationship to HR Service specific fields, not a parent/child relationships on a form.


Kiel Sanders
ServiceNow Employee
ServiceNow Employee

Hi Ali



Fields are associated at a table level, not down to the level of specific HR Services associated to those tables.   You will want to create most custom fields that you are referring to on the COE table unless it makes sense to share across all HR cases.   You can then use UI Policy to show/hide the fields based on the HR Service selected on the agent form.



Kiel


Hi Kiel,



Thanks for the response. I totally agree with the philosophy on adding fields to the COE versus the parent HR core case table. My inquiry is specific to the documented "Service table fields" list collector field on the HR Service. See here Create or modify HR services



The client script "Show HR service fields" will look at the fields listed in this collector and show/hide them if they are needed for the HR Service selected. This seems to work with OOB services. i.e. I select Beneficiaries Add/Modify as a service and the "Benefit Plan" field shows up on the Total Rewards Case form. If I select a different service that doesn't have the "Benefit plan" listed in it's service the field does not show. If I create a new service and have created fields for that on the case form, when I list them in the list collector they appear regardless.



find_real_file.png



I thought that this functionality would prevent me from creating the UI policy for every service that has custom fields. Is this the case or should that "Service table fields" work?