How to Display Multiple Columns in a List Collector on ServiceNow Service Portal

In ServiceNow, a List Collector is a catalog variable type that allows users to select multiple records from a list of available items. It presents a dual-pane selector (often called a slushbucket) where the left side lists available options and the right side shows selected items. This is commonly used in the Service Portal for catalog items or record producers to let users pick multiple entries (for example, selecting multiple users for an approval group) without having to create a long list of checkboxes.

By default, a list collector displays only a single column of information – typically the record’s display value (such as the Name for a user). In many cases, however, you may want to show more details for each option. For instance, if you are referencing the User table, you might have several users with the same name. Showing additional info like the user ID or email can help ensure the user selects the correct "John Smith". Displaying multiple columns in the list collector improves the user experience by providing more context for each listed record.

Understanding the Challenge

The challenge is that out-of-the-box Service Portal list collectors are limited to one column of display. The list collector will only show the field marked as the display value for that table (e.g. the full Name on the sys_user table). You cannot have more than one display field on a table, so only that one field is shown by default. In the platform’s native UI (UI16), there is a partial workaround: if you highlight or hover over an item in a list collector, the interface can display a preview with additional fields (such as first name, last name, email for a user) below the slushbucket. However, this preview functionality is not available in the Service Portal – in Service Portal, the list collector’s available list typically appears as a filterable drop-down without any hover preview. Users only see the single-column list of matching records, which can be problematic if the display values are not unique or descriptive enough.

Given this limitation, developers often seek a solution to show multiple columns of data for each entry in a Service Portal list collector. The goal is to make each option in the list more informative (e.g. showing an ID, name, and another attribute side by side). Fortunately, ServiceNow provides a way to achieve this using reference field attributes on the list collector variable.

Displaying Multiple Columns: Step-by-Step Solution

ServiceNow allows configuration of reference field behavior through variable attributes. By adding certain attributes to a list collector variable, you can enable a multi-column display in the auto-complete drop-down of the list collector. The key attributes to use are:

• ref_auto_completer=AJAXTableCompleter – This tells the list collector to use the AJAX Table Completer, which supports displaying tabular results (multiple columns) in the suggestion list. It essentially switches the autocomplete mode to a table format.

  
  

• ref_ac_columns=<field1>;<field2>;... – This specifies the additional fields (besides the display value) you want to show in the list collector’s drop-down. The field names should be separated by semicolons. For example, ref_ac_columns=user_name;email would add the User ID and Email fields as extra columns in a user reference list. (You do not need to include the default display field here – the display field will always show as the first column).

  
  

• ref_ac_columns_search=true – This enables searching/filtering by the fields listed in ref_ac_columns. With this set to true, the auto-complete will match the user's search text against not only the display name but also the additional columns. This is highly recommended so that users can search by any of the visible columns (for example, typing an email address to find a user).

  
  

• (Optional) ref_ac_order_by=<field> – This sets the sort order of the results by a specific field. If not specified, results typically default to sorting by the display field. You can use this to sort by one of the additional columns (e.g. ref_ac_order_by=user_name to sort users by user ID, or any other field on the referenced table).

  
  

Below is a step-by-step guide to configure a list collector with these attributes:

1. Open the List Collector variable for editing: In your catalog item or record producer form, find the list collector variable (for example, Group Members or Affected CIs – any variable of type List Collector). Click the variable name to open its configuration. Make sure you switch to the Advanced view so that you can see all fields, including Variable Attributes.

   
   

2. Add the reference attributes: In the variable form, locate the Variable attributes field (often found under the Type Specifications or Additional Details section). Here you will enter the attributes mentioned above. For example, you might enter:

   ref_auto_completer=AJAXTableCompleter,ref_ac_columns=name;user_name;email,ref_ac_columns_search=true

   
   

   This string of attributes would configure the list collector to use a table completer and display the Name, User ID, and Email for each user in the list. Ensure that each attribute is separated by a comma. The screenshot below shows how the attributes are added for a list collector variable in the catalog item configuration:

   Configuring the list collector variable with multiple column attributes. In this example, the attributes will cause the list to show the user's Name and User ID columns in the Service Portal.

   
   

   After entering the attributes, save/update the variable. (If your list collector was already on a catalog item form in the portal, you may need to refresh the page to see the changes.)

   
   

