Adding Received Emails to Source-to-Pay Workspace: S2P Config Byte Article

Astrid Sapphire
ServiceNow Employee

yesterday

Adding Received Emails to Source-to-Pay Workspace


This article accompanies the S2P Config Byte on adding received emails to the Source-to-Pay Workspace. It covers the same four configuration steps as the video, and provides the tables, properties, and JSON structures involved for ease of access.


 

Overview

This article is a written companion to the S2P Config Byte video on adding received emails to the Source-to-Pay Workspace. It covers the same four steps, with extra detail on the tables and client state parameters involved. If you're implementing this and want something to refer back to without rewatching the video, this is what you need.


Family release: Zurich

Monthly release: December 2025

Store applications:


Step 1: Create the relationship


Out of the box, the Procurement Case record has no relationship defined for received emails — only sent and draft. To surface received emails in the workspace, you first need to create that relationship explicitly in Core UI.


Navigate to the sys_relationship table (you can do this via the filter navigator). You'll see existing relationships for the Procurement Request and Task tables already defined here — the one you're adding follows the same pattern.


Create a new record with the following values:


  • Applies to table: Procurement Case (sn_spend_psd_procurement_request)
  • Query from table: sys_email
  • Name: Received Emails
  • Script: A script that filters sys_email records by the current record's sys_id and table, using the Document ID and table reference fields on the email table

The script is necessary because the email table uses Document ID and table references rather than a direct foreign key — so you can't just point at a field the way you would for a standard relationship. Here's the script to use:

(function refineQuery(current, parent) {
    current.addQuery('target_table', 'sn_spend_psd_procurement_request');
    current.addQuery('instance', parent.sys_id);
    current.addQuery('type', "=", 'received');
})(current, parent);

Return to top


Step 2: Add the related list to the form view


To make the relationship available on the Procurement Case form, you need to navigate to Procurement Cases in Core UI and open any record. From the record's context menu (the three-dot menu or the form header), open Configure > Related Lists.


You'll see the new Received Emails relationship in the available lists on the left. Move it across into the selected lists. At this point you can also adjust the order — in the video, Received Emails is positioned before Draft and Sent Emails. That ordering is a matter of preference, but it's worth doing now while you have the list open.


Save. The related list will now appear at the bottom of the Procurement Case form in Core UI. Steps 3 and 4 deal with making it behave correctly in the Workspace.


Return to top


Step 3: Create a new UI Builder variant


Changes to how records display in the workspace need to be done in UI Builder. You'll be working with the Record page, but you shouldn't modify the out-of-box variant directly — instead, you'll create a new variant scoped to Procurement Cases.


Open UI Builder and navigate to the Source-to-Pay Workspace. Find the Record page — you can search for it or use the Record button in the page list. From here, duplicate the Record Standard variant.


When setting up the new variant, configure the condition so that it only matches Procurement Case records:


  • Condition: Table is sn_spend_psd_procurement_request

Procurement Cases open the Record Standard variant by default, and by creating a variant with a more specific condition, you're overriding that default only for Procurement Cases — nothing else in the workspace is affected. The changes you make in Step 4 will live in this variant.


Return to top


Step 4: Update the client state parameters


If you stop after Step 2, Received Emails will show up as a standalone related list — separate from the Emails tab where Sent and Draft already live. Steps 3 and 4 together tell the workspace to fold it into that existing Emails section instead.


Two client state parameters control this behaviour. You'll find them in your new variant in UI Builder. Both need to be updated for the Procurement Case table entry (sn_spend_psd_procurement_request).


relatedListsToBeHidden


This parameter controls which related lists are suppressed from the standalone related lists panel. Any table listed here will not appear as its own tab — instead, it will be picked up by relatedWorkTabsObjects and displayed within a grouped section.


For the Procurement Case entry, you're adding sys_email to the array. Here's what the before and after look like for the sn_spend_psd_procurement_request entry:


Before:

"sn_spend_psd_procurement_request": [
    "sn_spend_sdc_service_request",
    "sn_spend_sdc_service_task",
    "task_sla",
    "interaction_related_record",
    "sys_email_draft"
]

After:

"sn_spend_psd_procurement_request": [
    "sn_spend_sdc_service_request",
    "sn_spend_sdc_service_task",
    "task_sla",
    "interaction_related_record",
    "sys_email_draft",
    "sys_email"
]

The only change is the addition of "sys_email" at the end of the array. Everything else in the parameter stays exactly as it was — the other table entries are untouched.


Return to top


relatedWorkTabsObjects


Where relatedListsToBeHidden suppresses a list from appearing standalone, relatedWorkTabsObjects defines which grouped section it should appear in instead. This is where you tell the workspace that sys_email belongs inside the Emails tab — alongside sys_email_draft.


For the sn_spend_psd_procurement_request entry, you're adding "sys_email" to the emails array:


Before:

"sn_spend_psd_procurement_request": {
    "emails": [
        "sys_email_draft"
    ],
    "related_work": [
        "sn_spend_sdc_service_request",
        "sn_spend_sdc_service_task",
        "task_sla",
        "interaction_related_record"
    ]
}

After:

"sn_spend_psd_procurement_request": {
    "emails": [
        "sys_email_draft",
        "sys_email"
    ],
    "related_work": [
        "sn_spend_sdc_service_request",
        "sn_spend_sdc_service_task",
        "task_sla",
        "interaction_related_record"
    ]
}

With both parameters updated, save the variant. To see the changes in the workspace, do a cache refresh — Shift + Cmd + R on Mac or Shift + Ctrl + R on Windows. The standalone Received Emails related list will be gone, and Received Emails will now appear as a tab within the Emails section alongside Sent and Draft.


Return to top


Conclusion

That's the full picture for surfacing received emails in the S2P Workspace — four steps across Core UI and UI Builder, with the client state parameter changes being the part that's easiest to get wrong without a reference. If you run into something unexpected in your environment or have questions about the relationship script, drop them in the comments below.

0 Helpfuls
  • 30 Views
Version history
Last update:
yesterday
Updated by:
ServiceNow Employee
Contributors