Set how conversations behave

Conversation settings governs the handover between your team and your automations: whether replying takes a conversation off the bot, when the bot gets it back, who owns it, and whether the AI is allowed to answer at all. Every control on the tab already matches how DMLY behaves out of the box, and the tab says so in a banner at the top: These already match how DMLY behaves out of the box — change them only if you want something different. So this is somewhere you come to change your mind, not a setup step you have to complete.

​

Open the tab

Two things about the scope of this tab:

• It is workspace-wide. There is no channel picker here. What you set applies to WhatsApp, Messenger, Instagram, Telegram, Live Chat, SMS and every other connected Channel, and to every teammate.
• It is admin territory. Reaching the tab needs a permission in the Team & Settings module, and saving needs Manage workspace settings. Admins and the workspace owner hold both; Members and Viewers hold neither by default, though a custom role can grant them. Note that the Settings entry in the sidebar menu is only shown to Admins, so a teammate on a custom role reaches the tab from the tab strip on another Settings tab rather than from the menu. See Roles and permissions.

​

Human takeover

​

When a teammate replies

• Pause the bot and the running flow (the default)
• Change nothing — keep the bot running

The tab’s own explanation: Replying is usually a takeover: the automation stops where it is, keeps its place, and stops answering for you. On the default, sending a reply does two things at once. It pauses the bot for that contact (the same state as Pause bot (human takeover) in the details panel), and it parks any automation the contact was part-way through: the flow keeps its current step, the answers already given, and whatever was left of a wait timer, rather than being cancelled or restarted. A parked flow shows as a banner in the details panel with Resume, Skip this step and End automation. See Work a conversation as a team. Two precise points that save confusion:

• The takeover only happens if the reply actually goes out. A reply DMLY refuses to send (the WhatsApp 24-hour window has closed, the message body is empty, a template has a blank value) leaves the bot running and nothing parked.
• It applies to a person’s reply. A message sent by an automation, a notification or a broadcast is not a takeover.

Choose Change nothing — keep the bot running and replying is just a message: no pause, no parked flow. Your automations and your team can then answer the same conversation, so use it when the bot handles one narrow job (an order lookup, a booking link) that a human reply should not interrupt. Ownership is a separate setting and still applies.

​

When should automation resume after a human reply?

• Only when someone resumes it (the default)
• When the conversation is closed
• After a quiet period, which reveals an hours box: anything from 1 to 720 hours (30 days), and 24 if you leave it alone
• Never — end it by hand

The tab’s own explanation: A paused flow keeps its place. Closing a conversation doesn’t prove the automation is still wanted, so by default it waits for you. Flows holding a payment, invoice, booking or order are never resumed automatically. What each one does:

• Only when someone resumes it: nothing hands back on its own. Somebody selects Resume bot, or the banner’s Resume or Skip this step. A flow’s Resume bot replies step lifts the pause too, though it leaves the parked run itself frozen.
• When the conversation is closed: closing hands the conversation back. In the web Inbox you are still asked (the prompt below), and this setting only pre-selects Resume it from the same step. Where nothing can ask, the hand-back happens by itself: a flow’s Close conversation step, the mobile app, or an AI assistant closing a chat over MCP.
• After a quiet period: DMLY checks every minute and hands the conversation back once the hours you set have passed. The clock runs from when the takeover happened, not from the last message, so a long conversation does not keep pushing it out. This one only lifts a pause that came from a takeover (a reply, or Pause bot (human takeover)); a pause set by a flow’s Handover to Human step, or by blocking a contact, is never swept.
• Never — end it by hand: a parked flow only ever moves because a person moved it. The close prompt drops Resume it from the same step entirely, and a close arriving from a flow step, the mobile app or MCP leaves the flow parked as well.

​

Ownership

​

Who owns the conversation after a reply

• Whoever replied last (the default)
• Only claim it if nobody owns it
• Replying never changes the owner

The tab’s own explanation: By default it follows whoever answered last — which also takes it off a teammate the moment somebody else replies. This is the setting behind the behaviour people notice first in a shared Inbox: a teammate answers a chat that was yours, and it quietly becomes theirs. Only claim it if nobody owns it keeps the reply-claim for unassigned conversations but never takes one off a teammate. Replying never changes the owner leaves assignment entirely to hand and to your automations. A claim from replying is silent either way: no bell for the new owner, no bell for the old one, and no conversation.assigned webhook. See Assign chats to teammates.

​

Give new conversations an owner

• Leave them unassigned (the default)
• Round-robin across the team

The tab’s own explanation: Round-robin picks whoever currently has the fewest open conversations. Everyone in the workspace counts as an agent, so leave this off unless that is true for your team. Round-robin fires once, on a contact’s first ever inbound message, and never on a returning contact. It compares how many Open conversations each workspace member holds right now (not how many they have ever been given) and hands the new one to the lowest; ties break the same way every time, so the result is stable rather than random. It never takes a conversation that already has an owner, and it assigns before the new-conversation alert goes out, so the alert names the right person. The assignee gets a bell notification; no conversation.assigned webhook is sent.

​

Reopening

​

When a closed conversation gets a new message

• Always reopen it (the default)
• Reopen only within, which reveals an hours box: anything from 1 to 8760 hours (a year), and 24 if you leave it alone
• Leave it closed

The tab’s own explanation: Someone writing back usually means the conversation is live again. Restrict it if your team treats closed as resolved. The window is measured from the moment the conversation was closed, not from the last message. A second message that arrives after the window has passed does not get a fresh window; it stays closed too. This setting only decides the Open / Done flip. Whatever you choose, an inbound message is still recorded in the thread, still raises the unread count, still fires message.received and any automation built on it, and still un-archives an archived thread. So under Leave it closed a returning customer lands in Done carrying an unread badge, which is exactly why you would only choose it if someone watches All or Unread only rather than just Open. See Open and done conversations.

​

AI replies

​

Let the AI reply

A switch, on by default. The tab’s own explanation: Turning this off stops every AI step across all your flows at once. The rest of each flow keeps running and the skipped step is noted in the conversation. This is the workspace kill switch for the AI step inside a flow. Turn it off and no flow is broken: each one keeps running, the AI step is skipped, and a line appears in the conversation reading ✨ AI step skipped — AI replies are turned off for this workspace. so whoever opens the thread can see why the bot went quiet. Turning it back on takes effect on the next message; it does not replay the skipped steps.

​

Wait before an AI reply

A number of seconds, 0 by default, maximum 5. The tab’s own explanation: A short pause makes the AI feel less instant. Max 5 seconds — it holds a worker while it waits. A flow step asking for longer keeps its own pause. It is a floor, not an override: an AI step that asks for a longer pause of its own (Typing delay before reply (seconds) on the step’s Prompt tab in the flow builder) keeps the longer of the two. Five seconds is the ceiling either way, though: whichever number wins, the pause DMLY actually takes never exceeds five seconds, because it is a real wait held open while the reply is prepared. Anything longer needs a Smart Delay step before the AI step rather than a bigger number here.

​

How the settings interact

The two halves of this tab meet in a few places worth knowing before you change anything:

​

Related