ChatGPT Dots Controls: Approvals, Custom Rules, and Review

Built-In Safeguards Are Not a Control Plan

ChatGPT dots ship with built-in safeguards, automatic approval checks, and existing app permissions from the start. Before an action that could affect accounts or share information, an automatic review checks instructions, permissions, custom rules, and built-in safety requirements. The outcome can proceed, need approval, or include a step you must do yourself. That is not the same as an operator control plan.

Operators still need to review ongoing work in Activity, scope instructions clearly, set optional custom rules for recurring boundaries, know what Pause versus stop-a-task versus cancel-a-schedule does, and understand sharing and privacy boundaries. Workspace admins separately gate who can use dots and which capabilities are on. This post covers what operators must own and what admins control so dots work stays under your control.

If you are still deciding whether to enable dots or need the overall rollout sequence, read the ChatGPT Dots for Business playbook first. This post assumes you have created or are about to create a dot and need the practical review, approval, and rule-setting habits that keep delegated work safe.

OpenAI publishes getting started with your dot for setup basics. You can create a dot in the mobile app, desktop app, or desktop browser. You name it, choose an appearance, connect plugins, and optionally connect a computer. Connections are separate. Messaging participation does not grant inbox or computer access. The first conversation starts with relevant ChatGPT memory. You start with ongoing responsibilities and say which decisions need your input. Ending a conversation or voice call does not necessarily stop assigned work. Open Activity to inspect delegated work.

Review Work Like an Operator

Your dot's profile on desktop includes an Activity view. Activity shows progress, files, results, and requests waiting for a decision, app connection, sign-in, or approval. You see what the dot is working on, what it has delivered, and where it is blocked. If a task needs your approval to proceed, you will find the request in Activity. If the dot drafted a message but does not have permission to send, that draft appears in Activity waiting for your decision.

Picture a two-location home services company. The operator asks the dot to draft a weekly client update every Friday. The dot researches completed jobs, pulls appointment counts from the scheduling plugin, and writes the update. Drafting replies does not grant permission to send. The draft appears in Activity. The operator opens Activity on Friday afternoon, reviews the draft, approves the send, or edits the message and tells the dot to revise. Without the Activity habit, the operator would never see the draft and clients would never receive the update.

The Scheduled view in your dot's profile shows recurring task instructions, timing, and destination. If you told the dot to post a summary to a Slack channel every Monday at nine, Scheduled lists that instruction, the schedule, and the channel. You can disable or delete a recurring task from Scheduled. Disabling stops future runs. Deleting removes the instruction entirely. Review Scheduled weekly to confirm the dot is still working on tasks you want and nothing you forgot to cancel.

You can change direction while work continues. If the dot is drafting a proposal and you realize the scope changed, open a new conversation or voice call and give updated instructions. The dot will incorporate the change. If you need to stop a specific delegated task immediately, open Activity, find the task, and stop it. Stopping a task does not stop other ongoing work or future scheduled tasks. It stops that one task.

What to Look for in Activity

Check Activity daily if your dot handles customer-facing work or account changes. Look for requests waiting for approval, especially sends, deletes, or actions that affect shared files. Look for tasks that completed and review the results. If the dot posted to a Slack channel, open the channel and confirm the message landed correctly. If the dot updated a spreadsheet, open the file and spot-check the changes. If the dot drafted an email, read the draft before you approve the send.

Look for tasks that are blocked. A blocked task might need you to connect an app, sign in to a service, or make a decision the dot cannot make alone. If a task has been blocked for more than a day, either unblock it or stop the task. Do not let blocked tasks accumulate. They clutter Activity and make it harder to see what is actually running.

Look for files the dot created or modified. Activity shows files by name and location. If you see a file you do not recognize, open it and confirm the content is correct. If the dot created a file in the wrong folder or with the wrong permissions, move it or update the permissions and tell the dot where files should go in the future.

How Automatic Action Review Works