3. Test the list collector in Service Portal: Navigate to the catalog item or form in the Service Portal and try using the list collector. Click into the list collector’s search box or start typing to filter. You should now see multiple pieces of information for each result. For example, if we configured the user list collector with Name and Email, the drop-down might show a table of results where one column is the Name and another is the Email address for each user. The first column will always be the record’s display value (e.g. Name), followed by the columns you specified.

   
   

   Example of a reference field auto-complete displaying multiple columns (e.g., an Incident list showing Number, State, and Opened By). This is the effect of using ref_auto_completer=AJAXTableCompleter with ref_ac_columns – the suggestions are shown in a table format with extra fields for clearer identification.

   
   

   You’ll notice in the results above that there are no column headers, but the values are spaced out as separate columns. For instance, in a user list, you might see entries like “Jane Doe jdoe jane.doe@example.com” all on one line – which corresponds to Name, User ID, and Email respectively. This provides much richer detail than just “Jane Doe” alone. The user can also search by any of those fields (for example, typing “@example.com” would match the email column if ref_ac_columns_search=true is set).

   
   

4. Adjust as needed: If you want to include different fields, simply change the ref_ac_columns list. You could add more fields or remove some, but be cautious not to include too many columns as the drop-down can become cluttered and hard to read. In most cases, two or three columns (including the primary display value) are sufficient to uniquely identify a record. Also consider using ref_ac_order_by if the default sorting isn’t ideal – for example, you might sort by a name field alphabetically or by an ID. Add this attribute to the same Variable attributes field (e.g., append ,ref_ac_order_by=email to sort by email address).

   
   

By following the above steps, you configure the Service Portal list collector to show multiple columns. This solution leverages built-in platform capabilities (reference field attributes) rather than requiring any custom code. Once set up, it should work for both catalog item variables and record producer variables, even on custom tables, as these attributes are supported in those contexts.

Handling Additional Filters with Reference Qualifiers

In many scenarios, you’ll not only want to display multiple columns, but also filter which records appear in the list collector. For example, you might want to show only active records, or filter the options based on another selection the user made (dependent variables). This is achieved using the Reference Qualifier on the list collector variable.

ServiceNow provides a Reference qualifier field for variables, where you can specify conditions to restrict the query for the available options. You can set a static filter (using a condition builder or encoded query string) or a dynamic filter using a script. The good news is that using a reference qualifier does not conflict with the multi-column setup – you can use both together. Below are some tips for handling filters:

• Simple Condition Qualifier: If your filter is straightforward (for instance, only show active records), you can use the condition builder in the Reference qualifier field. For example, set Active is true. This ensures the list collector only fetches active entries. In an encoded query format, this would be active=true. You can also directly type an encoded query string (like active=true^category=Hardware) into the qualifier field for more complex static conditions.

  
  

• Dynamic Qualifier (Dependent variables): Often, one list collector depends on another field. For example, you have a Group reference, and a list collector of Group Members that should show users in the selected group. In such cases, use an Advanced reference qualifier with a script that builds the query using the value of the other variable. For instance, suppose your first variable is department and the list collector should show active users in that department. You could write the reference qualifier as:

  javascript:"active=true^department=" + current.variables.department;

  
  

  This script concatenates an encoded query string using the current selection of the department variable (make sure to use the correct variable name). The above example would ensure the list collector only shows users who are active and whose Department matches the selected department. Another example, as shown in ServiceNow’s documentation, for filtering group members by a selected group: javascript:"group=" + current.variables.v_group will restrict a list collector to users of the group chosen in variable v_group.

  
  

