Quick Flows Parameter Mapping Fails When Field Values Contain <, >, (, )

Q&A
,
1

Executive Summary
A critical parameter mapping failure has been identified in Quick Flows when field values contain certain special characters. Specifically, when a field value includes characters such as <, >, (, or ), the parameter mapping mechanism fails to correctly identify the end of that field value, causing it to absorb content from subsequent fields. This results in one parameter receiving an oversized, corrupted value while the following parameter(s) remain blank.

Problem Description
Observed Behavior
When a Reasoning Group step outputs key-value pairs and a downstream Action step attempts to map those values to parameters, the following occurs:

  • Affected parameter: Receives the correct value plus content from subsequent fields (e.g., Value with <special chars>", "nextField": "nextValue")

  • Following parameter: Receives a blank/empty value

  • All other parameters: Map correctly without issue

Reproduction Conditions
Condition
Result
Field value contains <, >, (, )
:x: Mapping fails
Field value contains no special characters
:白色的对勾: Mapping succeeds
Identical workflow with fixed/simple field values
:白色的对勾: Mapping succeeds

Root Cause Hypothesis
Quick Flows’ internal field value parser appears to treat certain special characters (<, >, (, )) as control or structural characters rather than literal text content. This is consistent with how these characters are used in:

  • XML/HTML parsing

  • Regular expressions

  • Mathematical or programming syntax

When the parser encounters these characters mid-value, it may incorrectly interpret them as value terminators, causing field boundary misidentification.

Evidence
Test with Simplified Value (No Special Characters)

Field: Audit Based Update

Result: :白色的对勾: All parameters map correctly
Test with Special Characters

Field: Audit Based Update <30 Items (Regular)

Result: :x: This parameter absorbs subsequent field content; next parameter is blank
Key Finding
Even in a minimal test Flow with hardcoded values (no dynamic data, no loops), Quick Flows fails to map Step 1 output to Step 2 Action parameters when special characters are present. This confirms the issue is at the platform parser level, not a configuration error.

Troubleshooting Attempts (All Failed)
Over 15+ iterations, the following approaches were tested without success:
Modified output formats: pipe-separated, Markdown table, key-value pairs

  • Various field naming conventions: Title Case, UPPER_CASE, camelCase, snake_case

  • Adjusted field ordering (moving affected fields to different positions)

  • Added explicit extraction instructions in step prompts

  • Completely rebuilt the Reasoning Group from scratch

  • Created isolated test Flows with minimal, hardcoded data

None of these resolved the issue, confirming the root cause is not configuration-related.

Business Impact

  • Workflows using dynamically generated field values containing <, >, (, ) are completely blocked

  • No configuration-level workaround exists that preserves the required exact field values

  • Manual processing is required as a temporary workaround, increasing time cost and error risk

Questions for the Community / Support Team
Is there a known issue or limitation with special characters in Quick Flows field value parsing?

  1. Is there an escaping mechanism (e.g., \<, &lt;, URL encoding) that can be applied to field values to prevent parsing errors?

  2. Does any alternative data format (e.g., JSON output, structured arrays) bypass this parsing behavior?

  3. Are there reserved characters or field name restrictions in Quick Flows Reasoning Groups?

  4. How should Reasoning Groups correctly pass data to downstream Action steps when values contain special characters?

Environment Details

  • Platform: Amazon Quick Suite / Quick Flows

  • Workflow Type: Reasoning Group with Loop Configuration

  • Step Type: Action step (ticket creation)

  • Data Format: Key-value pairs

  • Affected Characters: <, >, (, )

2

Hi @wanqce and welcome to the Quick Community!

I really appreciate your thoroughness for testing this out! I have not noticed any other community user’s make similar observations on this flows behavior but that being said I do not know how many users use special characters in their prompts.

Since you clearly laid out that the behavior is specifically tied to those 4 special characters, and the flow works fine without them, I would recommend creating a support ticket. A support ticket can allow the support team to properly investigate into the cause of this instance and also make AWS more aware of this behavior that you are experiencing with flows. Please refer to this resource on how to create a support ticket (Case management - AWS Support).

I guess in the meantime, my only recommendation as a short-term solution is to try to see if it is possible to rewrite your prompts without those special characters.