> ## Documentation Index > Fetch the complete documentation index at: https://docs.dmly.io/llms.txt > Use this file to discover all available pages before exploring further. # Set how conversations behave > Choose what a teammate's reply does to the bot, who owns a conversation afterwards, when a closed one reopens, and whether the AI may answer. **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 Select your name and avatar at the bottom of the sidebar, then **Settings**. It is the second tab, after **Business Details**. One **Save** button at the top of the page saves the whole tab. Nothing applies until you select it. 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](/account/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](/inbox/notes-and-collaboration). 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](/getting-started/mobile-app), or an AI assistant closing a chat over [MCP](/mcp/overview). * **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. This select is greyed out when the setting above is **Change nothing — keep the bot running**, with the line **Nothing to resume while replies don’t pause the bot.** Your stored choice is kept, and it still applies to a takeover you start by hand with **Pause bot (human takeover)**, which parks a running flow the same way a reply does. **An automatic hand-back never resumes a flow that moves money or commits a slot.** If the parked flow contains a payment, invoice, order, subscription, coupon, credit, booking, confirmation, cancellation, reschedule, class enrolment, discount, a sent product/service/plan, or a webhook, DMLY leaves it parked and leaves the bot paused, even when your policy says resume. The agent may have taken that payment or booking by hand, and replaying it is worse than waiting. A person resuming it themselves does resume it: that is a decision, not a sweep. ## 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](/inbox/assigning-chats). ### 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. **There is no agent list.** Every user in the workspace is a candidate, including your bookkeeper and anyone who only logs in to read reports. There is no on-call or availability filter either: **On call duty** in the sidebar is for [WhatsApp calls](/inbox/whatsapp-calling) and has no effect here. If your workspace is not all-hands-on-the-Inbox, leave this off and triage the **Unassigned** filter by hand. ## 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](/inbox/conversation-status). ## 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](/automation/flow-builder). 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. It does not touch **Suggest a reply with AI** in the Inbox reply box. That is a separate feature for your team, and it keeps working with this switch off. Whether the AI Agent is available at all depends on your plan; see [Plans](/billing/plans). ### 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](/automation/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: | If you set | Then | | ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Change nothing — keep the bot running** | The resume policy has nothing to act on for replies, and greys out. It still governs a pause you start with **Pause bot (human takeover)**. | | **Never — end it by hand** | The close prompt loses its **Resume it from the same step** option, and no other way of closing a conversation can hand the flow back either. | | **Round-robin across the team** plus **Whoever replied last** | A new conversation gets an owner immediately, then changes hands to whoever answers it. Pair round-robin with **Only claim it if nobody owns it** if you want the original assignment to stick. | | **Leave it closed** plus **Round-robin across the team** | A returning contact is never re-assigned: round-robin only ever fires on a contact's first message. | | **Let the AI reply** off plus a flow whose only reply is an AI step | The flow still starts and still finishes, but the contact hears nothing: all they get is the skipped-step note, which only your team can see. Deactivate the flow itself if you want no run at all. | Change one thing at a time and watch a real conversation. Every setting here alters something a customer experiences (whether the bot speaks, whether a chat reopens), and the defaults are the behaviour your team already learned. ## Related Taking over from the bot, the parked-flow banner, and the close prompt. Who owns a conversation, and what changes hands. Marking done, reopening, and archive. The first tab on the same Settings page.