Omnitable Configuration Guide

Bullhorn Recruitment Cloud’s Omnitable Generic/reusable component that can be added to pages to show a fully configurable/customizable list of records and actions. is a generic, reusable component that can be added to pages to show a fully configurable and customizable list of records and actions.

It was designed to mimic and expand upon the existing Salesforce List Views, providing both consistency with the platform native behavior and additional functionality for Bullhorn Recruitment Cloud users.

Below are the Omnitable features:

• Customizable Columns
• Column Sorting and Custom Sorting
• Custom column renderer
• Infinite Scroll
• Support for Packaged and Custom Actions
• Support for Nested Menus (Actions)
• Support for Contextual Data Viewer
• Saved Omnitable Views comprising filtering and selected columns to display.
• Quick Search (no configuration options)
• Column Filtering (no configuration options)

 

System Requirements

Bullhorn Recruitment Cloud 2025.06

Configuration

Step 1: Omnitable Basic Configuration

Add an Omnitable as Standalone or as Related Lis to any object then configure what fields to display.

At its most basic, an Omnitable can simply be a list of records from an object displayed in table format where the columns of the table are fields from that object. Users will be able to see the data, configure the columns, do some filtering, sort and order the data.

For the basic configuration, navigate to the following location:

• Setup > Custom Metadata Types > Named Setting (BH4SF) (TR1__Named_Setting__mdt)

During the configuration, please be aware of the distinction between these two fields:

• Default Configuration: This field is intended to be read-only for customers (if configurations are packaged). In this way, it will be updated on upgrades.
• Configuration: This field is for the customization of packaged Omnitables. After upgrading, customers can see the updated default, and easily revert to it if desired.

The configuration for each Omnitable is stored as JSON on the Named Setting Custom Metadata Type, with a Name prefix of "Omnitable_" followed by the apiName of the Omnitable configuration.

This apiName is used to link an Omnitable instance to its configuration. The JSON is then stored in the Configuration field of the Named Setting record.

Please be aware of the distinction between these two fields:

• Default Configuration is intended to be read-only for customers (if configurations are packaged). In this way, it will be updated on upgrades.

• Configuration field is for the customization of packaged Omnitables. After upgrading, customers can see the updated default, and easily revert to it if desired.

At its most basic, an Omnitable can simply be a list of records from an object displayed in table format where the columns of the table are fields from that object. Users will be able to see the data, configure the columns, do some filtering, sort and order the data.

Available JSON Configuration Settings

The Baseline Configuration section of the JSON Configuration Settings table lists the minimum configuration required to create an Omnitable that can be added to a page layout:

• Object name
• Field set to be referenced to define the table columns,
• Chunk size for the infinite scroll behavior

You can then start adding more functionality to the baseline configuration, like for example by defining which field/column the table should be ordered by default, or referencing a second field set to define the ‘available’ columns for the users (if different from the default list of columns), or adding Actions: the remaining settings listed under ‘Baseline Configuration’ cover all the functionalities currently available to the Omnitable:

• Add an Omintable to an object as related list
• Define the set of columns available to the end user to customize the columns of the Omnitable
• Default Sort Order for the Omnitable
• Add Actions
• Define Action When used in ATS or Search and Match UI, one of multiple actions available after user has selected a sub-set of Candidates Categories (if using Nested Menus for Actions dropdown)

The remaining sections of the Omnitable Additional Resources list the settings available to further customize each functionality.

• Column Configuration
• Sort Configuration
• Action Configuration/Action Variable Mapping
• Action Categories
• Record Type Override

Step 2: Add an Omnitable as ‘Standalone’ or as ‘Related List’ to any object

1. Go to Setup> Lightning App Builder and click on the New button to create a Lightning Page.

2. In the next three screens, select:

   • Type=‘App Page’

   • Label= Omnitable (or any preferred name)

   • Layout=‘One Region’

3. Once the Lightning App Builder editor opens for the page you created, pick Omnitable from the left-hand side list of Custom-Managed items and pull it onto the page

   

4. On the right-hand side of the page, the Omnitable API API, or Application Programming Interface, is used by customers to create custom career portals or to take advantage of Data Mirror/DataMart. Bullhorn prefers to use REST API. Name needs to be filled with the value from the Named Setting(BH4SF) Name field on the Named Setting(BH4SF) record minus the Omnitable_ prefix

5. Finally create a tab to access the Omnitable. Go to Setup > Tabs>Lightning Page Tabs and click on New: retrieve the name of the Lightning Page you create from the Lightning Page lookup and fill in the remaining mandatory fields

