Issue Storing Email Message Body as Map in DynamoDB (Ticket Management Workflow)

[Sadia_Khalid]

Hi Community,
I’m building a ticket management system in n8n with the following workflow:

• Trigger: Email IMAP node checks for incoming emails.
• Parse: Extracts relevant fields from the email (including ticket number in subject/body).
• Check in DynamoDB:
  • If ticket number exists, update the existing entry with the new/updated message body.
  • If ticket number does not exist, insert a new row with all relevant details.
  • Send Acknowledgment Email to the user confirming ticket creation or update.
  • The message body is not just plain text — it’s a structured object containing:
    fromEmail
    toEmail
    timestamp
    emailSubject
    emailBody
    (and optionally) attachments metadata

Everything works fine except when trying to store this message body in DynamoDB as a Map.
The workflow fails or DynamoDB does not store the field as expected, despite multiple attempts to format the value as a Map.
I’ve tried different JSON formatting, Set node, and manual {{ JSON.parse() }} conversions, but Dynamo still stores it as a string or fails entirely.

---

Question:

How can I correctly store the email’s message body (with its structured fields) as a Map in DynamoDB via n8n?

---

What is the error message (if any)?

Unable to store params of msg body in map format so that can be retrieved easily at frontend.

---

Please share your workflow

---

Share the output returned by the last node

[
  {
    "ticketId": "TICKET-1234556788965-1233",
    "Msgbody": {
      "Subject": "Testing new workflows nice",
      "From": "<[email protected]>",
      "To": "<[email protected]>",
      "Msg": "<Testing new workflows nice... message body>        ",
      "Timestampe": "Mon, 4 Aug 2025 05:57:51 +0000",
      "Msg-type": "Email",
      "Email-status": "Default"
    },
    "Timestampe": "Mon, 4 Aug 2025 05:57:51 +0000"
  }
]

---

Information on your n8n setup

• n8n version: 1.105.3
• Database (default: SQLite): AWS Dynamo DB
• n8n EXECUTIONS_PROCESS setting (default: own, main) : default
• Running n8n via (Docker, npm, n8n cloud, desktop app) : Self Hosted.
• Operating system : Linux

[jabbson]

I am assuming the problematic part is Updating the entry (not creating a new entry)?

How exactly it doesn’t work/fail? When you try to store it, what happens? How does it fail? Is there an error?

Have you tried reducing the workflow to only have this one task - given a static input, update the database with new body,

Could you also share the workflow?

[Sadia_Khalid]

Thanks for your response!

---

The issue actually happens on both creating and updating an item in DynamoDB from my n8n workflow.

The msg body field in DynamoDB is set to type Map, but when I send data from n8n (via the AWS DynamoDB node), it always stores it as a string instead of a Map.

For example, instead of:

{ "key1": "value1", "key2": "value2" }

it stores:

"{\"key1\":\"value1\",\"key2\":\"value2\"}"

There’s no error — the workflow runs successfully — but the data type is wrong, which means I can’t later update specific Map attributes without replacing the entire string.

Steps I’ve tried so far:

• Parsing the data to JSON before sending to DynamoDB.
• Selecting Map as the field type in the n8n DynamoDB node.
• Sending both raw object data and stringified JSON — both end up stored as a string.

I haven’t yet stripped the workflow down to a single test task with static data, but I can do that next if it helps.
Happy to share a minimal export showing only the relevant DynamoDB create/update node if that’s useful.

The goal is to store the msg body as a proper DynamoDB Map type so the frontend can access attributes by key/index, and so we can update only the required attributes later without replacing the whole value.

---

[jabbson]

Hey @Sadia_Khalid hope all is good.

Sadly, I don’t have an access to any DynamoDB instances to try to figure it out or test, maybe someone else in the community does.

[Sadia_Khalid]

Thanks @jabbson, for your response. Could someone else support in this regard it would be quite appreciated.