Genesys Cloud - Developer Community!

Hi everyone,
In a Digital Bot Flow, I'm using quick replies/buttons (and sometimes free-text). In some cases, customers tap the same button multiple times or the channel delivers duplicate messages (latency/retry), and the bot ends up running the same action twice (e.g., calling a Data Action twice, creating two tickets, sending duplicated confirmations).

What's the best way to implement idempotency / deduplication logic in a DBF?

• Do you store the last selection + timestamp in Participant Data and ignore repeats within X seconds?

• Is there a reliable message/turn identifier we can reference in the flow?

• Any recommended pattern for "lock" behavior (e.g., set processing=true until the action finishes) to prevent double execution?

Olá @Alex Sander Felicio!

------------------------------
Fernando Sotto dos Santos
Consultor Grupo Casas Bahia
------------------------------

Recommended pattern in Digital Bot Flow

1. Use a "processing lock" in Participant Data

Before executing any critical action (Data Action, ticket creation, etc.), check and set a lock:

• Participant.processing = true before the action

• If processing == true, ignore the input or send a "processing" message

• Reset processing = false after the action finishes (success or failure)

This prevents:

• Multiple quick-reply taps

• Duplicate messages caused by channel retries/latency

• Parallel execution of the same node

This is the most effective and reliable pattern in DBF.

2. Add lightweight deduplication (optional but recommended)

For quick replies or repeated intents, store:

• lastIntent

• lastValue

• lastActionTimestamp

Before executing:

• If the same intent/value is received within a short window (e.g., 3–5 seconds), ignore it

This reduces repeated execution caused by user behavior but should not replace the processing lock.

3. Do not rely on message/turn identifiers

DBF does not expose a consistent or guaranteed unique messageId or turnId suitable for idempotency. Messages can be retried or delivered more than once by channels, so flow logic should be state-based, not event-based.

4. Best practice: idempotency in the backend

If you control the backend behind a Data Action, implement idempotency there as well:

• Generate an idempotencyKey (e.g., conversationId + intent + selectedValue)

• Send it in the Data Action request

• Ensure the backend processes the action only once per key

This guarantees protection even if the bot or channel misbehaves.

Wow, this really helps solve the same problem I'm facing. Thank you, everyone!

Hi!

This is a really good question - duplicate clicks and retries are a very real problem in Digital Bot Flows, especially when you start doing side-effect actions (create ticket, call external API, etc.).

You can handle idempotency in a Digital Bot Flow using Participant Data and, when possible, backend logic. Inside the flow, one common pattern is to store a simple action key + timestamp (e.g., "createTicket|orderId=123" and lastActionTimestamp). Before executing a side-effect (Data Action, ticket creation, etc.), you compare the current action key with the last one and check if it happened within a short time window; if yes, treat it as a duplicate and skip. For more critical steps, you can also use a lightweight lock flag (e.g., processingCreateTicket = true/false) so that if a duplicate message arrives while processing is still true, you simply ignore it or route to an alternative path.

For a more robust solution, push idempotency to your backend/API. Send an idempotency key from the bot (based on conversation ID + action key) and make the external service either return the same result or ignore repeated requests with the same key. Since DBF doesn't expose a direct message/turn ID, combining conversation context, Participant Data (last action + timestamp or lock flags), and backend idempotency usually gives a solid deduplication strategy against double clicks, retries, and duplicated messages.

Best pattern we've found is to treat DBF/channel delivery as at-least-once and enforce idempotency in the backend:

• Generate/send an idempotencyKey with the Data Action (e.g., conversationId + actionName + choice/intent (+ time bucket)).

• Backend stores the key with a TTL and returns the same result on duplicates instead of executing twice.

In the DBF you can add a lightweight guard:

• Store lastActionKey + lastActionTs in Participant Data and ignore repeats within X seconds, and/or

• Use a processing=true flag (with a timeout) to "lock" while the action runs.

Relying on a universal "message/turn id" is usually not consistent across channels, so the key + backend dedupe is the most reliable.