6. If adding the Omnitable to an object as a Related List, please note the following:

   1. The JSON configuration must contain a value for the ‘contextFilterFieldName’ Json string: it’s whatever field on the primary object that links it with the context object. For example if you are adding a Call List Members Omnitable to a Call List: "objectName" = TR1__Call_List_Member__c and “contextFilterFieldName” = TR1__Call_List__c

   2. If you are adding the Omnitable directly on the page, the ‘context’ is picked up automatically

   3. when used in a Flow Screen, the property ‘Context Record Id’ is available to pass in the parent record id

   If adding the Omnitable to an object as a Related List, please note the following:

   1. The JSON configuration must contain a value for the ‘contextFilterFieldName’ Json string: it’s whatever field on the primary object that links it with the context object. For example if you are adding a Call List Members Omnitable to a Call List: "objectName" = TR1__Call_List_Member__c and “contextFilterFieldName” = TR1__Call_List__c

   2. If you are adding the Omnitable directly on the page, the ‘context’ is picked up automatically

   3. When used in a Flow Screen, the property ‘Context Record Id’ is available to pass in the parent record id.
      

Step 3: Configure Omnitable Features Column Customization

The Customize Column control opens the ‘Customize Columns’ modal that shows to the user:

• Selected Columns: the fields shown or moved here will appear on the UI as Omnitable columns

• Available Columns: a set of fields configured by the System Admin for the specific Omnitable instance and that can be manually added to the Omnitable by the user

Save Custom Columns set based on Record Type

The following settings are used in the configuration JSON stored in TR1__Named_Setting__mdt to populate the ‘Selected Columns’ and ‘Available Columns’ modal sections :

• DefaultFields: The fields from the fieldset referenced in this JSON string will populate the ‘Selected Columns’ modal sections when the Omnitable is opened by the user for the first time
• AvailableFields: The fields from the fieldset referenced in this JSON string will populate the ‘Available Columns’ modal sections

To simplify, defaultFields and availableFields settings are used to define the fieldsets (table columns) at the table level.

There is a third setting called contextRecordTypeOverrides which allows the admin to override the table level settings for specific contextual record types (this is obviously only relevant for Omnitable used as related lists, not for standalone Omnitables).

contextRecordTypeOverrides is an array of overrides, one per record type, which specifies the contextual record type the override applies to, and the fieldsets to use for that record type.

Custom Column Renderer

A Custom Column Renderer is a custom component that is used to render the data for a specific column in the table. There are three parts to the configuration of a custom column renderer for an Omnitable instance:

1. Install Bullhorn LWS package in the Org where the Omnitable instance is configured.

   Important:Tthe subscriber’s Org must have Lightning Web Security enabled (Setup > Session Settings > Use Lightning Web Security for Lightning web components and Aura components must be set to True). Custom column renderer is not supported in Orgs where this setting is not enabled.
2. Use the omnitablePlus component that comes with the Bullhorn LWS package to add the Omnitable to the page, not the Omnitable component that comes from the TR1 package.

3. Configure the column for your Omnitable instance using the configuration JSON

   • Add the renderer element when configuring the Omnitable columns using the columnOverrides JSON attribute
     • Renderer requires the full name of the LWC used to render the data in the table:
       • If it's in a namespace, use the format "namespace/componentName".
       • If it's not in a namespace, use the format "c/componentName".
   • Configure the virtual column (see section below).

Virtual Column

When using Custom Column Renderer, you can also configure a Virtual Column. Virtual Columns are perfect for when you want the Users to be able to choose between different "views" for the same field.

If you don't specify virtualName then the column overrides, including renderer and label, will simply be used for that column

A Virtual Column is a column that does not exist in any fieldset but it might be used in order for the 'rendered' data to be displayed on the Omnitable. Once configured, this virtual column will become available in the Omnitable ‘Customize Column’ modal and users will be able to add it to the Omnitable UI.

The columnOverrides attribute in Baseline JSON Configuration can be used to configure various overrides that apply to a specific column on the table. If you add virtualName to the JSON configuration for columnOverrides, then this config will form the basis for a brand new column created alongside the original column for that field, following the same rules for availability and default visibility.

Conversely, if columnOverride does not specify a value for the virtualName property then that config will only apply to the original non-virtual column for the field.

Now admins can use the virtual column to display data rendered as images like chevrons, etc. (the original column can then be removed from the table).

"columnOverrides":[{

"virtualName":"Test",

"label":"Stage 2",

"fieldName":"TR1__Stage__c",

"renderer": "tr1/omnitableChevronPath"

},{

"label":"Stage 1",

"fieldName":"TR1__Stage__c"

}]

The virtualName must be unique across all columnOverride definitions in a given JSON configuration.

Sorting and Filtering Exceptions

Filter Field Override

To enable users to sort/filter a column that displays data not stored in the database (as is the case of the custom column renderer, for example), specify an alternative "sortable" field that Omnitable can then use behind the scenes to sort the column while still displaying the original column data.

To configure this, set a filterField and a sortField in the columnOverrides section of the configuration JSON.

JSON Example: For a formula field displaying an image URL that you want to filter/sort by its text value instead:

Hide filtering/sorting option

To prevent users from trying to sort/filter columns where it won't work, you can use the below attributes in the configuration JSON. This results in hiding the sort/filter options for columns that don't support that.