Before an action that could affect accounts or share information, an automatic review checks instructions, permissions, custom rules, and built-in safety requirements. The outcome can proceed, need approval, or include a step you must do yourself. For example, you must change a password yourself. The dot cannot change passwords even if you instruct it to do so.

A specific instruction can cover future actions within that scope. If you tell the dot to post a summary to a specific Slack channel every Monday, that instruction covers future Monday posts to that channel. The dot does not need approval each time. If you tell the dot to draft replies but not send them, drafting does not grant send permission. Each send needs approval unless you later give a specific instruction that covers sends.

Research tools from connected apps are read-only for that research. The dot can read messages, files, and calendar events to gather information. It cannot send messages, change app content, or control a browser or computer during research. Follow-up actions still need permissions and safety requirements. If the dot researches your inbox and then wants to send a reply, the send requires approval even though the research was read-only.

Custom rules are instructions the dot tries to follow, and it can make mistakes. Rules do not grant app or computer access, override built-in safety, or remove required confirmations such as approval to use a saved login. If your workspace disables custom rules, you cannot edit saved rules and they do not apply. The automatic review still runs. Built-in safeguards and app permissions still apply.

OpenAI publishes OpenAI's guide to controlling your dot with additional detail on how the automatic review works and what operators can control.

Set Custom Rules for Ongoing Boundaries

Custom rules are optional instructions that tell your dot how to handle recurring situations. You set rules in Settings on desktop or web, or in the sidebar under Customize on iOS or Android. On desktop or web, open Settings, then Personalization, then Custom rules under Permissions. On mobile, open the sidebar, tap Customize, then Custom rules.

When you add a rule, you choose from four options. Take action without asking means the dot proceeds without approval for actions that match the rule. Take action when you say so means the dot waits for an explicit instruction each time. Ask before taking action means the dot asks for approval before proceeding. Hand off to you means the dot stops and tells you to handle the action yourself.

Use Take action without asking for low-risk actions you have scoped clearly and want to run automatically. Use Take action when you say so for actions you want only on explicit request, such as sending a specific type of message. Use Ask before taking action for medium-risk actions where you want to review each instance before it happens. Use Hand off to you for high-risk actions you never want the dot to attempt, such as deleting shared files or making irreversible account changes.

Custom rules are for actions, not preferences. If you want the dot to use a certain tone or format, say so in conversation. If you want the dot to check with you before sending customer emails, create a custom rule. Conversation preferences guide style and approach. Custom rules gate actions that could affect accounts or share information.

Plugin permissions are separate from custom rules. Open Plugins in Settings to review which apps are connected and what actions are allowed. Enabling an app alone does not authorize a send. The dot still needs permission to send messages even if the messaging plugin is connected. Plugin permissions control which apps the dot can read from and write to. Custom rules control which actions require approval within those apps.

If your workspace disables custom rules, you cannot edit saved rules and they do not apply. The toggle appears in the Admin Console under Permissions. Workspace admins can turn custom rules on or off for all members. If you rely on custom rules and your workspace disables them, your approval boundaries disappear. Know who controls the workspace setting and confirm it is on before you depend on rules.

A Practical Rule Set for Operators

Start with rules for your two or three riskiest actions. Do not create a rule for every preference. Focus on actions that could affect customer relationships, shared files, or account settings. Expand the rule set only after you see how the first rules work in practice.

Ask before taking action for customer-facing or outbound messages. If your dot drafts emails to clients, proposals to prospects, or posts to public channels, set a rule that requires approval before sending. This rule catches mistakes, tone problems, and factual errors before they reach the recipient. It also gives you a chance to add context the dot might not have.

Hand off to you for deletes of shared files or irreversible account changes. If your dot organizes files and might delete old ones, set a rule that hands off deletes to you. You review the file, confirm it is safe to delete, and delete it yourself. The same applies to account changes that cannot be undone, such as removing a team member from a workspace or canceling a subscription.

