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

Hert-Gutier · 3 weeks ago

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

CASE001	Payroll	Missing Pay	Regular Pay
CASE002	Benefits	Health Insurance	Enrollment

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:

Adding three fields directly to the WFM Cases table and populating them when the case is created.
Using a Business Rule, Flow, or Script to retrieve the answers from the related question/answer records and copy them into the new fields.
Using a Database View or another reporting mechanism instead of duplicating the data.
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!

vaishali231 · 3 weeks ago

Hey @Hert-Gutier
I would recommend adding the three fields directly to the WFM Case table and populating them when the case is created.

The overall approach would be:

Portal Variables/Questions → WFM Case Fields → Reporting/Integrations

For example:

Case	Help Topic	Sub Help Topic	Request Type
CASE001	Payroll	Missing Pay	Regular Pay
CASE002	Benefits	Health Insurance	Enrollment

Why physical fields?

Since these values are business attributes of the Case, storing them directly on the Case makes the data much easier to consume.

Instead of integrations/reporting having to:

WFM Case → Question/Answer records → Find variable → Extract answer

they can simply query:

WFM Case → Help Topic / Sub Help Topic / Request Type

This also avoids relying on the Description field for structured data.

How should the values be populated?

First identify where the portal submission is creating the WFM Case and where the variable/question answers are available.

If the Case is created through Flow Designer, I would preferably map the values as part of the Case creation itself.

If the values are only available through related question/answer records, they can be retrieved during creation and populated into the new Case fields.

I would avoid having multiple reports/integrations query the question/answer tables independently.

Database View?

I would not use a Database View as the primary solution here.

A Database View makes sense when you need to combine data from multiple tables for reporting. However, in this scenario, these values logically belong to the WFM Case.

A Database View would also leave integrations dependent on the underlying question/answer structure.

Business Rule vs Flow

If you already have a Flow that creates the WFM Case, I would first look at extending that process.

A Business Rule can be used if there is no suitable creation point, but I would avoid unnecessary synchronous queries and updates such as:

Create Case → BR → Query answers → Update Case

If possible, populate the values during the original Case creation.

Existing historical cases

For existing cases, I would perform a one-time backfill after introducing the fields.

The process could be:

Create the three fields.
Implement the mapping for new Cases.
Validate the mapping.
Run a controlled backfill for historical Cases.
Handle records where the old Description/question data cannot be reliably mapped.
Use the new fields going forward for reporting and integrations.

One thing to verify

I would also confirm whether Request Type is independently selected or whether it is always derived from Help Topic + Sub Help Topic.

If it is always derived, you may not need to store it separately. If it is an independent business value, then a dedicated field is appropriate.

Overall, I would go with:

Dedicated fields on WFM Case + populate them during Case creation + one-time historical backfill.

*********************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb