Use PDIs? Take our 5-minute survey to help shape the PDI roadmap.

Best approach to expose Portal variables as separate columns in a WFM Cases table

Hert-Gutier
Kilo Contributor

Hi team,

I’m looking for some guidance on the best approach to implement the following requirement.

We currently have a WFM Cases table where some information selected by the user in the portal is ultimately combined and stored/displayed as part of the Description field.

The business would like to have the following values available as separate columns on the WFM Cases table:

  • Help Topic – Help Topic selected by the user on the portal

  • Sub Help Topic – Sub Help Topic selected by the user on the portal

  • Request Type – Additional standardized selection that may vary depending on the selected Help Topic/Sub Help Topic

The main reason for this request is reporting and integrations. Currently, when data is exported from ServiceNow or consumed by external automation, these values need to be extracted from the Description text, which adds unnecessary processing and makes reporting more difficult.

The expected result would be something like:

WFM Case Help Topic Sub Help Topic Request Type

CASE001PayrollMissing PayRegular Pay
CASE002BenefitsHealth InsuranceEnrollment

At the moment, these values appear to originate from the questions/variables submitted from the portal, rather than existing as actual fields on the WFM Case record.

I’m trying to determine the best ServiceNow approach for exposing these values as structured data.

Some approaches I am currently considering are:

  1. Adding three fields directly to the WFM Cases table and populating them when the case is created.

  2. Using a Business Rule, Flow, or Script to retrieve the answers from the related question/answer records and copy them into the new fields.

  3. Using a Database View or another reporting mechanism instead of duplicating the data.

  4. Querying the related question/answer tables directly for integrations/reporting.

My main questions are:

  • What would be the ServiceNow best practice for this scenario?

  • Would adding physical fields to the WFM Cases table be recommended?

  • If the values originate from portal questions/variables, what is the recommended way to retrieve and persist them on the case?

  • Would a Database View be a better approach if the primary requirement is reporting/exporting data?

  • Are there any performance, maintenance, or upgrade considerations with these approaches?

  • How would you recommend handling existing historical cases if new fields are introduced?

Any guidance or examples of similar implementations would be greatly appreciated.

Thanks in advance!

0 REPLIES 0