SOW UI Builder create a contact card for a custom user field on incident table

[WasonJ1]

Hi,

On our incident table we have the caller_id field and a u_requested_for field. In SOW in the Record Information section there is a contact card for the caller_id user. We also want to have a contact card for our u_requested_for field which is also a reference to sys_user table. I have created a variant Record SNC page along with a Record Information SNC to customize what's displayed. However when I duplicated the existing caller_id contact card I can not figure out how to make it point to our u_requested_for field. I have tried creating a data source that pulls in record data but I do not know how to make that dynamic and when I try to set the subheading on the contact card, it is always blank. Any help would be greatly appreciated.

[rahulswami]

Hi @WasonJ1,

This comes down to two separate issues, making the data resource dynamic, and how the Contact Card component actually expects its data.

On making the data resource dynamic, a data resource follows the current record when its filter is bound to a value from the page context instead of a hardcoded sys_id. You likely already have a data resource fetching the incident record itself. Add a new data resource, a Lookup Record or GlideRecord type pointed at sys_user, and set its filter using context binding syntax that references the incident record data resource's u_requested_for value directly. That is what makes it follow whichever incident is open, instead of always pulling the same user.

On the blank subheading, this is the part that trips most people up. The Contact Card's properties, heading, subheading, badges, contact fields, are JSON shaped under the hood, and direct drag and drop data binding on those nested properties is unreliable. The recommended approach is to skip direct binding on the Contact Card and use a Scripted Property instead. Inside the script you get access to api.data and api.state, and you build the JSON object the card expects yourself, pulling name, title, or department straight from your new sys_user data resource output. That is almost certainly why your subheading stays empty even though the data resource itself may be fine.

So the path forward: clone your data resource so it queries sys_user filtered dynamically by u_requested_for, then instead of duplicating the caller_id contact card's bindings, add a scripted property on your new contact card that reads from that data resource and returns the full JSON structure including the subheading.

[WasonJ1]

Really appreciate your detailed response. I will be working on this today and tomorrow.