Flow Designer Reference Field Bug: Why Your Impacted Service Stays Blank

The Problem That Wasted My Afternoon

Last week I spent three hours staring at a Flow Designer action that should have been straightforward. The task was simple enough: resolve a Technical Service from CMDB relationships and populate the Primary Impacted Service field on an incident.

The logs showed everything working perfectly. My script was returning the correct sys_id. The execution details displayed the right display value. But when the incident was created, the Impacted Service field was completely blank.

If this sounds familiar, you are not alone. This is one of those ServiceNow quirks that catches experienced developers off guard.

Flow Designer Architecture

What Actually Goes Wrong

The root cause is surprisingly subtle. Flow Designer handles output variable serialization differently depending on how you configure your action outputs.

When you set an output variable as a Reference type, Flow Designer tries to be clever. It attempts to serialize the reference properly when passing data between your custom action and downstream steps like Create Record. The problem is that this serialization does not always work correctly.

You can return a perfectly valid sys_id string from your script. Flow Designer will show you the correct value in the execution details. But somewhere in the handoff to the Create Record step, the reference resolution fails silently.

Troubleshooting Mind Map

The Fix That Actually Works

After testing several approaches, here is what reliably solves the problem:

Step 1: Change Your Output Variable Type

Inside your custom Flow Designer Action, change the output variable configuration:

• Name: primary_impacted (or whatever makes sense for your use case)
• Type: String (not Reference)

This is counterintuitive. You would think a reference field should use a Reference output type. But switching to String avoids the serialization problem entirely.

Step 2: Return the sys_id as a Plain String

Your action script stays essentially the same. Just make sure you are returning the sys_id as a string value:

outputs.primary_impacted = technicalServiceSysId;

Nothing fancy. Just the 32-character sys_id string.

Step 3: Use a Field Script in Create Record

This is the key part that makes everything work. In your Create Record step, do not drag the output data pill directly onto the reference field.

Instead, click the fx button next to the field and use a field script:

(function execute() {
    var svcSysId = fd_data.resolve_primary_service.primary_impacted;
    if (!svcSysId) return '';
    return svcSysId;
})();

Replace resolve_primary_service with whatever you named your action step in the flow.

Why This Approach Works

When you use a field script, ServiceNow handles the reference resolution at the last possible moment. The sys_id string gets injected directly into the field, and ServiceNow automatically resolves it to the correct record.

This bypasses Flow Designer's problematic reference serialization entirely. The field receives a clean sys_id value and does what reference fields are supposed to do.

Configuration Summary

Things to Watch Out For

A few notes from testing this in different environments:

Verify your fd_data path. The exact path to your output variable depends on how you named things. Use the data pill picker in Flow Designer to confirm the correct object path.

Check your target field type. This approach works for reference fields pointing to any table, not just cmdb_ci_service_technical. Just make sure the sys_id you return actually exists in the target table.

Test with edge cases. What happens when your script cannot find a matching service? Make sure your field script handles empty or null values gracefully.

The Bigger Picture

This issue highlights something important about Flow Designer development. The platform tries to abstract away complexity, but sometimes that abstraction creates unexpected behaviour.

When you hit a wall like this, the solution often involves stepping back from the visual tools and using more explicit approaches. Field scripts give you precise control over what value ends up in a field, which is exactly what you need when Flow Designer's automatic handling falls short.

I have started defaulting to String output types for any sys_id values I pass between Flow Designer steps. It adds one extra line of code in the downstream step, but it eliminates an entire category of serialization bugs.