Introduction
In both the Source-to-Pay (S2P) Workspace and the Finance Operations Workspace, Agents can create new cases directly from the different case Lists by clicking on the 'New' button. When doing so, a pop-up — known internally as the Case Interceptor — is opened, offering a dropdown with the available case types the Agent can choose from to start the creation process.
This is a small but very visible piece of the day-to-day Agent experience, and it has a direct impact on adoption. If the dropdown shows case types that are no longer relevant for the customer, or it is missing the new custom case types that have been created as part of the implementation, Agents will get confused and the experience will feel inconsistent.
Challenge
When delivering a Source-To-Pay or Finance Operations implementation, it is quite standard to:
- Deactivate some of the OOTB case types that are not in scope for the customer.
- Create custom case types to cover business processes that are not addressed by the standard product.
- Restrict which case types are available depending on the persona, region, or business unit.
The expectation, in all these scenarios, is that the dropdown shown when clicking 'New' from the case List reflects the configuration that has been applied. However, this is not always the case: the dropdown does not always honor the active/inactive flag of the case types, and there is no obvious configuration page exposed to manage what shows up in it.
So, where is this dropdown actually controlled, and how can it be adjusted?
Out-of-the-box behavior
The pop-up that is opened when clicking 'New' from a case List in the Workspace is rendered by a UX page within the Workspace's Page Collection. It is fed by a Data Resource that returns the list of available options based on the Record Producers associated with the underlying case table.
In a nutshell, the OOTB flow is:
- The Agent clicks 'New' from one of the case Lists in the Workspace.
- The Case Interceptor page opens as a modal.
- A Data Resource calls a server-side method that builds the dropdown data, based on the Record Producers configured for the sn_spend_sdc_service_request table.
- The Agent selects one of the options and is taken to the corresponding Record Producer to fill in the case details.
Where the dropdown is actually built
To trace exactly where the dropdown content comes from, the entry point is UI Builder. The steps are the same for both Workspaces (S2P Workspace and Finance Operations Workspace), only the Page Collection name changes.
- Navigate to UI Builder > Finance Operations Workspace (or Source-to-Pay Workspace).
- Open the Page Collection and select Finance workspace modal > Case interceptor for Finance Operations Workspace (or its equivalent page in the S2P Workspace Page Collections).
- In the Data Resources panel, look for the resource named "Get Service cases/task data 1", which uses the Open Record [sys_ux_data_broker_transform] transform (We can navigate to it by clicking on the three dots at the right side, and then clicking on 'Open Record' option).
- Once the record is opened, the key part on the script executed is:
javascriptdata.dropdownData = new InterceptorUtil().constructDataForLinkSet(input.query, input.table);
This is the line that builds the JSON array of options that the dropdown renders. The InterceptorUtil Script Include is the one responsible for translating the configured Record Producers into the dropdown entries.
⚠️ Heads-up: In the current OOTB implementation, this method does not always filter out Record Producers that have been marked as inactive. As a result, you may still see deactivated case types appearing in the dropdown until you complete the additional configuration described below. If you spot this in your instance, it's worth raising it through HI as a defect, and in the meantime, treat the wizard-level configuration (next section) as the source of truth.
Alternatively, the Script Include function can be modified to add a new line of code to only retrieve active entries:
From:
var grAnswer = new GlideRecord('sys_wizard_answer');
grAnswer.addQuery('question', grWizard.sys_id + '');
grAnswer.orderBy('name');
grAnswer.query();To:
var grAnswer = new GlideRecord('sys_wizard_answer');
grAnswer.addQuery('question', grWizard.sys_id + '');
grAnswer.addActiveQuery();
grAnswer.orderBy('name');
grAnswer.query();
Where to add, remove or reorder the entries?
Even though the data is constructed by InterceptorUtil, what it actually iterates over is a Wizard record, as it can be deducted from the Script Include code in the function. This is the configuration point you'll want to manage when you need to add a new entry, remove one, or reorder the dropdown.
- Navigate to the Wizard [sys_wizard] table.
- Filter by Intercepts = sn_spend_sdc_service_request.do.
- Open the corresponding Wizard record.
- The list of answers/options associated with this Wizard is what drives the dropdown shown in the Case Interceptor pop-up.
From here you can:
- Remove an option that is no longer relevant — for example, an OOTB case type that has been deactivated as part of the customer scoping.
- Add a new entry that points to a custom Record Producer created for a new case type. This is the natural complement of the Extend 'Case Creation on behalf of Suppliers' to custom case types configuration: that article explains how to extend the 'Add More Details' button to custom case types, and this one ensures the same case type also appears as an option when starting a case from the List in the Workspace.
- Reorder the options to surface the most frequently used case types at the top.
💡 Tip: Always test the change with an Agent persona — not as admin — to validate that the entries you expect to see are visible, that the inactive ones are gone, and that selecting each option correctly opens the Record Producer behind it.
