Approval preferences

Every brand has one setting for how much Daoco does on its own. It applies everywhere that brand works: chat, post workflows, brief folders, and the assistant’s recurring tasks.

​

Where to set it

Brand owners and admins set it per brand:

​

The three options

Reading and drafting never need approval. Deleting or removing things in a connected app always asks, whichever option you pick. When Daoco sends a newsletter or email campaign to your list through Ghost, Mailchimp, beehiiv, Kit, or Klaviyo, it always asks too, one send at a time. No option, connection setting, earlier approval, or Bypass approvals skips it. This covers the tools Daoco recognises as sends. Drafting tools follow your usual approval settings, even one that can also schedule. Under Work autonomously and Full autonomy, social posts requested in chat can be scheduled automatically when the selected time is more than one hour away. Posting now and nearer schedules require approval. An account set to always ask still asks. Under Full autonomy, Daoco still asks before an unusually large action: more than 500 recipients, more than 100 records written at once, more than 10 posts scheduled in one go, any new or increased spend, or the first thing it ever publishes through a connection.

​

Per-connection exceptions

Exceptions live with the connection itself. Open Connections from the manage sidebar, find the account or integration, and choose Access & approvals from its ⋯ menu. The dialog has two controls: Access is enforced before anything runs. A connection set to Read only refuses writes outright. Daoco is told why and plans around it instead of sending you an approval to grant. One chat-side exception: a workspace owner or admin can turn on Bypass approvals for a single thread from the composer, which answers that thread’s ordinary asks, including a connection set to Always ask, until it is turned off. Deletes and always-confirm actions still ask, and Read only still refuses. See Brand chat. To stop Daoco using a connection entirely, disconnect it from the same menu.

​

Browser profiles

A signed-in browser profile, for a site you added or for a social account, is a connection too. Its setting is on the Browser tab of Connections: Off, Read only, Ask, or Allow. The three options above and Bypass approvals apply to it the same way, with three additions:

• Likes, reposts, follows, direct messages, posts, comments, and replies on a social platform always need their own approval, one per action. Nothing above skips them.
• Security settings always ask.
• Purchases, payment details, ad spend, passwords, and one-time codes are never handled through a browser and have no approval.

See Browser profiles.

​

Work nobody is watching

The assistant’s recurring tasks and brief folders run under the brand’s setting. When one of them reaches something that needs approval, it pauses and waits for a member rather than failing or going ahead. Work the assistant starts on its own never approves anything. Approving from the approval bar above the chat box, or from the panel showing the post, video, or campaign, resumes the approved work automatically. Daoco does not add an “Approve” message to the conversation or place one in the follow-up queue. When a connected-app specialist asked, that same specialist continues where it stopped, with what it had already looked up, instead of starting the task over. Typing “approve” in the thread does the same as the card, as long as exactly one approval is waiting. With more than one waiting, none is answered and Daoco asks you to use the cards. If you type anything else while an approval is waiting, Daoco treats it as a new instruction: the pending request is closed without running, and the thread carries on from your message. A browser task pauses the same way. Approving its card continues the same browser specialist, which runs exactly what the card showed. Destructive decisions are bound to the specific operation, connection, resource scope, and run that requested them, so approving a delete never covers anything else. An ordinary connected-app update is approved with Allow once, which runs exactly that action; Daoco asks again next time. From the second update of the same kind in a row, an arrow beside the button offers Allow in this chat, which also lets Daoco keep making ordinary updates on the same provider for the rest of that thread. That thread-scoped access appears in the brand’s grant list and only ever applies inside that thread. Typing “approve” gives the same access as Allow in this chat. After three approvals of the same kind in a row, the arrow also lists the standing permissions an action allows, for example Always allow Instagram publishing for this brand. Choosing one approves this action and stops asking for the next ones. On a connected app such as Ghost or WordPress, the standing permission covers the one action shown, such as creating a draft: other actions on that app still ask, publishing a page or post always asks, and a publish card offers no standing permission. Saved permissions are listed under Settings → Brands, where you can revoke them.

​

Related guides

• Brand chat explains when Daoco asks before publishing, scheduling, or applying brand updates.
• Create posts covers preview review before publish or schedule actions run.
• Integrations explains how /integration handles writes to a connected integration.
• Workspace settings shows where to open brand settings from the Brands tab.