• disableSorting : When true, sorting will be disabled for this column

• disableFiltering : When true, filtering will be disabled for this column

Omnitable Actions Configuration

Once you have completed the basic configuration required to add an Omnitable to a chosen object, you can proceed and add Actions to that Omnitable: in Omnitable, Actions are added by wrapping them in Flows and then referencing the Flow in the JSON configuration.

As mentioned above, the configuration JSON stored in TR1__Named_Setting__mdt has an ‘Actions’ string that supports various configuration elements.

Packaged ATS Actions for Omnitable

A selection of ATS Actions is available to be added to an Omnitable on Job or Contact records in a few simple steps. By tweaking the OOTB Configuration JSON you can:

• Add/remove actions (custom actions are supported)
• Change the order of Actions in dropdown (by changing the order of the action in JSON)
• Configure actions based on record type
• Display the action either in the Action dropdown or as an icon to the left of the dropdown
• Change the icon

Add ATS Actions to an Omnitable on Job Records

1. Go to a Job record >Cog setting on the top right of page> Edit Page to open the Lightning App Builder for that page

2. Add a tab for the Omnitable or replace an existing tab

3. Drag and drop the Omnitable component from the ‘Custom-Managed’ list of components on the left hand side into the tab space.

4. Enter ‘JobATS’ in the ‘Omnitable API Name’ field on the right

   1. 

5. Go toSetup>CustomMetadataTypes>NamedSetting(BH4SF)>Omnitable_JobATS

6. Open the Omnitable_JobATS record to see what ATS actions are configured out of the box and how they are configured. You can copy and paste the JSON configuration from the ‘Default Configuration’ field to the ‘Configuration’ field if you want to make any change to it

Add ATS Actions to an Omnitable on Contact Records

1. Go to a Contact record >Cog setting on the top right of page> Edit Page to open the Lightning App Builder for that page
2. Add a tab for the Omnitable or replace an existing tab
3. Drag and drop the Omnitable component from the ‘Custom-Managed’ list of components on the left hand side into the tab space.
4. Enter ‘CandidateATS’ in the ‘Omnitable API Name’ field on the right
5. Go to Setup>Custom Metadata Types>NamedSetting(BH4SF)> Omnitable_CandidateATS
6. Open the Omnitable_CandidateATS record to see what ATS actions are configured out of the box and how they are configured. You can copy and paste the JSON configuration from the ‘Default Configuration’ field to the ‘Configuration’ field if you want to make any change to it

Omnitable Contextual Data Viewer

In BHRC we have four packaged Contextual Data Viewer Flows:

• Omnitable Contact Contextual Data Viewer (Below Omnitable)
• Omnitable Contact Contextual Data Viewer (Right of Omnitable)
• Omnitable Job Contextual Data Viewer (Below Omnitable)
• Omnitable Job Contextual Data Viewer (Right of Omnitable)

In order to have Omnitable instead of the Contextual Data Viewers ‘Data Tables’ and ‘BH Bullhorn, our flagship product. Data Fetchers’ in those Flows, users will need to create an Omnitable Configuration for each Contextual Data Viewer instance.

Create a Field Set

1. Go to: Setup > Object Manager > Employment History > Field Sets
2. Create a new Field Set:
   • Name: Omnitable_Default_CDV.
3. Add Required Fields

Create Custom Metadata Type with JSON Config

1. Go to: Setup > Custom Metadata Types > Named Settings (Manage Records) > New

2. Use the following as a guide, this example is to configure the Employment History tab:

• Label: Omnitable_EmploymentCDV
• Name: Omnitable_EmploymentCDV
• Schema: /resource/TR1__OmnitableConfigurationSchema
• Use the following JSON Configuration:
Copy

{
  "objectName": "TR1__EmploymentHistory__c",
  "defaultFields": "TR1__Omnitable_Default_CDV",
  "contextFilterFieldName": "TR1__Contact__c",
  "infiniteScrollInitialChunkSize": 50,
  "infiniteScrollChunkSize": 20,
  "actions": []
}

 

Replace the Data Tables in the Flow with Omnitables:

1. Go to: Setup -> Flows -> Omnitable Contact Contextual Data Viewer (Below Omnitable)
2. Open the Screen
3. Delete the Data Table for Employment History (note the Set Component Visibility conditions first, to preserve the behaviour of the tabs)
4. Save and reopen the Screen (the following step would be prevented otherwise)
5. Delete the Data Fetcher for Employment History
6. Add an Omnitable component where the Data Table was
7. API Name: EmploymentOmnitable
8. Context Record Id: {!highlightedContactId}
9. Omnitable API Name: EmploymentCDV
10. Set Component Visibility: replicated from the above

Ensure the Correct Omnitable + CDV component is on the Relevant Page Layout

In order to see the Omnitable, ensure the corresponding Omnitable component is included on the appropriate page layout.