• Ensure the qualifier updates on changes: When using a dynamic reference qualifier that depends on another variable’s value, add the ref_qual_elements attribute to the list collector’s Variable attributes. This attribute should list the name of the variable(s) that the qualifier depends on. For example, if your list collector is filtered by a field called select_group, add ref_qual_elements=select_group in the attributes. This ensures that when the user selects a different group, the list collector knows to refresh its options (especially important in the platform UI; in Service Portal, it often updates automatically, but this attribute ensures consistency between Portal and backend).

  
  

• Compound Conditions: If you need multiple conditions, you can combine them in the script as shown above using the caret (^) to delimit each condition. Just be careful with the syntax (the entire script has to return a single encoded query string in quotes).

  
  

With these reference qualifier configurations, your list collector will not only show the extra columns, but also maintain whatever filtering logic you require. For instance, you can have a list collector showing multiple columns of only relevant records (e.g., only active, only in a certain category or related to another input). This makes the list collector both informative and precise in what it presents to the user.

Troubleshooting Common Issues

While configuring multiple columns in a list collector is straightforward, you might encounter a few common issues or questions. Here are some troubleshooting tips and best practices:

• Additional columns not appearing: If you added ref_ac_columns but don’t see the extra fields in the drop-down, double-check the spelling and existence of the field names. The fields must exist on the target table and be spelled exactly as the column name (case-sensitive). If a field name is wrong or doesn’t exist, the auto-complete might simply show a blank space for that column or ignore it. The drop-down will always show the display field first, then the specified columns in order – so if one column is consistently blank, that’s a clue the field name might be incorrect or the field has no data. Remove or correct any non-existent column names to fix the display. Also note that you cannot show related records’ fields (only fields on the referenced table), unless those are brought in via dot-walk in the reference qualifier or similar advanced setups.

  
  

• Search isn’t filtering by the new columns: If you can see the extra columns but typing into the filter only matches the primary display field, ensure you included ref_ac_columns_search=true in the attributes. Without this, the auto-complete will only query the display value field for matches. Setting this to true allows queries on the additional columns as well. If you have set it and it’s still not working, verify that the field types are searchable (most are, but if a field is not text or has special query constraints, it might behave differently).

  
  

• Sorting or result order is not as expected: By default, results may be ordered by the display value or by relevance to what’s typed. If you want a specific sort (say, always alphabetical by a certain field or descending by date), use the ref_ac_order_by attribute. For example, to sort the user list by user_name, add ref_ac_order_by=user_name. Remember that the sort field doesn’t have to be one of the visible columns – you could sort by a hidden field if desired. If multiple order-by fields are needed, you might not have that level of control with a single attribute (it supports one field). In such cases, consider making your reference qualifier return a pre-sorted result (though that’s advanced). Usually one field sort is enough for user experience.

  
  

• Selected items only show one column of info: This is expected behavior. The list collector’s selected list (the right-hand side of the slushbucket or the tags of selected values in Service Portal) will display the record’s display value only. The additional columns are for the selection phase (left side drop-down) only. In the native UI, you could at least hover to see more details once selected, but as noted, Service Portal doesn’t show the hover preview. After selection, the user will just see something like a list of names. If it’s important for the user to see more info about what they selected after picking, you might consider adding UI hints. For example, you could include a client-side script to display a confirmation or additional info in a read-only field once selections are made, or instruct the user that they can click the info icon (in platform UI) to open the record if needed. In Service Portal, each selected item may have a remove (x) icon but not a direct info icon by default. A workaround is to make the display value itself more descriptive. Some admins choose to set the display value of the table to a composite (like a concatenation of name and ID), so that even the single column conveys more information. This, however, changes how the field appears everywhere, so use caution before altering a table’s display value for this purpose.

  
  