Take action without asking for low-risk internal drafts or checklist updates you already scoped. If your dot maintains a weekly task checklist in a private document and you have told it exactly what to track, set a rule that allows updates without approval. The risk is low because the document is private, the updates are scoped, and you review the document regularly. If the dot makes a mistake, you catch it in your next review and correct the instruction.

Take action when you say so for sends you want only on explicit request. If your dot drafts a monthly report but you want control over when it goes out, set a rule that requires you to say send each time. The dot prepares the report, saves it in Activity, and waits. You review the report, confirm the timing is right, and tell the dot to send. This rule is useful for time-sensitive or high-stakes communications where you want to choose the moment.

Imagine an agency ops lead who manages client reporting. The dot drafts weekly status updates for three clients. The ops lead sets Ask before taking action for all client emails. Every Friday, the dot drafts the updates and saves them in Activity. The ops lead opens Activity, reviews all three drafts, edits one for tone, approves two, and tells the dot to revise the third. The rule ensures no client email goes out without a human review, but the ops lead does not have to write the drafts from scratch.

Start narrow and expand. Create one or two rules in the first week. Live with them for a week. Open Activity daily and see how often the rules trigger. If a rule blocks too much work, adjust it. If you find a new risky action, add a rule. Do not create ten rules on day one. You will spend more time managing rules than reviewing work.

Stop, Pause, and Delete Without Confusion

Pause stops the current main task but not every delegated task or future schedule. The Pause button appears in your dot's profile. When you pause, the dot stops working on the task you are discussing in the active conversation. It does not stop tasks you delegated in earlier conversations. It does not disable recurring tasks in Scheduled. If you want to stop a specific delegated task, open Activity, find the task, and stop it. If you want to stop a recurring task, open Scheduled, find the task, and disable or delete it.

Resume restarts the paused task. The Resume button appears in the same place as Pause. If you paused a task by mistake or want to restart it after a break, tap Resume. The dot picks up where it left off. If a workspace admin pauses your dot from the Admin Console, you cannot resume it yourself. The admin must resume it or you must contact the admin.

Stopping a task does not undo completed actions. If the dot posted a message to Slack, stopping the task does not delete the message. If the dot updated a spreadsheet, stopping the task does not revert the changes. You must undo completed actions yourself. Open the app, find the change, and reverse it manually. Stopping only prevents future actions in that task.

Delete your dot removes the dot entirely. The delete option appears in Settings. When you delete, you see a confirmation that warns you the action cannot be undone. Deleting the dot does not undo changes already made in connected apps or recall messages already delivered. It does not delete separately stored files, Codex threads, or conversations. It removes the dot, its instructions, its custom rules, and its access to your accounts. If you want to stop one bad task, stop the task. Do not delete the dot.

Common mistake: an operator creates a dot, assigns three ongoing tasks, realizes one task is wrong, and deletes the dot to stop it. Deleting stops all three tasks, removes all custom rules, and disconnects all plugins. The operator must recreate the dot, reconnect plugins, rewrite instructions, and set rules again. The correct action is to open Activity, find the bad task, and stop it. The other two tasks continue and the dot remains configured.

Sharing, Privacy, and Data Settings

Before sharing information from a private conversation with other people, your dot checks that you have allowed it. If you discuss a client issue in a private conversation and then ask the dot to post a summary to a public Slack channel, the dot asks for confirmation before posting. Tell the dot where to send updates and which changes need your attention. If you want weekly summaries in a specific channel, say so. If you want to review every message before it goes to a customer, say so.

ChatGPT data controls also apply to eligible conversations with your dot and the work it carries out. If you have opted out of training data, your conversations with the dot and the tasks it performs are not used for training. OpenAI does not train models directly on proactive research or the dot's private notes. If that research becomes part of an eligible conversation or task, data settings apply. Check your data settings in ChatGPT settings and confirm they match your privacy requirements.

