Skip to content

Dynamic Named Fields

Most dynamic fields have static names and dynamic values: the field name sessionId stays the same; only its value abc123 changes. ASM handles these automatically.

But some applications use dynamic field names, where the field name itself changes based on other values. A field named color1234 might become color5678 in the next session, because 1234 and 5678 come from another field's value.

Dynamic named fields are rare. They are also the kind of thing that will break your replay in confusing ways when ASM treats them as static. This guide explains how to recognize them, when ASM auto-detects them, and how to configure manual correlation when it doesn't.

What Are Dynamic Named Fields?

The Problem: Field Names That Change

Typical dynamic field (ASM handles automatically):

sessionId=abc123    ← Field NAME stays "sessionId", VALUE changes
sessionId=xyz789    ← Same name, different value

Dynamic named field (requires configuration):

Recording:
  serialno=1234
  color1234=blue     ← Field name includes value from "serialno"

Replay:
  serialno=5678
  color5678=?        ← Field name changed! ASM doesn't know to correlate this

Why it breaks: ASM sees color1234 in the recording, finds it in Fields View with hardcoded value blue. During replay the application expects a field named color5678 (because serialno=5678), but the test case sends color1234=blue. The server rejects it.

Why Applications Use Dynamic Names

Common scenarios:

  1. Array-like data without explicit indexing: Server generates field names from IDs
  2. Legacy systems: Old applications concatenate IDs into field names
  3. Dynamic forms: Forms generated with unique field names per item
  4. Database-driven UIs: Field names derived from database record IDs

Example use cases:

  • E-commerce: quantity{productId} → quantity12345, quantity67890
  • Inventory: checkbox{itemId} → checkbox999, checkbox888
  • Reporting: {reportId}_status → 2024Q1_status, 2024Q2_status

When ASM Auto-Detects Dynamic Names

ASM's AI-Powered Detection (v7.0)

In v7.0, ASM's AI analysis can detect simple dynamic name patterns automatically:

Auto-detected patterns:

  • ✅ Suffix patterns: fieldName{value} (e.g., color1234)
  • ✅ Prefix patterns: {value}_fieldName (e.g., 1234_assembly_date)
  • ✅ Common separators: Underscore, dash, no separator
  • ✅ Numeric identifiers: When identifier value is clearly numeric

When ASM auto-detects:

  1. Analyzes field names in recorded POST data
  2. Looks for patterns where part of name matches another field's value
  3. Creates correlation if pattern is clear and unambiguous
  4. Grey background in Fields View indicates auto-configured

Check Fields View after ASM runs: If dynamic named fields show grey background, ASM detected them automatically. No manual configuration needed.

When Manual Configuration Is Needed

You need manual configuration when:

  • ❌ Field name pattern is ambiguous (could match multiple identifiers)
  • ❌ Separator is unusual or inconsistent
  • ❌ Identifier value is complex (alphanumeric, special characters)
  • ❌ Multiple dependent fields use same identifier in different positions
  • ❌ ASM didn't auto-detect (white background in Fields View, replay fails)

Symptoms requiring manual configuration:

  • ✅ Replay fails with errors like "field not found" or "invalid field name"
  • ✅ POST data inspection shows field names contain IDs from other fields
  • ✅ Application uses array-like notation in field names
  • ✅ Fields View shows dependent fields as "Recorded" (static)

Ask the AI

My replay fails with "field not found" errors. I see fields like
"color1234" where 1234 matches the value of "serialno". Is this a
dynamic named field issue? How do I configure it?

How Dynamic Named Fields Work

Core Concept: Identifier + Dependent Fields

Two types of fields:

  1. Identifier field: Its VALUE becomes part of other field names
  2. Dependent field: Its NAME includes the identifier's value

Example:

Identifier:  serialno = 1234
Dependent:   color1234 = blue     ← Name includes identifier value "1234"

During replay:

  1. Extract identifier value: serialno = 5678 (fresh value from server)
  2. Rename dependent field: color1234 → color5678
  3. Extract dependent value: Get fresh value for color5678 from response
  4. Post with new name: Send color5678=<fresh value>

