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 · Accepted solution]

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!

[eromlige]

After much head butting, yes, this is the correct path forward. Will be creating a junction table and building out the proper guardrails {BR's, indexes} to prevent duplicates from being created. Thank you for your input.

[Ankur Bawiskar]

@eromlige 

share some screenshots

[Tejas Adhalrao]

Hi @eromlige ,

In ServiceNow (Yokohama), a List Collector field and a Related List do not automatically sync unless both are using the same many-to-many (M2M) table in the background. A List Collector does not store values on the main table; it always saves selections in an M2M table. When you add a Related List from Configure → Related Lists, it may look connected to the List field, but if it is not pointing to the same M2M table, updates done in one place will not appear in the other. This is expected platform behavior. To get two-way sync, you must explicitly use the same M2M table for the List Collector (via dictionary attributes like m2m_ref_table) and for the Related List. Once both read and write to the same M2M table, changes will reflect correctly in both places.

To understand your exact setup better, please share screenshots of the List field dictionary (attributes), the Related List configuration, and a brief scenario of how you are adding records.