question Re: Service table fields functionality not working? in HRSD forum

Service table fields functionality not working?

alijubran — Tue, 10 Oct 2017 20:54:17 GMT

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.

Re: Service table fields functionality not working?

SanjivMeher — Tue, 10 Oct 2017 21:04:25 GMT

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.

Re: Service table fields functionality not working?

alijubran — Wed, 11 Oct 2017 12:02:18 GMT

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.

Re: Service table fields functionality not working?

Kiel Sanders — Wed, 11 Oct 2017 13:11:10 GMT

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

Re: Service table fields functionality not working?

alijubran — Wed, 11 Oct 2017 13:25:32 GMT

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.

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?

Re: Service table fields functionality not working?

ludijormajordeb — Fri, 22 Dec 2017 14:56:31 GMT

Hi alijubran,

I have the same question. Did you managed to find the answer for it?

Kind regards,

Ludijor

Re: Service table fields functionality not working?

alijubran — Fri, 12 Jan 2018 21:47:25 GMT

Hi ludijormajordebarros,

I found that this functionality was limited to OOB case fields. I didn't explore it much past that and went with Kiel's suggestion to use UI Policies. I was hoping to get around the 'older school' way of setting visibility. Ex If HR Service is XYZ show these fields. Hopefully, there will be some more info on this functionality in later releases. If there is anything I find before that, I'll be sure to post!

Thanks,

Ali

Re: Service table fields functionality not working?

ludijormajordeb — Sun, 14 Jan 2018 11:46:11 GMT

Thank you alijubran!!

I was hoping the same, that would definitely help in terms of configuration. I think everyone was expecting that to be the behavior of the OOB functionality.

If I find anything about that I'll also be updating this post.

Kind regards,

Ludijor

Re: Service table fields functionality not working?

Kiel Sanders — Mon, 15 Jan 2018 14:48:13 GMT

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.

Re: Service table fields functionality not working?

mjepp — Mon, 15 Jan 2018 18:17:14 GMT

Hi guys,

I thought I would jump in on this since I was working through the same issue in Kingston. I was able to configure the functionality to work as expected by doing the following.

1: Created a new Service which created a Case on the "sn_hr_core_operations" table.

2: Added a custom field "HRITReason" to the COE table and added it to the form.

3: Modified the UI policy Kiel listed above, "Hide HR service fields and related lists". I did an insert and stay on the action as I could not create a new UI action from scratch.

Once I did this my new field displays on the case based on it being configured on the HR Service "Service Table fields".

Regards,

Matt

Re: Service table fields functionality not working?

alijubran — Mon, 15 Jan 2018 20:46:55 GMT

Matt, you are the MAN!!! Thanks for putting these steps up here.

Re: Service table fields functionality not working?

alijubran — Mon, 15 Jan 2018 20:48:03 GMT

Looks like this is it. The UI Policy was the missing ingredient.

Bascially, UI Policy hides -- Client Script shows based on HR Service

Re: Service table fields functionality not working?

ludijormajordeb — Tue, 16 Jan 2018 00:15:39 GMT

Thank you very much guys kielsanders alijubran mjepp

Re: Service table fields functionality not working?

dansieders — Mon, 07 Dec 2020 04:20:50 GMT

The "Hide HR service fields and related lists" UI Policy is assigned to the "HR Case [sn_hr_core_case]" table however the OOB UI Policy Actions have fields from the child tables already.

UI Policy; (note the table is sn_hr_core_case)

UI Policy Actions; (note the tables are the child tables)

Just 'Insert and Stay' on one of the OOB UI Policy Actions, that has the same child table as your custom field i.e HR Payroll Case.

Then update the UI Policy Action 'Field Name' to your custom field on the child table.

Cheers Daniel

Re: Service table fields functionality not working?

G24 — Tue, 14 Nov 2023 20:44:37 GMT

Hello @Kiel Sanders . Are you still with ServiceNow? Is there now some documentation on this feature? Where, please?

In my custom "HR Service" on the "HR Service Additional Information" tab, for field "Service table fields" I added ALL of the available fields (over 100 I believe), and only about 10 of them seemed to actually SHOW UP on a newly instantiated HR Case record. See here:

Re: Service table fields functionality not working?

michaelj_sherid — Tue, 14 Nov 2023 21:00:20 GMT

@G24 the functionality has changed a bit since 2018 when this post originated. If you have added your fields to the UI policy and they are not showing after configuring them in the HR Service, you may have scope issues. Are the fields created in the same scope as the table? In the newer functionality of Service Table fields, this can make a difference.

Regards,

Mike