Pattern Syntax: Using & as Placeholder

Pattern configuration uses & (ampersand) as placeholder for identifier value.

Pattern examples:

Pattern Matches
color& color1234, color5678, color999
&_date 1234_date, 5678_date, 999_date
item&_qty item1234_qty, item5678_qty
checkbox& checkbox123456789, checkbox999

How patterns work:

  • & replaced with identifier value at runtime
  • Pattern matching finds fields where name includes identifier value in specified position
  • Case sensitive: Color& won't match color1234

Configuring Dynamic Named Fields

Step 1: Access Preferences

  1. Window → Preferences (or Load Tester → Preferences on macOS)
  2. Web Performance → Configuration Wizards → Application State → Dynamically Named Fields
  3. Preferences page opens showing two tables: Identifiers (top) and Fields (bottom)

Step 2: Add Identifier Field

Identifier field is the field whose VALUE appears in other field names.

  1. Click "Add Field" next to Identifiers table (top table)
  2. Enter field name exactly as it appears in your test case
  3. Example: serialno
  4. Click OK

Identifier appears in table. You can now configure dependent fields for this identifier.

Step 3: Add Dependent Fields

Dependent fields are fields whose NAMES include the identifier value.

  1. Select identifier in Identifiers table
  2. Click "Add Field" next to Fields table (bottom table)
  3. Enter pattern with & as placeholder:
  4. Example: color& (matches color1234, color5678, etc.)
  5. Click OK
  6. Repeat for each dependent field using this identifier

Step 4: Run ASM

After configuring patterns:

  1. Right-click test case → Configure → Application State...
  2. ASM wizard runs with dynamic name configuration
  3. Fields View shows dependent fields correlated to identifier
  4. Run replay to verify field renaming works

Common Patterns and Examples

Pattern 1: Suffix (Identifier at End)

Field structure: fieldName{identifierValue}

Example: 

serialno=1234
color1234=blue
weight1234=5

Configuration:

Table Field Pattern
Identifiers serialno (no pattern for identifiers)
Fields (for serialno) color& Matches color1234
Fields (for serialno) weight& Matches weight1234

Result: During replay, if serialno=5678, fields are renamed to color5678 and weight5678.

Pattern 2: Prefix (Identifier at Start)

Field structure: {identifierValue}_fieldName

Example: 

reportId=2024Q1
2024Q1_status=approved
2024Q1_total=15000

Configuration:

Table Field Pattern
Identifiers reportId
Fields (for reportId) &_status Matches 2024Q1_status
Fields (for reportId) &_total Matches 2024Q1_total

Result: If reportId=2024Q2, fields become 2024Q2_status and 2024Q2_total.

Pattern 3: Middle Position

Field structure: prefix{identifierValue}_suffix

Example: 

itemId=999
weight999_in_lbs=25
price999_usd=49.99

Configuration:

Table Field Pattern
Identifiers itemId
Fields (for itemId) weight&_in_lbs Matches weight999_in_lbs
Fields (for itemId) price&_usd Matches price999_usd

Result: If itemId=777, fields become weight777_in_lbs and price777_usd.

Pattern 4: Multiple Identifiers for Same Dependent Field

Use when: Same field name pattern can use different identifiers depending on context.

Example: 

Scenario A:
  itemId=123456789
  checkbox123456789=checked

Scenario B:
  legacyId=123
  checkbox123=unchecked

Configuration:

Table Field Pattern
Identifiers itemId
Identifiers legacyId
Fields (for itemId) checkbox&
Fields (for legacyId) checkbox&

How it works:

  • ASM examines each checkbox{number} field
  • Checks if {number} matches itemId value → Associates with itemId
  • Checks if {number} matches legacyId value → Associates with legacyId
  • Correct identifier chosen based on which value matches

Result: ASM correctly correlates checkbox123456789 with itemId and checkbox123 with legacyId.

