List Collector field data to Related List, bi-directionally

[eromlige]

ver. Yokahama

So I created a List field in a custom app I'm building, it's a reference to another table. No big deal, it allows a user to select multiple items, it works as expected.

After opening an item form for the table in question, I thought, "hmm, maybe people would prefer to add these via a related list as well...". So I go to the Additional Actions (hamburger) menu > Configure > Related lists and great there's a related list for the field in question.

I decide to try it, I add multiple items to the field (list collector), save, and expect to see  them to show up in the Related list, no go. I clear the field save again and add the choices via [Edit] on the Related list, save again and expect them to show up in the field, no go.

So what's the proper way to sync the Related List > List collector field, both ways so that my selections show up in both places whenever they're added to one of the places? And where is this data? I mean the related list is pointing to the field, right?  

[Matthew_13]

You didn’t do anything wrong; this is one of those areas where ServiceNow looks like it should work, but doesn’t by design.

A list collector field and a related list are actually two completely different data models, even though the UI makes them feel interchangeable.

The list collector stores its values as a comma-separated list of sys_ids in a single field on the record. A related list, on the other hand, shows child records from another table, where each row is its own record with a reference back to the parent. Because the data lives in different places, there’s nothing for ServiceNow to “sync,” so adding values in one place will never automatically show up in the other.

That’s why:

• Adding items in the list collector doesn’t create rows in the related list

• Adding rows in the related list doesn’t populate the list field

If users really want to manage these via a related list, the best approach is to model this as a child table with a reference back to the parent, and drop the list collector entirely. That gives you true add/remove behavior, reporting, and future flexibility.

If the list collector works fine on its own, the simplest answer is to stick with the list collector and remove the related list, so you don’t give users two UIs that don’t agree.

It’s a frustrating discovery, but it’s a classic ServiceNow gotcha  once you know it, the design choice becomes much clearer.

Hope Help my Friend

@eromlige - Please mark as Accepted Solution and Thumbs Up if you found Helpful!