Queue SpecificContent Key Truncates Numeric Suffix (e.g., key1 → key)

Help Orchestrator
,
1

I’m using Add Queue Item to add several dictionary entries with keys like “RelatedMember1”, “RelatedMember2”.

However, in Orchestrator the key becomes “RelatedMember” and multiple values are overwritten or merged.

I also tried “RelatedMember_1”, but it still comes through as “RelatedMember”.

Is there a known restriction on using numeric suffixes in SpecificContent keys?

Has anyone experienced or documented this behavior?

2

Hi @summertime1
I tried to reproduce it, doesn’t look like there is any restriction on Key Name.

image
image314×146 5.79 KB

If possible please share some more details, like activity screenshot or any custom logic you are using.

3

@summertime1,

Check if your Queue is setup to accept only predefined schema.

The image shows a software interface for creating a queue with fields for naming, description, schema definitions, additional options, auto retry settings, SLA predictions, and retention policy configuration. (Captioned by AI)
The image shows a software interface for creating a queue with fields for naming, description, schema definitions, additional options, auto retry settings, SLA predictions, and retention policy configuration. (Captioned by AI)1495×829 66 KB

4

Thanks for the suggestion!

I double-checked the Queue configuration in Orchestrator, and I haven’t enabled any predefined schema.

It’s just a regular queue with no custom constraints — I’m freely using dynamic key-value pairs in SpecificContent.

The issue still persists even with newly created queues.

Let me know if there’s anything else I should check!

5

Thanks for following up!

Due to security policy I can’t share screenshots, but here’s exactly how the queue item is constructed:

  1. I load an Excel file with 3 sheets.
  2. From the “Subscription Info” sheet, I iterate through each DataRow.
  3. Each DataRow is converted into a Dictionary (key: column name, value: cell value).
  4. Before creating the Dictionary, I group the columns by name and filter out those with duplicate keys.
  5. If any key is duplicated, the process logs the issue and stops to avoid exceptions.
  6. Once a valid Dictionary is created, I merge it with two other Dictionaries (property info + file info).
  7. If duplicate keys exist during merge, I keep only the first value (using LINQ).
  8. The final Dictionary is added to the queue via Add Queue Item.

This process works fine except when the Dictionary contains keys like RelatedMember1, RelatedMember2.
In Orchestrator, only one key appears — RelatedMember, and the other seems to get ignored or overwritten.

No custom serialization or queue schema is applied.

Also, since I’m working in a Korean environment, it’s common practice here to use key names that combine Korean characters (Hangul) with numbers — for example, “예시1” or “예시(예: YYYY-MM-DD)”.
Could this naming convention be causing any issues in how keys are parsed or displayed in Orchestrator?

Thank you again for your help!

6

@summertime1

Use debug mode and check at each step what are the keys are getting stored in dictionary variable and add a log message and provide whatever the exact values you provided in Add qeue activoty in the log message.

From orchestrator queue there is no any kind of restrictions until you defined any schema.

try to look somewhere your are taking any numeric values or any mistakes.

7

Thanks for your insights.
I just realized that there was a sanitization (cleansing) logic in the existing code, which stripped numeric suffixes from the dictionary keys.
I hadn’t accounted for that, so I’ll work on resolving the issue from that angle.

Appreciate your help!

8

Great ..

Please mark my post as solution to close this topic if you got the solution.
Or if any queries you have please post here.

Happy Automation!!

9

Sure! Marked your post as the solution :blush:

Thanks again for the detailed explanation and kind follow-up.

Much appreciated – Happy Automation!