Pattern 5: Complex Multi-Field Dependencies

Example: Product catalog with multiple attributes per item

productId=A1B2C3
name_A1B2C3=Widget
price_A1B2C3=29.99
qty_A1B2C3=100
A1B2C3_inStock=true
A1B2C3_category=tools

Configuration:

Table Field Pattern
Identifiers productId
Fields (for productId) name_&
Fields (for productId) price_&
Fields (for productId) qty_&
Fields (for productId) &_inStock
Fields (for productId) &_category

Result: All six dependent fields renamed when productId changes.

Verifying Dynamic Name Configuration

Check Fields View After ASM

After running ASM with dynamic name configuration:

  1. Open Fields View (Window → Show View → Fields)
  2. Look for dependent fields:
  3. Field Name shows pattern (e.g., color&)
  4. Datasource shows Dynamically named from: serialno
  5. Grey background indicates ASM configured the dependency
  6. Value shows current extracted value

Example Fields View entry:

Field Name: color&
Datasource: Dynamically named from: serialno
Value: blue

Test with Replay

Run a single-iteration replay to verify field renaming works:

  1. Right-click test case → Replay
  2. Watch for field name errors in Errors View
  3. Check POST data in Headers View:
  4. Click transaction that posts dependent fields
  5. Verify field names updated with fresh identifier value
  6. Replay succeeds → Dynamic name correlation working ✅

Verify Configuration

I configured dynamic named fields with identifier "serialno" and
dependent field "color&". How can I verify ASM is renaming the
field correctly during replay?

Troubleshooting Dynamic Named Fields

Problem: ASM Doesn't Detect Pattern

Symptoms: After ASM runs, dependent field still shows white background (not grey) in Fields View.

Possible causes:

  1. Pattern doesn't match: & position wrong or separator different
  2. Identifier field missing: Didn't add to Identifiers table
  3. Case mismatch: Pattern is Color& but field is color1234
  4. Identifier value not in field name: Value doesn't actually appear in name

Solutions:

Verify pattern matches exactly:

  • Recorded field: color1234
  • Identifier value: 1234
  • Pattern: color& ✅
  • Wrong patterns: Color& (case), &color (position), color_& (separator)

Check identifier value appears in name:

If identifier value is "1234" and field name is "color1234", match ✅
If identifier value is "5678" and field name is "color1234", NO match ❌

Re-run ASM after fixing configuration:

  1. Fix pattern or add missing identifier
  2. Right-click test case → Configure → Application State...
  3. Check Fields View again

Problem: Field Renamed But Value Not Extracted

Symptoms: Field name changes during replay, but value is still hardcoded from recording.

Possible cause: Dependent field's VALUE also needs correlation (separate from name).

Solution: Configure VALUE extraction separately.

How to fix:

  1. Dynamic name handles the NAME change (color1234 → color5678)
  2. Standard ASM must handle the VALUE extraction (blue → fresh value)
  3. Run ASM configures both automatically

If value isn't extracted:

  • Check if server actually sends value for color5678 in responses
  • Use custom detector if value extraction needs manual configuration (see Advanced Field Assignments)

Problem: Multiple Fields Match Same Pattern

Symptoms: Pattern item& matches multiple fields, ASM correlates wrong ones.

Possible cause: Pattern too broad, matches unintended fields.

Example: 

Pattern: item&
Matches: item1234 ✅ (intended)
Also matches: item1234_qty ❌ (unintended)
             item1234_price ❌ (unintended)

Solution: Make pattern more specific.

Fixed patterns: 

item&           → Matches item1234 only
item&_qty       → Matches item1234_qty only
item&_price     → Matches item1234_price only

Problem: Identifier Value Contains Special Characters

Symptoms: Identifier value like A1-B2_C3 doesn't match fields with that value in name.

Possible cause: Special characters in identifier value.

Solution: Pattern still uses & as placeholder. ASM replaces with actual value including special characters.

Example: 

Identifier: productCode = A1-B2_C3
Pattern: name_&
Matches: name_A1-B2_C3 ✅

