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, automations, and the assistant.

​
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 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.

​
Automations

Automations run under the brand’s setting. You can make an individual automation stricter when you edit it. Making one looser than its brand requires an explicit grant. When an unattended run reaches something that needs approval, it pauses and waits rather than failing or proceeding. Run history shows the decision, the action, and the setting that applied. 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. 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. Run history can show approval audit events with the decision, action type, connection scope, and policy that applied. See Automations.

​
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.