If your workspace has data residency or compliance requirements, confirm with your workspace admin that dots meet those requirements. Workspace admins control data settings at the organization level. Individual data controls apply within the workspace settings. If you handle regulated data, ask your admin whether dots are approved for that data before you assign work that involves it.

Workspace Admin Gates Operators Should Know Exist

Workspace admins control whether members can use dots at all. The Admin Console includes a Permissions section with a Use dots toggle. If the admin turns off Use dots, existing dots are hidden, paused, and billing stops. Members cannot create new dots. If your dot stops working and you did not pause or delete it, check with your admin. The workspace setting may have changed.

Admins control whether dots can participate in Slack and Microsoft Teams channels. The Add dots to Slack and Microsoft Teams toggle appears in Permissions. If this toggle is off, dots cannot read or post in channels. If your dot is supposed to post updates to Slack and nothing appears, confirm the workspace setting is on.

Admins control whether dots can connect to local computers. The Allow local computer access toggle appears in Permissions. If this toggle is off, members cannot connect their dots to their local machines. Cloud computer capabilities are separate. Admins control Use a browser, Allow network access, Allow computer use, and Use password manager in the cloud computer section. These settings gate what dots can do in cloud environments. If your dot needs browser access or network access, confirm the workspace settings allow it.

Admins control whether members can use custom rules. The Use custom rules for dots toggle appears in Permissions. If this toggle is off, members cannot edit saved rules and existing rules do not apply. Built-in safeguards and app permissions still work, but the custom boundaries you set disappear. If you depend on custom rules, confirm this setting is on and know who to contact if it changes.

Admins control which plugins are available and what actions are allowed. The Admin Console includes plugin controls for each connected app. An admin can enable an app but restrict certain actions. Enabling an app alone does not authorize a send. The dot still needs permission to send messages even if the app is enabled. If your dot cannot perform an action you expected, check plugin permissions with your admin.

Admins can pause, resume, or delete any member's dot from the Admin Console under Dots inventory. An admin pause prevents the member from resuming the dot. The member must contact the admin. Deleting a dot from the Admin Console has the same effect as the member deleting it. The dot, its instructions, its rules, and its access are removed. Changes already made in connected apps remain.

When a member leaves, admins should follow an offboarding checklist. Review the member's dot permissions and connections. Check for ongoing work in Activity and Scheduled. Stop or reassign tasks that should not continue. Disconnect plugins the member used. Delete the member's dot if it is no longer needed. Revoke the member's Use dots permission. Offboarding a member without reviewing their dot can leave tasks running, messages sending, and files changing after the member is gone.

Admins and operators share responsibility. Admins set the boundaries. Operators work within them. If you are an operator, know which workspace settings are on and who controls them. If you are an admin, communicate setting changes to operators before you make them. A surprise toggle can stop work in progress and create confusion.

A Lightweight Control Checklist Before You Hand a Dot Ongoing Work

Before you assign ongoing responsibilities to your dot, confirm you have covered the basics. This checklist takes ten minutes and prevents most control problems.

Write the scoped instruction. Be specific about what the dot should do, when it should do it, and where the output should go. If the instruction is vague, the dot will guess. If the instruction is too broad, the dot will do more than you want. Write the instruction as if you are delegating to a junior team member who will follow it literally.

List the decisions that need you. Tell the dot which actions require your approval, which actions you want to review, and which actions you will handle yourself. If you want to approve every customer email, say so. If you want to review file deletes before they happen, say so. If you want to change passwords yourself, say so. Do not assume the dot will know. State the decision gates explicitly.

Name the destinations for updates. Tell the dot where to send summaries, where to post progress, and where to save files. If you want a weekly summary in a specific Slack channel, name the channel. If you want drafts saved in a specific folder, name the folder. If you want errors sent to your email, say so. Do not make the dot guess where things should go.

Create custom rules for your two or three riskiest actions. Identify the actions that could cause the most damage if they go wrong. Create a rule for each one. Use Ask before taking action or Hand off to you for high-risk actions. Use Take action without asking only for low-risk actions you have scoped clearly. Start with two or three rules. Add more only if you find new risks.

Set an Activity review habit. Decide when you will open Activity and how often. Daily is best for customer-facing work. Weekly works for low-risk internal tasks. Put the review on your calendar. Treat it like any other operational review. If you do not review Activity, you will not catch mistakes until they cause problems.

Set a Scheduled review habit. Decide when you will review recurring tasks. Weekly is enough for most operators. Monthly works if you have only a few recurring tasks. Check that the tasks listed in Scheduled are still tasks you want. Disable or delete tasks that are no longer relevant. Update instructions for tasks that have changed.

Know who to contact if your workspace disables a capability. Find out who controls the Admin Console. Ask them to notify you before they change a setting that affects your dot. If a capability you depend on gets turned off, you need to know immediately so you can adjust your work or find an alternative.

Common Mistakes

Treating Draft Permission as Send Permission

Drafting replies does not grant permission to send. If you tell your dot to draft customer emails, the drafts appear in Activity. The dot cannot send them unless you approve each send or give a specific instruction that covers sends. Operators who assume drafts will be sent automatically find that nothing goes out. Clients do not receive updates. Prospects do not receive proposals. The operator opens Activity a week later and finds a stack of unsent drafts.

Fix: when you assign drafting work, decide whether you want to approve each send or give a standing instruction to send. If you want to approve, set a custom rule that requires approval and check Activity daily. If you want the dot to send automatically, give a specific instruction that covers sends and confirm the dot understood.

Never Opening Activity

Activity is where you see what your dot is doing, what it has done, and what it needs from you. Operators who never open Activity miss approval requests, ignore completed work, and let blocked tasks pile up. They assume the dot is working when it is actually waiting for a decision. They assume tasks completed successfully when errors occurred.

Fix: open Activity daily if your dot handles customer-facing or account-changing work. Open Activity weekly if your dot handles only low-risk internal tasks. Put the review on your calendar. Treat it as a non-negotiable operational check.

Creating a Rule for Every Preference Instead of Using Conversation

Custom rules are for actions that need approval or handoff, not for preferences about tone, format, or style. Operators who create rules for every preference end up with a long list of rules that overlap, conflict, or do not apply. The dot tries to follow all of them and makes mistakes. The operator spends more time managing rules than reviewing work.

Fix: use conversation for preferences. Tell the dot how you want things formatted, what tone to use, and what details to include. Use custom rules only for actions that could affect accounts or share information. Keep the rule list short.

Always-Style Without Asking on Outbound Customer Messages

Take action without asking is for low-risk actions you have scoped clearly. Outbound customer messages are not low-risk. A message with the wrong tone, wrong facts, or wrong recipient damages the relationship. Operators who set Take action without asking for customer emails find that the dot sends messages they would have edited or blocked.

Fix: use Ask before taking action for customer-facing messages. Review every message before it goes out. If you trust the dot after a few weeks, you can switch to Take action when you say so and approve sends in batches. Do not switch to Take action without asking until you have reviewed dozens of messages and confirmed the quality is consistent.

Assuming Pause Canceled Schedules

Pause stops the current main task. It does not disable recurring tasks in Scheduled. Operators who pause their dot and assume all work stopped find that recurring tasks continue to run. A weekly report still goes out. A daily checklist still updates. The operator did not intend those tasks to continue, but Pause does not stop them.

Fix: if you want to stop a recurring task, open Scheduled, find the task, and disable or delete it. Use Pause only when you want to stop the current task temporarily. Use Scheduled to manage recurring work.

Deleting the Dot to Stop One Bad Task

Deleting your dot removes the dot, its instructions, its rules, and its access to all connected apps. It does not undo changes already made. It does not recall messages already sent. Operators who delete the dot to stop one bad task lose all their other work, all their rules, and all their plugin connections. They must recreate the dot from scratch.