No escaping needed in pattern. & is a literal placeholder, not regex.

Troubleshooting Help

I configured identifier "productId" with dependent field pattern
"qty&" but ASM isn't correlating it. The field name in my test case
is "qty12345" and productId value is "12345". What's wrong?

Advanced Scenarios

Scenario 1: Arrays of Items

Application sends: 

numItems=3
item0_name=Widget
item0_price=9.99
item1_name=Gadget
item1_price=19.99
item2_name=Gizmo
item2_price=29.99

Problem: Index (0, 1, 2) is dynamic, not from another field.

Solution: Dynamic named fields don't work for numeric array indices that aren't correlated to another field.

Alternative: Use Dynamic Path Segment Detector if indices appear in URLs, or contact support for custom array handling.

Scenario 2: Nested Dependencies

Application sends: 

categoryId=100
productId=200
field_100_200=value

Problem: Field name includes TWO identifier values.

Solution: Dynamic named fields support one identifier per field. For multiple identifiers in same field name, contact support for custom configuration.

Scenario 3: Identifier Value Changes Format

Recording: 

itemId=12345
field_12345=value

Replay: 

itemId=A9876  ← Changed from numeric to alphanumeric!
field_A9876=?

Problem: If identifier value format changes, pattern still works. & is replaced with ANY value.

Solution: Pattern field_& matches both field_12345 and field_A9876. No special configuration needed.

Best Practices

1. Let ASM Auto-Detect First

Always run ASM before configuring dynamic names manually. AI detection in v7.0 catches many patterns automatically.

Workflow:

  1. ✅ Record test case
  2. ✅ Run ASM (automatic or manual)
  3. ✅ Check Fields View for grey-background dependent fields
  4. ❌ Only configure manually if ASM missed them

2. Use Specific Patterns

Bad (too broad): 

Pattern: &
→ Matches ANY field containing identifier value anywhere in name

Good (specific): 

Pattern: color&       → Matches color1234, color5678
Pattern: &_status     → Matches 1234_status, 5678_status
Pattern: item&_price  → Matches item1234_price

Why: Specific patterns avoid false matches and make configuration easier to understand.

3. Document Identifier Purpose

Use descriptive identifier names when possible:

Bad: 

Identifier: id
Dependent: field&

Good: 

Identifier: productId
Dependent: price&
Dependent: qty&

Why: In complex test cases with multiple identifiers, clear names prevent confusion.

4. Test with Multiple Values

After configuring dynamic names, test with multiple identifier values:

  1. First replay: Verify works with one fresh identifier value
  2. Second replay: Check with different identifier value
  3. Load test: Verify works with many virtual users (different IDs)

Why: Ensures pattern matches all identifier value formats (numeric, alphanumeric, etc.).

5. Combine with Standard ASM

Dynamic names handle field NAME changes, but standard ASM handles VALUE extraction.

Both must work together:

  • ✅ Dynamic name config: color1234 → color5678 (name change)
  • ✅ Standard ASM: Extract fresh value red for color5678 (value extraction)

Don't forget: After configuring dynamic names, verify standard ASM also extracts values correctly.

Dynamic Names vs. Other ASM Features

Dynamic Names vs. Dynamic Values

Feature Changes Example
Dynamic Values (standard ASM) Field VALUE changes, name stays same sessionId=abc123 → sessionId=xyz789
Dynamic Names (this topic) Field NAME changes based on identifier color1234=blue → color5678=red

Most fields are dynamic values. Standard ASM handles them automatically.

Dynamic names are rare. You only need this when a field name includes another field's value.

Dynamic Names vs. Advanced Field Assignments

Feature Use Case
Dynamic Names Field name includes identifier value (color1234)
Fragment Patterns Field value assembled from parts (ca-pub-123)
URL Path Variables Dynamic URL segments (/order/12345/summary)

Use dynamic names when: The field's name changes.

Use advanced assignments when: The field's value needs complex extraction/assembly.

Next Steps

Related Topics: