How to display related records as a table in Jira issues with Elements Connect's new Table field
How to display related records as a table in Jira issues
When you enrich a Jira issue or a JSM request with external data, a single value is easy: a customer name, a status, a price. The moment you need to show several related records for that value - the contacts tied to an account, the deals tied to a customer - a single field stops working. You either flatten everything into one unreadable string, or you build several disconnected fields and lose the mapping between rows.
I'm Etienne, Product Marketing Manager for Elements Connect at Elements Apps, and this is a case we hear about often enough to be worth a walkthrough: showing a customer's contacts and deals, pulled from a CRM, as two proper tables on a JSM request, instead of a wall of comma-separated text. Happy to discuss fit in the comments, including where this isn't the right tool.
The problem: related records don't fit in a single-value field
Picture a JSM portal used to manage RFP (request for proposal) requests from sales reps, on behalf of leads tracked in a CRM. When a rep raises a request for a given customer, the pre-sales agents processing it want to see, at a glance:
-
who the contacts are for that customer (name, e-mail)
-
what deals are open or closed for that customer (amount, stage, close date)
Doing this with a single read-only field means concatenating everything into one string, fine for one contact, unreadable for five. Splitting it into several fields, one per attribute, breaks the relationship between rows: nothing ties a given e-mail back to the right contact anymore.
What's needed is a field that keeps rows and columns together, the way a table does.
What we're building
We want to create three connected custom fields made with Elements Connect. They are native Jira custom field whose value is fetched from an external data source (REST API, database or another Jira project) instead of entered manually.
We put our fields on a JSM request type, all fed from a CRM (HubSpot, in this example):
-
Customer: a select list that retrieves customers available in HubSpot based on what the user is typing (in case the list of customer is huge). This is the parent field of the other two listed below.
-
Contacts: a table listing each contact tied to the selected customer, with last name, first name and e-mail as columns.
-
Deals: a table listing each deal tied to the selected customer, with deal name, amount, stage and close date as columns.
Both table custom fields are read-only: agents see the data, they don't edit it here.
Prerequisites
-
HubSpot (or another CRM/REST API/database) as your data source
-
Elements Connect installed on your instance
1. Connect your CRM as a data source
Configure HubSpot as a REST API data source in Elements Connect. The exact authentication and endpoint setup is covered in Configure HubSpot as a datasource, a similar pattern applies to any REST API or database you'd rather use instead.
2. Create the Customer parent field
Before the two tables can show anything, we need a field for reps to pick which customer the request is about. Create a connected custom field named Customer, of type Select list (single choice), on your HubSpot data source.
-
What it fetches - companies in HubSpot whose name matches what the rep is currently typing, rather than the full company list at once.
-
What the rep sees - a search-as-you-type dropdown of customer names.
This is a dependency on what the user is typing rather than a static list, useful once your CRM holds more accounts than you'd want to load in one dropdown. The exact endpoint and query for this field are detailed in the "Customer" section of the full HubSpot tutorial.
This field is the parent both Contacts and Deals will depend on next: whatever the rep selects here is what filters the two tables below.
Be aware that you can now validate your template directly in the app admin with our Template tester, built into the configuration.
3. Create the Contacts table
Create a connected custom field named Contacts, of type Table, on your HubSpot data source.
-
What it fetches - contacts associated with the customer selected in the parent "Customer" field.
-
Columns - Last Name, First Name, E-mail, each mapped to the corresponding property returned by the query.
The query itself (endpoint, filters, JSON path) follows the same fetch/filter steps as any other connected field. The exact request body and column templates for this example are detailed in How to integrate customer information and deals from HubSpot into Jira issues.
As you map each column, the Configuration tester lets you preview the rendered table against real query results before saving - worth checking each time you add or rename a column, rather than only finding out on a live request.
4. Create the Deals table
Repeat the same pattern for a second field, Deals, still on the HubSpot data source and still dependent on the "Customer" field.
-
What it fetches - deals associated with the selected customer.
-
Columns - Deal, Amount, Stage, Close date.
Same doc reference applies for the exact endpoint and column configuration.
5. Add both fields to your JSM request form
From each field's Actions menu, choose Add field to Portal, select your JSM project and request type, then drag both Contacts and Deals onto the request form, below the Customer field they depend on.
The result
Once a customer is selected on the request, pre-sales agents see two clean tables, contacts and deals, without opening HubSpot. No flattened strings, no disconnected fields to mentally re-associate row by row.
That also means agents get the full account context without switching tabs, and fewer people on the pre-sales side need an actual HubSpot seat just to check who a contact is or where a deal stands.
FAQ
Can users edit the values in a Table field? No, Table fields are read-only. They reflect what the query returns; they don't write back to your data source.
What is the maximum of results you can display in a table connected custom field? You can display for the moment a maximum of 10 rows and 5 columns in the table. It displays the first 10 results from the data source.
Does this only work with HubSpot? No. The example uses HubSpot because it's a documented, concrete case, but the same field type works with any REST API, database, or Jira project you already use as a data source in Elements Connect.
Is the Table field type new? Yes - it was introduced in Elements Connect 7.2 (August 2026), alongside a template preview in the Configuration tester to check column rendering before saving.
Does this replace Atlassian Assets or a dedicated CRM sync app? No. If your organization already uses Assets for this kind of record, or a two-way CRM sync app, those remain purpose-built for that job. This pattern is for displaying related, read-only records inline on an issue or request, without duplicating or syncing data.
Final thoughts
A single read-only field is often enough, until the data you're pulling in has more than one related record per value. At that point, flattening everything into one string or splitting it into several disconnected fields both lose information. A dedicated table keeps rows and columns together the way the source data actually looks.
It's not the right fit for everything: if you need users to edit the data, or keep two systems in sync both ways, look at a purpose-built sync app instead. But for showing related, read-only records - contacts, deals, or anything else with more than one attribute per row - it's a more honest representation than either alternative.
It's also worth noting what stays untouched: HubSpot remains the source of truth. Elements Connect reads the data at render time, it doesn't duplicate it into Jira or write anything back - so there's no sync to maintain and nothing to drift out of date. And this pattern isn't limited to contacts and deals: any CRM data that's useful to a support or delivery team - order history, subscription tier, past tickets - follows the same setup.
Was this helpful?
Thanks!
Etienne Frère_Elements
1 comment