Fix: open Activity, find the bad task, and stop it. If the task is recurring, open Scheduled and disable or delete it. Do not delete the dot unless you want to remove it entirely.

Ignoring That Workspace Disabled Custom Rules

If your workspace admin turns off the Use custom rules for dots toggle, your saved rules do not apply. You cannot edit them. The dot does not follow them. Built-in safeguards and app permissions still work, but the custom boundaries you set disappear. Operators who do not notice the change assume their rules are still protecting them. They assign work that depends on a rule and the rule does not trigger.

Fix: confirm the Use custom rules toggle is on before you depend on rules. If your admin turns it off, ask why and whether it will be turned back on. If it stays off, adjust your instructions and approval habits to compensate.

Confusing Plugin Permissions with Custom Rules

Plugin permissions control which apps the dot can read from and write to. Custom rules control which actions require approval within those apps. Operators who confuse the two assume that connecting a plugin gives the dot permission to send messages, delete files, or change settings. It does not. The dot still needs permission for each action even if the plugin is connected.

Fix: open Plugins in Settings and review which apps are connected. Then open Custom rules and review which actions require approval. Treat them as separate controls. Connecting a plugin is step one. Setting rules for actions is step two.

A 14-Day Practice Plan

This plan builds control habits over two weeks. Follow it in order. Do not skip steps.

Days 1 Through 3: Create and Scope

Create your dot or reopen an existing dot. Connect only the plugins you need for the first task. Do not connect every plugin available. Connect one or two. Write one scoped ongoing responsibility with clear decision gates. Tell the dot what to do, when to do it, where the output should go, and which decisions need your approval. Start the work. Open Activity and confirm the dot started the task.

Days 4 Through 7: Live in Activity and Scheduled

Open Activity every day. Look for requests waiting for approval. Look for completed tasks and review the results. Look for blocked tasks and unblock them or stop them. Open Scheduled and confirm the recurring task is listed correctly. If the dot asks for approval, answer deliberately. Do not approve automatically. Read the request, check the context, and decide. If you approve, watch what happens. If you deny, tell the dot why and what to do instead.

Days 8 Through 10: Add Two Custom Rules

Identify your two riskiest actions from the first week. Create a custom rule for each one. Use Ask before taking action or Hand off to you. Do not use Take action without asking yet. Test the rules. Assign work that should trigger the rules and confirm they trigger. Open Activity and see the approval requests or handoff messages. Adjust the rules if they are too broad or too narrow.

Days 11 Through 14: Review Permissions and Settings

Open Plugins in Settings and review which apps are connected and what actions are allowed. Disconnect any plugin you are not using. Open Custom rules and review the two rules you created. Edit them if you learned something in the first ten days. Check your ChatGPT data settings and confirm they match your privacy requirements. If you are in a workspace, confirm with your admin which workspace gates are on. Ask about Use dots, Add dots to Slack and Microsoft Teams, Allow local computer access, Use custom rules for dots, and plugin controls. Write down who to contact if a setting changes.

At the end of 14 days, you have a dot with scoped work, a daily Activity habit, two custom rules, and a clear picture of what your workspace allows. You are ready to add more work, more rules, and more plugins. Expand slowly. Add one new task or rule per week. Review the results before you add the next one.

How SumoGrowth Labs Helps

SumoGrowth Labs is an AI implementation and consulting agency. We help operators define approval boundaries, write scoped instructions, set rule packs, and build review habits so dots work stays under operator control. We do not sell software. We implement and set things up. We work with small business owners, operators, and agency operators who need practical systems that fit their workflows.

If you need help defining which actions need approval, writing instructions that prevent scope creep, or training your team to review Activity and Scheduled, we can help. We build the control plan with you, not for you. You own the decisions. We document them, configure the rules, and show your team how to maintain them.

by Darius Gaynor