ChatGPT Dots permissions matter because access to information, permission to act and approval of a finished result are different decisions. A business may want an assistant to read an approved service outline without publishing new website claims. It may want a draft customer response without authorising the message to be sent. Understanding these distinctions makes an ongoing responsibility easier to describe and helps a reviewer know what should happen when a task reaches a boundary or needs a decision.
This guide combines a short account of OpenAI’s documented controls with practical recommendations for a small-business pilot. It is not a claim that every app offers identical permissions or that a conversation can override product safeguards. Check the actual account and connection before relying on a setting. The examples are hypothetical. Their purpose is to help you define useful responsibilities, choose relevant sources and verify the result, while keeping business ownership clear throughout the process.
What the official controls establish
OpenAI says built-in safeguards, app permissions and automatic action review apply to Dots. Its controls guide distinguishes reviewing tasks in Activity from managing recurring work in Scheduled. Custom rules can add boundaries, but they do not override built-in requirements or grant access to an app. Pausing the main task, stopping delegated work and cancelling schedules are separate actions. Read the current controls guide for the exact product behaviour and settings available to your account.
Those product details are the foundation, not the whole business process. Your team still needs to decide which responsibility is being assigned, who owns its result and how it will be reviewed. A technical permission may allow an action while the business brief says to prepare a draft only. Conversely, a brief may request an edit that the connected account cannot perform. Check both layers before assuming that an assignment will work unattended or that the intended boundary is already enforced by a particular connection.
Distinguish access from authority
Access means the task can reach a source or tool. Authority means the business has permitted a particular action for a stated purpose. For example, a document connection may make several project files available, but the brief should identify the approved source for this assignment. The task should not treat every accessible file as current or every suggested action as authorised. Define the scope in plain language, including the specific destination and the circumstances in which a person should be consulted.
Imagine an assistant preparing an internal service comparison. It may need the current outline and a list of customer questions. That does not require permission to change the published offer or send messages. State the output as “an internal draft for review” and make the next decision explicit. The reviewer can then approve wording for a separate publishing stage. This approach avoids conflating useful preparation with the authority to make a company promise, even when both stages use the same underlying information.
Match the source set to the purpose
Begin by asking what the task actually needs to answer the business question. A FAQ brief may need question text and an approved service outline, but not names, addresses or the complete customer record. A project readiness note may need status and ownership, but not unrelated personnel information. Provide a suitable source extract where possible. The practical benefit is clarity: a smaller relevant source set is easier to check and makes it less likely that irrelevant material will dominate the result.
List the sources in the brief and identify their authority. If an old brochure differs from the current outline, explain which record wins. If neither source is confirmed, ask the task to identify the conflict rather than choose the most convenient answer. This is a review principle as well as an access decision. The business should be able to explain why an output says what it says. Wider access does not remove the need for that explanation and may introduce additional contradictions that slow the reviewer down.
Separate read, draft, edit and publish
Use concrete verbs in the assignment. “Read the approved brief and suggest changes” describes a different action from “edit the working document”. “Create a draft post” is different from “publish the post”. If the task contains several stages, write each one separately and state where it must pause for a person. The goal is to make the boundary visible to the assistant and to anyone in the team who later needs to inspect or continue the work.
For a hypothetical website update, the stages could be source review, draft copy, editor approval and publication verification. The first pilot may stop after the draft. Once the review process is reliable, the business can consider a defined edit stage with the actual available tools. Expansion should follow evidence from the previous stage. A successful research result does not prove that the publishing connection works, just as the ability to save a draft does not confirm that its public wording has been commercially approved.
Give approvals enough context
A useful approval request describes the action, destination and result. The reviewer needs to understand what will change and why. “Approve these three FAQ answers for the draft service page” is easier to assess than “may I proceed?” The underlying source should be available, and unresolved facts should be clearly marked. The business should not have to reconstruct the whole conversation merely to decide whether a particular change is appropriate. A concrete result makes review faster and more meaningful.
For example, show the proposed answer, the relevant service-outline section and the current wording if a replacement is intended. Explain whether approval covers the wording only or the action of publishing it. If the destination is a draft, say so. If the change includes a price or timing promise, identify that detail explicitly. The reviewer can then make the actual decision with the needed evidence, rather than approving a broad process without seeing the business commitment that would result.
Account permissions need their own check
An instruction is not evidence that a connection has the capability to perform the requested action. OpenAI’s connection documentation says supported plugins use their connected accounts and permissions. Check the app and computer guide. For a business task, verify the correct account and test a harmless read before depending on a later action. If a connection expires or needs setup, treat that as a blocker and resolve it through the supported sign-in or connection flow.
Avoid solving an unclear failure by repeatedly granting more access. First establish whether the issue is the wrong account, missing source, unavailable action or an ambiguous brief. Each has a different remedy. A task that cannot find the approved outline may simply be looking in the wrong folder. A task that can read a file may still lack edit permission. The business gets a clearer result by identifying the exact missing requirement than by treating unrestricted access as the normal response to any interruption.
Public communication requires an editorial decision
When a workflow prepares website content or customer messages, assign a reviewer who understands the actual offer. That person checks facts, audience and purpose before the material is used publicly. The task should distinguish a proposed claim from an approved one. A draft may contain useful suggestions about explaining a service, but those suggestions should not quietly change the service itself. Good language can support a customer promise; it cannot establish whether that promise is operationally correct.
Consider a proposed sentence that says enquiries receive a reply within one hour. It may sound helpful, but the business must decide whether that timing is supported. Ask the task to flag such commitments and provide the source, rather than improve the sentence’s persuasiveness first. Once the wording is approved, the publishing stage can be assessed separately. This retains commercial ownership and helps prevent a content workflow from turning a stylistic revision into an unintended service guarantee.
Keep review evidence proportionate
Not every task needs a long report. An internal draft can include a short source list and a section for unanswered questions. An edit can show the relevant before-and-after wording. A completed save can identify the destination that the reviewer can open. The evidence should be sufficient for the decision and concise enough that people will actually inspect it. A process that demands lengthy documentation for a minor wording correction may create more administration than the assistance removes.
For recurring work, keep a small record of the assignment, source version, result and review outcome. If the same error appears again, update the brief or source material and note the change. This supports continuous improvement without pretending that the task will never make a mistake. It also helps another team member take over the review. They can understand the current scope and see which problems have been addressed rather than relying on an informal history known only to the original owner.
Treat information as evidence, not instructions
A source document may contain comments, old process notes or text copied from another place. Decide which material is evidence for the task and which instructions actually come from the business owner. A research page telling an assistant to perform an unrelated action should not redefine the assignment. A customer message requesting a price change is evidence of a request, not approval of that change. Preserve this distinction in both the prompt and the review process.
In practice, ask for unusual requests or conflicting instructions to be surfaced. If a source suggests sending private project details to a new destination, that is a new decision that the business needs to assess. The task’s useful response is to explain the conflict and continue whatever preparation remains within scope. The reviewer should be able to see why work paused and what remains possible. This avoids turning a source-reading stage into an accidental expansion of the responsibility.
Verify actions at the destination
If the assignment includes saving or editing, open the destination and check the result. A final message alone is not proof of completion. Confirm the content, status and relevant fields. For a website draft, inspect whether it is actually a draft and whether the requested wording and metadata are present. For a document, check that the final revision was saved in the intended file. Verification should match the action rather than merely confirming that an output was generated somewhere.
If the task cannot complete the action, preserve the prepared result and describe the blocker precisely. “The text is ready, but draft creation is blocked by account access” is useful. “Everything is done” is not. A clear partial result helps the business continue without duplicating research or writing. It also prevents the next reviewer from assuming that an external change happened when only the underlying content was prepared. Successful delivery and useful preparation should both be reported accurately.
Plan how a responsibility ends
Give a pilot a review date and an owner. Decide what should happen to active work, recurring schedules and saved results when the pilot ends. These are separate practical questions. A team member saying “we are finished with this campaign” may not describe which ongoing tasks should stop. Keep a current list of responsibilities and ask for confirmation when changing their status. Check the product’s controls rather than relying on the end of a conversation as the stopping mechanism.
Retain any useful source and draft records before making changes that remove access or delete work. Also check what has already happened. Stopping future activity does not reverse an earlier edit or recall a message. If something needs correcting, inspect that destination and address the actual change. This is an operational habit the business should apply to any automated process: understand what is pending, what is complete and what still requires a person, then act on those categories deliberately.
A permissions brief you can adapt
Use an original template such as: “Prepare [specific internal result] using [approved sources]. You may read those sources and create a separate draft in [destination]. Do not publish, send messages or alter the approved service record. Bring conflicting facts and requests outside this scope to [reviewer]. Report unavailable sources and preserve any completed preparation. Completion means the draft can be opened, its claims are supported and unresolved decisions are clearly listed.” Adapt each detail to the actual task and available tools.
The template is useful because it describes permitted preparation and the point at which judgement returns to a person. It is not a substitute for reviewing app permissions or product requirements. Test whether the intended source and destination are available before giving the task an ongoing responsibility. Then check the first result carefully. If the boundaries are unclear, improve the brief before adding more sources or actions. Clear scope makes a permissions decision easier to understand and a task easier to evaluate.
Common permissions questions
Does connecting an app authorise every possible action?
Plan the task around its actual scope and verify the connection’s permissions. The business brief should state the particular action it intends, including whether the result is a draft or a public change. Do not assume that accessible information is approved for every audience. A useful assignment connects a defined purpose, relevant sources and an inspectable result, with a person responsible for decisions outside that scope.
Can a custom rule make every task unattended?
No instruction should be treated as a promise that every action can proceed without interruption. Check the current product controls and actual connection requirements. A well designed process anticipates missing information, sign-in needs and decisions that require a person. The goal is useful progress within a clear responsibility, with an accurate report of what is complete and what remains blocked.
Build confidence through a defined pilot
Start with a small internal result, narrow sources and a named reviewer. Separate preparation from external action and verify delivery in the actual destination. Expand only after the first stage is useful and understood. The final article in this series brings these principles together in an advanced weekly workflow, showing how sources, stages, review and completion checks can form a practical system rather than a collection of disconnected AI requests.