• Fields disappear or get cleared on selection: Sometimes users report that additional fields seem to vanish when an item is chosen. What actually happens is that once you select an item from the filtered results, the drop-down closes and the filter input may clear (in preparation for a next search). This can give the impression that the info “disappeared.” In reality, the item was added to the selected list (check the right-hand selected list or the token showing the selected value). You can then search for another item. Note that the list collector in Service Portal typically adds one selection at a time; after each selection you may need to search again for the next entry. This is normal behavior (the control isn’t designed for multi-selecting several entries in one go without closing the drop-down). Just instruct users as needed: type to find a record, select it, then repeat to add multiple entries.

  
  

• Ensuring performance with large lists: If the reference table has a huge number of records (thousands), pulling multiple columns for all of them could have performance implications. Usually, the auto-complete only fetches a limited set of results (e.g., first 50 matches) so it’s efficient. But if your list collector is unrestricted and users attempt wildcard searches that return many records, the multi-column rendering could be slightly slower than single-column. To mitigate any issues, use reference qualifiers to limit scope (e.g., filter by active, category, etc., as discussed) or encourage specific searches. You can also set a property to limit the maximum number of search results. ServiceNow by default might show up to 50 or 100 results in a reference auto-complete; consider if you really need more than that. There is a platform property glide.xmlhttp.excessive that controls how many items are shown in reference lists – though typically you won’t need to change this unless you face performance problems.

  
  

By addressing the above points, you can avoid common pitfalls when customizing list collectors. In summary, double-check your attribute syntax and field names if something isn’t working, and remember that the multi-column display mainly aids in the selection interface, not in how the selected values display afterward.

Alternative Approaches to Enhance List Collector Functionality

The method of using reference attributes is the most straightforward way to show multiple columns in a list collector. However, depending on your requirements, there are other approaches or enhancements you might consider:

• Using Multi-Row Variable Sets (MRVS): If your goal is to capture multiple pieces of information for each selection (not just to display them), a Multi-Row Variable Set might be a better fit. Introduced in the London release, MRVS allows you to present a grid (table) in a catalog item where each row can contain multiple fields of input. This is useful if, for example, you want the user to provide additional details for each item they would otherwise select in a list collector. MRVS can sometimes replace the need for a list collector by providing a mini-form for each entry. Keep in mind MRVS comes with its own learning curve and limitations, but it’s an out-of-the-box alternative for scenarios where list collectors fall short (especially when you need more than just selecting references).

  
  

• Custom Display Value or Field Concatenation: As mentioned in troubleshooting, one simple (if blunt) approach to show more info is to modify the display value of the referenced table to include multiple pieces of data. For instance, some organizations set a user’s display name to “Name (UserID)” so that even a single-column reference shows both. You can do this by creating a new field (or using an existing one) that concatenates other fields via a business rule or calculated field, and mark that as the display field. However, use caution – changing a table’s display value affects all references to that table globally. It might be acceptable for a custom table (created specifically for that one list collector scenario), but doing this on a core table like User or CI could have unintended side effects across the platform. So, this approach is only viable in limited cases. It’s more of a last resort if the attribute solution isn’t possible for some reason.

  
  

• Custom Widgets or Client Scripts: If you have very specific UI needs, you could build a custom Service Portal widget to replace the standard list collector interface. For example, you might design a widget that presents a list in a modal with a multi-column HTML table where users can check multiple rows and submit. That widget would then pass the selected values back to the form (perhaps storing them in a hidden field or the list collector itself). This approach gives you complete control – you could even include column headers, formatting, or interactive filtering. The downside is that it requires significant development effort (AngularJS/Service Portal widget development and maybe GlideAjax to fetch data) and maintenance. For most cases, the built-in list collector with attributes is sufficient, but a custom widget is an option if you need a truly tailored experience.

  
  

