Skip to main content
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:
1

Open Settings

Choose Settings from the manage sidebar.
2

Open the Brands tab

Select the brand you want to configure.
3

Choose what daoco can do on its own

Pick one of the three options. Exceptions for a single account or integration live on the brand’s Connections page.

The three options

Reading and drafting never need approval. Deleting or removing things in a connected app always asks, whichever option you pick. 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.

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 chat card or workflow panel 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. Destructive decisions are bound to the specific operation, connection, resource scope, and run that requested them, so approving a delete never covers anything else. Approving an ordinary connected-app update is broader on purpose: it runs exactly that action and also lets daoco keep making ordinary updates on the same provider for the rest of that thread without asking again, so one approval covers the whole job. That thread-scoped access appears in the brand’s grant list and only ever applies inside that thread.
  • 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.