• UI Policy / Client-side Enhancements: Another idea for enhancing list collectors is using client scripts or UI policies. While you cannot directly make the OOB list collector show multiple columns via client script, you could use a script to dynamically filter options (setting the qualifier dynamically using g_form for instance) or to display additional info elsewhere on the form when a user selects something. For example, if a user selects a record in the list collector, a client script could populate a read-only text field with details about that record (like a summary). This isn’t showing multiple columns in the list collector, but it is providing more context on the form. It’s a creative way to supplement the user’s understanding without modifying the list collector itself.

  
  

In general, before resorting to complex solutions, evaluate if the combination of reference qualifiers and ref_ac_columns attributes meets the requirement – often it does. The multi-column auto-complete along with a well-chosen filter makes the list collector much more usable. Alternative approaches are good to know about for edge cases: for example, MRVS for multi-field inputs per entry, or custom widgets for a totally bespoke selection process.

Conclusion

Customizing a Service Portal list collector to display multiple columns is a powerful way to improve the user experience in ServiceNow. By default, list collectors only show one column (the display value) which can be limiting, but with a few configurations we can overcome that limitation. The key takeaways and best practices from this discussion include:

• Use reference attributes to show multiple columns: Adding ref_auto_completer=AJAXTableCompleter along with ref_ac_columns for the fields you want to display is the primary solution. This enables a table-like dropdown so users can see, for example, a Name, ID, and Email rather than just a Name. Always include ref_ac_columns_search=true to allow searching by those fields as well, making the feature truly effective.

  
  

• Keep it relevant and manageable: Only display the columns that add value. Too many columns can overwhelm the user or clutter the UI. Two or three well-chosen fields (including the default display value) are usually enough to uniquely identify a record. For instance, an asset list might show “Asset Tag” and “Serial Number” next to the asset name – that’s usually sufficient. Also, be mindful of performance; more columns means more data to retrieve. In practice this isn’t usually an issue for small result sets, but always test with realistic data sizes.

  
  

• Leverage Reference Qualifiers for filtering: A multi-column list collector is most useful when it’s not showing an unbounded list of everything. Use reference qualifiers to filter the options (e.g., by status, category, or another user selection). This not only improves performance but also helps the user by narrowing choices to relevant ones. We showed how you can use static conditions or dynamic scripts in the qualifier. Also remember the ref_qual_elements attribute if your qualifier depends on other variables, to ensure a smooth, interactive filtering experience in all interfaces.

  
  

• Test in the Service Portal: After making these changes, always verify the behavior in the Service Portal (and in the native UI if your catalog item might be used there too). The portal may have slight differences in how it renders list collectors, so ensure that the multi-column display works as expected. Try searching by each of the additional fields to confirm ref_ac_columns_search is effective. Additionally, have a look at how the selected items appear to the end-user and adjust any help text or field labels to make it clear what is being shown.

  
  

• Further learning: To deepen your understanding, you can refer to ServiceNow’s official documentation on Reference field auto-complete attributes (which covers ref_auto_completer, ref_ac_columns, etc.) and how they work. The ServiceNow Community forums are also an excellent resource – many developers have shared tips and solutions for list collector customization (for example, threads where the solution of adding these attributes is discussed and confirmed to work). Searching the community for “list collector multiple columns Service Portal” will yield Q&A posts (like those cited in this article) that can provide additional context and examples. If you prefer video tutorials, there are webinars and YouTube videos by ServiceNow experts demonstrating how to configure reference field attributes and list collectors step-by-step.

  
  

By following the guidance in this article, you should be able to transform your ServiceNow Service Portal list collectors into more user-friendly components. Users will appreciate seeing more information at a glance, reducing ambiguity when selecting from large lists. As with any customization, remember to follow best practices: document your changes (e.g. note in the variable description that certain attributes are in use), and avoid hard-coding values that might change (use dynamic qualifiers instead). With these enhancements, the humble list collector becomes a much more powerful element of your ServiceNow forms, improving both usability and accuracy of user selections. Happy developing!