Build a Private ‘My Assigned Issues’ Dashboard in ChatGPT Sites: Per-User Connections, Testing, and Editor Control

Define a private personal queue before building it

Your job is to build a private “My Assigned Issues” dashboard in which each authorised visitor sees their own issue queue, then prove that the result changes correctly for a second person. This tutorial is documentation-led, reviewed as of 11 October 2026, and not a hands-on benchmark. The build instructions and acceptance tests below are recommendations for your team to execute; they are not reports of a dashboard we have deployed or tested.

Keep the deliverable small: one approved issue tracker, one workspace, one personal queue and a named owner. Do not begin with a company-wide reporting portal. The useful first result is a page that answers “what is assigned to me?” without making the builder’s account the shared source of everyone’s results. A clean layout matters, but the account and permission checks come first. A convincing preview populated with the wrong person’s issues is a failed dashboard.

As of 11 October 2026, OpenAI documents Sites as a public beta for Plus, Pro, Business, Enterprise and Edu, with plan-specific limits. [Sites]

That general Sites availability is not the same as eligibility for this connected-data tutorial.

The Help Centre describes connected-app delegated access as an admin preview for Business and Enterprise. OpenAI’s 29 September 2026 Business release notes document private workspace Sites using supported connected apps, with teammates approving read-only access to their own accounts. [Managing ChatGPT Sites for your workspace; ChatGPT Business release notes]

Use an eligible Business or Enterprise workspace for this tutorial, not a personal-plan assumption.

For creation, OpenAI names Work on ChatGPT web, or Work or Codex in the ChatGPT desktop app; Sites is not available in ChatGPT Classic. The responsibilities page says availability varies by plan and region. The July launch notes excluded the European Economic Area, Switzerland and the United Kingdom from public publishing and the expanded beta rollout at launch; that historical statement is not a complete current regional entitlement list. [Creating and using ChatGPT Sites; Understanding responsibilities for your ChatGPT Sites; ChatGPT release notes]

For the rest of this tutorial, “private” means the intended audience is restricted to approved members of the owning workspace. It does not mean invisible to the owner or administrators, and it is not a promise of a particular storage location. “My” means the person using the dashboard under their own authorised connection. It must not mean the builder, a name typed into a text box, or whichever account happened to populate the first preview. Write those meanings into the project brief so reviewers are checking the same thing.

The fictional Northwind Operations team will be our example. Mira owns the Site, Owen is the second-user tester and Priya is the workspace administrator. These are teaching roles, not a customer story. Start with non-sensitive test issues that your organisation permits you to use. Neither a tutorial nor an output generated by artificial intelligence (AI)Computer systems designed to perform tasks that normally require human intelligence, such as understanding language, recognising patterns, or making predictions. Open glossary entry replaces a qualified security, privacy or legal review. Generated code and suggested operational decisions remain drafts until an accountable person approves them.

Step 1: approve the data and appoint the reviewers

Ask the issue-tracker owner to approve the project or collection used in the pilot. Choose a source in which the two testers have deliberately different assignments. Avoid personnel cases, customer secrets, vulnerability details, medical information and confidential negotiations. You need enough variety to test sorting, empty results and access denial, not a representative copy of the organisation’s entire workload. Prefer ordinary operational tasks whose titles are safe to show to the designated reviewers.

OpenAI states that Sites does not support data residency or inference residency at launch, including deployed Sites, code, storage, artefacts and logs. Its responsibilities guidance also excludes processing protected health information and payment-card data. [Creating and using ChatGPT Sites; Understanding responsibilities for your ChatGPT Sites]

Do not put those data categories into this issue-dashboard pilot.

Give each person a concrete responsibility. Mira approves the audience and the first publication. Priya checks administrative permissions and helps distinguish a missing feature from a denied permission. Owen performs the visitor tests without borrowing Mira’s account. An issue-tracker owner confirms which records should appear. A technical reviewer inspects the generated query and data handling if the operations team cannot do so confidently. A business sponsor decides whether the completed evidence is sufficient to introduce the tool to colleagues.

Keep the approval record compact. State the intended purpose, source, fields, audience, connection mode, reviewers and stop conditions. Do not paste personal data or access secrets into that record. A useful stop condition is “any record appears for the wrong visitor”; another is “the requested permissions exceed those approved for this read-only task”. Treat uncertainty about either condition as a reason to hold publication, not as a reason to give the tool broader access and hope the discrepancy disappears.

• Approve one source and the minimum fields needed for a personal work list.
• Nominate a Site owner, an administrator, an independent visitor and a source-data reviewer.
• Record the intended workspace and the exact approved audience in ordinary language.
• Exclude writes, exports, scheduled runs, cross-workspace sharing and additional connectors from the first build.
• Set the acceptance rule before looking at a generated preview.

For a broader policy conversation before approving the pilot, the guide to Sites security and privacy review covers access controls, secrets, data residency and safe publishing. Use those subjects to organise your own questions, but keep the current official permissions evidence in this tutorial as the basis for the specific personal-queue build.

Step 2: confirm the actual administrative controls

The Help Centre says Business has Sites enabled by default, while Enterprise creation and publishing depend on role-based controls. Those creation and publishing controls do not enable connected-app access. In its admin-preview instructions, a global administrator opens External access, selects ChatGPT Sites and reviews Connectors under Scopes; workspace administrator status alone does not grant authority over that tenant-level setting. [Managing ChatGPT Sites for your workspace]

Ask Priya to verify the actual workspace and organisational scope before making a change. A request should identify the proposed dashboard, its business purpose, the single approved plugin and the intended read-only use. Ask for a narrow approval, not “enable everything needed”. Keep the reply as evidence of the approved scope. Do not ask an ordinary visitor to alter administration settings or to work around a missing control by supplying another person’s connection.

The official pages use different plugin labels and defaults. The Help Centre calls the setting Allow use in Sites and says it is off by default. Sites administration instead names Admin > Plugins > the plugin > Allow site visitors to use this plugin, with unsaved defaults of allowed for Business and Education and off for Enterprise. It says a saved administrator choice overrides the default. [Managing ChatGPT Sites for your workspace; Sites administration]

Record the label and saved value in your workspace rather than assuming one universal default.

This difference in documentation is a practical reason to record what the administrator actually sees. Note the displayed control label, the current saved state, the workspace and the date of review. If the control is already approved and enabled, do not toggle it merely to follow a sequence. If the documentation and your account disagree in a way that prevents the pilot, ask your administrator or support contact to clarify availability. Do not infer that a missing toggle means the restriction has been removed.

Keep an explicit distinction between checking and changing. A check establishes that the chosen plugin is permitted for the intended task. A change alters organisational access and should require the appropriate authorisation. For example, Priya may confirm that an existing approval already covers the pilot and record that no change was necessary. Alternatively, a tenant administrator may need to review a new request. Neither outcome requires Mira to collect administrator credentials.

There is also a scope difference between official pages: the Help Centre describes read-only visitor access, while the Sites guide documents configured write actions requiring visitor consent and an explicit user action. The administration guide says its plugin toggle does not provide separate Sites-specific read and write switches. [Managing ChatGPT Sites for your workspace; Sites; Sites administration]

This tutorial deliberately specifies a read-only dashboard; do not interpret one enablement toggle as proof that write actions are unavailable.

For this build, instruct the agent to omit issue creation, reassignment, closure, comments, labels and all other mutations. Ask the technical reviewer to confirm which actions the generated implementation actually calls. A “read-only” heading in the page is not your acceptance evidence. The evidence should be the approved action inventory, the observed consent request and the test record. If the team cannot determine the action scope, keep the Site unshared until someone with the necessary expertise reviews it.

Specify the result, not just the appearance

Step 3: write the personal-queue acceptance contract

For connected features, the Site must be private to its workspace and the visitor must belong to that workspace. Each visitor uses their own connected account and existing app permissions. An external-viewer invitation does not independently authorise connected-app access. [Creating and using ChatGPT Sites]

Translate that boundary into an acceptance contract that is more precise than “show my tasks”. Ask for issues assigned to the authenticated visitor’s selected provider account, limited to projects that person is already authorised to read. An account connection establishes whose permitted data is available; your dashboard requirement adds the narrower condition that the displayed records are assigned to that person. Check both conditions. Being allowed to read a colleague’s issue is not a reason to include it in a personal assigned queue.

Use a compact set of display fields: issue reference, title, current status, source priority, project and a link to the original record. Request an assignee indication only when needed to make the test understandable. Do not request full comment histories, attachments or personal profiles merely because they might be available. Decide whether completed issues should be excluded by default and how a user can tell which filter is active. Record any state mapping supplied by the source owner rather than inventing a universal list of statuses.

The title “My Assigned Issues” should remain an accurate description after a user changes a project filter. That filter should narrow the visitor’s personal queue, not switch the page into a team-wide search. For the pilot, avoid an editable assignee picker. If stakeholders later want a manager’s team view, define it as a separate deliverable with its own purpose, audience and data review. Do not gradually turn the personal queue into a reporting tool while retaining the original privacy explanation.

Design decision	Recommended pilot rule	Evidence to collect
Whose issues appear	The selected visitor account’s assignments only	Different expected lists for Mira and Owen
Which projects appear	Only approved projects available to that visitor	A source-owner review of allowed scope
Which fields appear	Only the short work-list fields agreed above	A comparison between the brief and visible columns
What happens without access	A clear connection or permission explanation, not substitute data	A declined-consent test record
What actions are possible	Read, filter, refresh and open an original issue	An inventory with no issue-changing actions
Who approves release	The named owner after independent visitor review	A dated human approval and saved candidate reference

Prepare a small expected-results list before building. In the fictional exercise, Mira has “Check meeting-room signage” and Owen has “Review storeroom labels”. A third issue, “Archive completed supplier checklist”, is completed and should follow the team’s explicit completed-item rule. A fourth task is unassigned. These examples are not recommended production records or genuine customer data. Their purpose is to make inclusion and exclusion decisions visible, so a reviewer can explain why each row belongs or does not belong.

Add an access-denied case without asking anyone to inspect material they are not allowed to see. The source owner can establish a harmless restricted test record and tell Owen only that it must not appear. The test should never require Owen to obtain the restricted title or contents. For the record, write “restricted test item absent” rather than copying confidential details into a shared testing document. The testing process should not defeat the boundary it is meant to verify.

Define what an empty state means. “No matching assigned issues” is a successful result only when the account, connection, query and filters have been checked. “Connection needed”, “permission not granted”, “request failed” and “results still loading” should be distinct design requirements. Ask for these states in the brief. Do not allow a generated page to translate every failure into a reassuring zero, or to insert sample issues so that the interface never looks empty.

Decide how much issue text the page really needs. In an operational queue, the short title and original-record link may be enough for a user to choose the next task. A full description can expose unnecessary context, especially during a screen share or a support investigation. Request concise source fields rather than generated summaries for the pilot. If summarisation is later justified, add a separate review for factual accuracy, personal-data minimisation and how uncertainty is shown.

Put ordinary usability requirements alongside the privacy requirements. Ask for clear column headings, keyboard-operable filters, readable focus indicators, text labels rather than colour alone, and a sensible narrow-screen layout. These are acceptance requests, not claims that every generated Site will already satisfy them. A tester should be able to identify the active account context, the applied filters and the result state without guessing from decorative elements or remembering the original build conversation.

Finally, agree what “ready” means. The owner’s preview must match the approved source, the second user must receive their own expected list, a declined connection must not reveal another person’s data, and no editor permission should be required merely to visit. Keep the first audience limited until those checks have evidence. This turns a vague build request into a deliverable a team lead can accept or reject without judging it solely on appearance.

If your team is still deciding what a useful dashboard should contain, the earlier tutorial on building and sharing interactive enterprise dashboards offers wider dashboard context, from initial prompts to team sharing and customisation. This build intentionally narrows that general task to a personal issue queue and requires a separate second-user acceptance record.

Build and review before widening access

Step 4: create a saved dashboard candidate

The documented creation flow is to select Work on web, or Work or Codex in the desktop app, then describe a website or mention @Sites. OpenAI instructs users to review the preview and request changes. Every deployment address is a production deployment; save a version before deploying if you want a reviewable candidate that does not update the live Site. [Creating and using ChatGPT Sites; Sites]

Start a new build conversation for the bounded task. Give the agent the approved specification rather than a collection of unrelated dashboard examples. Name the issue-tracker plugin that the administrator has approved, or ask the agent to identify available options before doing any build work. Do not assume that a familiar product name means the same connector, account or action set is available in your workspace. Stop to review the answer if it proposes another source or a different connection model.

The following is an illustrative build prompt. Replace the descriptive source choice with the approved plugin’s actual name before using it. The prompt requests behaviour; it does not itself enforce permissions or prove that the generated implementation is correct. Keep the acceptance contract beside it, and ask for a saved candidate rather than immediate publication.

Build a website called My Assigned Issues for the Northwind Operations pilot.
I confirm that I am authorised to use the approved test material and connected issue tracker for this purpose.
Use only the approved issue-tracker plugin available in this workspace. If the connector, account mapping or required actions are unclear, explain the blocker before building.
Each visitor must use their own authorised connected account. Show only issues assigned to that visitor within the projects they are already allowed to read.
Do not use my builder connection as a shared account. Do not embed preview results as shared sample data.
Keep the dashboard read-only. Include issue reference, title, status, source priority, project and a link to the original issue. Add project filters and a manual Refresh action.
Do not add issue writes, comments, exports, scheduled jobs, unrelated plugins or a shared copy of retrieved issue content.
Distinguish loading, no matching issues, connection needed, denied permission and request failure. Do not fabricate records or substitute another account when data is unavailable.
Minimise personal data and respect the source material's access and licensing restrictions.
Explain the proposed account mapping, assignment filter and data handling for review by Mira and the technical reviewer.
Save a version for review without deploying it or changing the audience.

Read the proposed approach before accepting the generated page. Look for an explicit explanation of the selected connection, the assignment condition and the requested read actions. If the answer says only “I added authentication”, ask how the current provider account becomes the assignee used in the query. If it proposes a manually entered name, challenge that design. Display names are not the acceptance contract. The contract is the authorised visitor’s own account and the expected records agreed with the source owner.

Keep the first refinement narrow. If the initial layout is acceptable but the completed-item rule is missing, ask only for that rule and a clear filter indication. Do not combine a permissions repair with new charts, extra providers and a visual redesign. Smaller requests make it easier for a reviewer to identify what changed and which tests need repeating. Maintain an ordinary change note in your team’s approved working record: requested change, reason, reviewer and affected acceptance cases.

During building and previewing, ChatGPT uses the builder’s available connections. OpenAI then tells builders to publish privately and ask a teammate to sign in, review requested access and choose their own connected account before broader sharing. [Creating and using ChatGPT Sites]

A correct builder preview is therefore not the documented end of the test procedure.

During Mira’s preview, compare every displayed issue with her expected-results list. Check the actual source record, not a remembered title. Confirm that the displayed assignment, status and priority correspond to the approved query at the time of review. If a source value is missing, ask for a clear missing-value label rather than a plausible replacement. If an issue is deliberately excluded by a filter, record that reason. A row count alone will not explain whether the right rows are present.

Step 5: inspect the personal query and the visible states

The Sites guide explicitly gives a personal issue dashboard as an example: it can show your assigned issues to you and your teammate’s assigned issues to them. Its example prompt asks for grouping by priority, project filters, links to original issues and a Refresh button. [Sites]

Connector availability and the returned fields still need checking for the workspace you actually use.

Ask the agent to explain the query in plain language that the source owner can verify. The explanation should identify the selected provider account, how its identity is resolved, what assignment condition is applied, which projects are included and how completed records are handled. Do not approve a query merely because it contains the word “me”. Require the reviewer to connect that expression to the selected account and to the expected inclusion and exclusion cases.

Make a clear distinction between a query restriction and a visual filter. Your requirement is not “fetch every issue and hide the unwanted rows”. Ask the technical reviewer to confirm that the implementation respects the personal-queue requirement in the data request and returned result, rather than relying only on a cosmetic filter. If the connector’s supported actions cannot express the required scope, stop and redesign with qualified help. Do not present unsupported filtering behaviour as a solved feature.

The page should make its meaning clear without displaying unnecessary identity details. Ask for an appropriate account-context label and a concise explanation that the queue reflects the visitor’s selected connection. Avoid showing personal contact details merely to demonstrate that a sign-in occurred. If several accounts are relevant to one person, require the test record to state which account was chosen. A successful connection to the wrong account is still a failed personal queue.

Review the proposed data handling as part of the build, not as an afterthought. Ask whether issue content is copied into generated page content, a shared database, a downloadable report or an error message. Request an explanation of any retained values and their purpose. Do not accept “private” as a substitute for that explanation. For the pilot, prefer a design that displays the minimum required source fields and avoids creating an additional archive of the team’s issue content.

Use the preview stage to examine uncomfortable cases as well as the attractive populated screen. Ask the builder to show how the page should behave with no matching records, an unavailable source field and a connection that has not been authorised. These can be design walkthroughs using clearly fictional material before the real visitor tests. Label them as such. A walkthrough helps the team agree expected behaviour, but it is not evidence that the connected runtime has enforced that behaviour.

Pay attention to explanatory text. “No work assigned” is too strong if the page is showing one project, an incomplete result set or a failed request. Prefer wording tied to the verified scope, such as “No matching issues for the selected project filter”, but only use a success state after the request has completed successfully. Ask for a neutral failure message that does not expose raw issue content, internal system details or another user’s account context.

The Sites guide says connected data is read on page load using the visitor’s connection and permissions, with caching and reloading managed by Sites. It describes a default Load more action when the connector returns a cursor and recommends asking for a manual refresh action when needed. [Sites]

It does not give this tutorial a universal cache lifetime or guaranteed refresh latency.

Decide what a refresh demonstration must prove. It should show a deliberate attempt to obtain updated results for the current visitor and explain whether that attempt succeeded. Do not promise a refresh interval that your team has not verified. If the design displays a time, ask the reviewer to identify exactly what it represents: the latest successful retrieval, the page opening or another event. A decorative “updated just now” label is not sufficient evidence of a new source response.

Check multi-page results with the source owner. A first page of correct records is not evidence of a complete queue. Ask whether more results are available and how the visitor can request them. Test that adding another page keeps the same person and project constraints. If the first pilot has too few approved records to exercise this, record the pagination case as not executed and do not describe completeness as proven. You can approve a limited pilot with a stated gap only if the accountable reviewer accepts that limitation.

For sorting, preserve the source’s priority meanings rather than inventing an ordering from colour or alphabetic labels. Ask the source owner to approve the intended order. Where priorities are absent, require an explicit unprioritised group. The dashboard should not silently turn missing data into low priority. Similarly, keep status mapping conservative: if a source has several completion states, agree which ones the personal queue excludes rather than letting the generated interface guess from their names.

Inspect the original-issue links. The useful test is not just that a link opens a page, but that it opens the intended record for the current user and does not substitute the builder’s private context. Ask testers to compare the issue reference and title. Do not copy live source addresses into a public support message or article. Keep any detailed test evidence in the organisation’s approved location and use safe descriptions when escalating a problem.

Publish a private pilot, not a public workaround

Step 6: review the audience and approve the first publication

A new Site is limited to its owner and workspace administrators until access is changed. The documented sharing flow uses Share and Who has access, with options dependent on plan and settings, including selected active users or groups and, where supported, anyone in the workspace. [Creating and using ChatGPT Sites]

Public access is a separate option, not a requirement for deploying this private dashboard.

Before changing access, compare the saved candidate with the approved brief. Confirm the source, the personal assignment rule, the displayed fields, the absence of write features and the explanation of connection states. Confirm that the owner knows which candidate will be published. If a later refinement was made after the review, inspect that change before approval rather than assuming it was harmless. The release decision should identify the actual candidate, not simply refer to “the latest version”.

Choose the smallest supported private audience that lets Owen conduct the independent test. Prefer named active members or an approved test group when those options are available. If the available sharing control would admit a much larger audience than the pilot approval covers, pause and ask the administrator to help. Do not select a public audience to avoid an access error. The purpose of this step is to prove a private workflow, not to find any configuration that makes the page load.

Review the saved access list in plain language: who may visit, which group grants access, whether any broader audience setting remains and who may edit. Avoid treating the delivery of a link as proof of a permission change. Ask the reviewer to check the saved audience, then ask Owen to open the Site under his own account. The distinction between intended recipients and actual access should remain visible in the test record throughout the pilot.

After reviewing the audience, the Help Centre’s sharing procedure says to select Publish and then use Visit or Copy link. [Creating and using ChatGPT Sites]

This is publication to the selected audience; the private-workspace connected-data recipe does not instruct the builder to make the Site public.

Have Mira perform the first publication only after the audience and candidate checks are complete. Record the publication time, the approved audience and the candidate reference in the team’s release note. Keep the note free of retrieved issue content unless the review genuinely needs it. Owen’s invitation should explain the test purpose, the intended workspace and the fact that he must choose his own connection. It should not contain a password, shared sign-in instruction or a request to borrow the builder’s account.

Use a short handover message such as the following. It is an editorial template, not a product notification or a claim about a built-in invitation flow. Adjust the names and approved source description to your organisation’s actual pilot.

Owen, please review the private My Assigned Issues pilot using your own approved workspace account and issue-tracker connection.
First open it without granting app access and record the result. Then review the requested access and authorise only the approved connection if you are comfortable doing so.
Compare the displayed issues with your agreed expected list. Do not send issue contents or personal information in the feedback thread.
Report unexpected records, excessive permissions or any apparent write action to Mira. Stop the test if another person's queue appears.
This is a read-only pilot. It is not approval to change issues, invite more people or publish another version.

A request to invite a contractor deserves a separate audience review rather than an improvised change to this pilot. The tutorial on sharing a Site with external clients without public access addresses named external viewers. Treat that as a different sharing task: the connected personal queue here requires membership of the workspace that owns the Site.

A visitor signs in with ChatGPT, reviews the app access requested by the Site and chooses the connected account and access to allow. Visitors may continue without granting app access, but features needing that access will not work. Sharing the Site does not give other visitors access to the builder’s connected accounts. [Creating and using ChatGPT Sites; Sites]

Do not coach the tester to accept every request just to make the page work. Ask them to compare the requested source and access with the approved brief. If something unexpected appears, record the request description safely and stop. If they choose not to authorise the connection, that should be a valid test outcome rather than a personal failure. The team can improve the explanation or reconsider the need for the tool without pressuring the visitor to grant broader access.

Separate “can open the Site” from “can obtain the personal issue list” in the acceptance sheet. A visitor might reach a page yet decline the source connection; another might authorise a connection that lacks the expected project permissions. The test should identify those differences. Do not combine them into one pass or fail labelled “login works”, because that hides which control needs attention and encourages unnecessary changes to the wrong layer.

At the end of this phase, the result should be a deliberately limited live pilot and a pending independent review. Do not announce it as complete yet. The remaining work is to test personal isolation, verify the failed and declined states, and decide whether anyone truly needs editing rights. If stakeholders request extra charts or team summaries during this pause, capture those as future proposals. Keep them out of the acceptance criteria for the first personal-queue release.

When stakeholders ask to turn the personal queue into a wider analytical report, pause and define a new deliverable. The guide to Data plugin permissions and dashboard validation discusses semantic layers, permissions, publishing and validation. Those are useful planning topics, but they do not remove this tutorial’s requirement to verify each visitor’s authorised account and expected records.

Test the second visitor before granting editing rights

Step 7: test with another person’s account

OpenAI’s Sites administration guide explicitly calls for another workspace member to sign in, review access and connect their own account, and for a separate test of continuing without plugin access. It also requires checking that the Site shows data that member is allowed to access. [Sites administration]

Ask Owen to conduct the test in his own signed-in browser session or a separate browser profile, not in Mira’s open session. The recommendation is about reducing test ambiguity: the person performing the test should be able to identify the account and workspace they are using. Do not share passwords or copy a sign-in session between people. If screen sharing is needed for support, agree what may be visible and avoid capturing unnecessary personal or issue information.

Begin with the Site audience rather than the issue list. Have Owen open the approved pilot link and record whether the expected page is accessible. Confirm the workspace and whether he was included through a direct invitation or an approved group. A failed page opening is not yet an issue-tracker query failure. Keep the sequence orderly so a later connection error does not obscure a basic audience mistake. If the account context is unclear, stop and establish it before proceeding.

Next, deliberately decline the app connection. The requested acceptance result is a clear explanation of the connection requirement with no issue records shown. Inspect the page title, counters, charts, empty state and any decorative example cards, not only the main table. A stray issue title in a summary card is enough to fail the personal-data boundary. Record the observed state in neutral words and avoid repeatedly granting and withdrawing access merely to produce a more attractive screenshot.

Then review the consent request and choose the approved provider account. Do not choose a personal account simply because it appears first. Owen should know which source account the expected-results list describes. If multiple accounts are offered and the correct one is uncertain, ask the source owner for help without collecting account secrets. The goal is not to prove that any connection can return data; it is to prove that this visitor’s approved connection returns the intended personal queue.

Compare records rather than impressions. Check that Owen’s expected issue appears, Mira’s exclusive issue does not, and the unassigned test issue follows the exclusion rule. Check the completed-item rule separately. If two testers genuinely share an assignment, note that expected overlap so it is not mistaken for a privacy failure. A useful comparison includes both positive cases, which should appear, and negative cases, which should not. Merely receiving a different row count is insufficient.

Test case	Expected pilot result	What to record
Owen opens the private Site	Access matches the approved audience	Account context and audience route, without secrets
Owen declines the connection	No connected issue content and a clear explanation	Visible state and whether any stray source content appeared
Owen authorises his approved account	His expected assigned records appear	Safe issue references and inclusion reasons
Mira-only test record	Absent from Owen’s personal queue	Absence verified without copying the restricted content
Project filter changes	The result narrows without changing whose queue it is	Filter state and expected included records
More results are requested	Additional records keep the same personal scope	Whether the case was executed and the outcome
Connection or request fails	An honest failure state, not another account’s data	Safe error wording, time and responsible reviewer

Repeat the test after returning to the original account context. Ask Mira to revisit the approved candidate and check her own expected queue again. This is a test recommendation for detecting accidental reuse of a previous result, not a claim about the platform’s cache implementation. Do not assume that two successful first visits cover account changes or repeat visits. If you cannot exercise a transition reliably, mark it untested rather than claiming it passed.

For the refresh test, ask the source owner to make a harmless, approved change to one fictional test issue in the issue tracker itself. Owen can then request refreshed data and compare the relevant field. Record the sequence and observed result without imposing an invented response-time promise. If the source and dashboard differ, keep both observations with their times and investigate. Do not make the dashboard appear current by manually changing a displayed value while leaving the retrieval problem unresolved.

Ask the technical reviewer to inspect any retained or reused results with the same personal-boundary question. The review should determine whether one visitor’s content could be returned to another, whether error handling falls back to a shared sample, and whether filters can change the intended assignee. These are implementation review questions, not declarations that the hosting platform provides a particular isolation mechanism. For a low-code team, uncertainty here is a reason to request qualified help rather than skip the review.

Step 8: record failures and close the test gaps

Create a small evidence record for each executed case: candidate reference, tester, account context, initial condition, action, expected result, observed result, decision and reviewer. Record “not executed” when a required condition was unavailable. Do not convert a proposed test into a completed one by copying the expected result into the observed-result column. Keep sensitive source material out of the record; a safe issue reference or source-owner confirmation is often enough.

Use three decisions rather than a vague confidence score. “Pass” means the observed result meets the agreed condition. “Fail” means the result contradicts it. “Blocked” means the test cannot yet establish an answer. A blocked personal-isolation test should block wider release. A blocked cosmetic check may be handled differently if the owner explicitly accepts that limitation. Write the decision and the reason so a later maintainer does not mistake an accepted limitation for verified behaviour.

When a failure appears, reduce the problem to the smallest safe reproduction. Identify the visitor, connection, filter and expected record involved without sharing its confidential contents. Ask whether the source itself has changed and whether the wrong account was selected. Do not widen project access, make the Site public or grant editing rights as a diagnostic shortcut. Those changes alter the test conditions and can conceal the original problem. Correct one layer, repeat the relevant case and preserve the earlier failed observation.

The Help Centre says visitor-connected access is usable while the visitor interacts with the Site and does not authorise background scheduled tasks. Its scheduling section states that a scheduled task cannot use a visitor’s connected-app access and needs its own supported access to the data source. [Creating and using ChatGPT Sites; Managing ChatGPT Sites for your workspace]

Do not add overnight personal-queue refreshes to this tutorial by reusing visitor consent.

Keep background work out of this acceptance sequence. A stakeholder may want an overnight digest or a morning refresh before anyone opens the page. Record that request as a different workflow requiring its own authority, data source and review. The present dashboard is deliberately visitor-driven. A promise that tomorrow’s queue will be prepared automatically would change the access model being tested, so do not add it as an apparently minor convenience.

Before advancing, ask Owen to explain the page back to Mira. He should be able to describe whose records he is viewing, which filters are active, what to do if the source connection is not available and where to check the original issue. If he thinks the page shows everyone’s workload, the interface explanation needs repair even if the query is correct. The acceptance review includes reader understanding, not just data retrieval.

Step 9: decide whether a collaborator needs Can edit

Site owners can grant Can edit to active members of the same workspace through Share and Who has access. Editors can find the Site in Sites > Shared with you, update it and save versions. After the owner’s first publication, an editor can publish later versions without a separate owner-approval step. [Creating and using ChatGPT Sites]

Do not promote Owen to editor to make his visitor test easier. Visiting the personal queue and changing its implementation are different responsibilities in this pilot. The independent test should establish ordinary visitor behaviour first. Only afterwards should the owner consider whether a maintenance collaborator needs editing authority. A person who wants to report an incorrect label or request a new filter can provide feedback without being entrusted with publication.

The Sites guide warns that editors can read the Site’s live database data. It also says promoting a visitor to editor does not change the Site’s audience setting. [Sites]

Visitor connection consent and the trust granted to a code-and-data editor must therefore be reviewed separately.

Evaluate editor access as a trust decision about the Site’s code and data, not as an enhanced viewing option. Ask what the collaborator needs to change, which data they may encounter, how long they need the role and who will review their work. If the Site holds no shared issue database, record that as a design decision to verify, not as an automatic protection. An editor could propose changes to the design, so the review process must cover future data handling as well as the current screen.

Make a deliberate choice between two operating patterns. In an owner-only pilot, collaborators suggest changes and the owner carries out the reviewed edit. In a shared-maintenance pilot, a trusted editor can prepare and publish changes under an agreed team process. Do not describe the second pattern as technically requiring owner approval if the platform does not impose that gate. If your organisation requires enforced separation of author and publisher, ask the responsible governance team whether the available controls meet that requirement before granting editor access.

The owner retains control over access, the Site name or address, ownership transfer and owner-only settings such as secrets and custom domains. The Sites guide additionally excludes editors from changing audience, managing settings or analytics, restoring an earlier version or making the first publication. The 20 August 2026 changelog documents co-editing with those owner-retained responsibilities. [Creating and using ChatGPT Sites; Sites; ChatGPT & Codex changelog]

For a trusted maintenance collaborator, record the grant in the release record. Include the person’s approved maintenance purpose, the effective date and the review arrangement. Ask them to make one harmless draft change, save the candidate and have another reviewer inspect it before any publication. This exercise should test the team’s procedure as well as the available product role. Keep the change narrow enough that an unexpected publication or audience alteration would be easy to recognise.

Use an explicit editorial rule: no changes to account mapping, query scope, source plugins, persistence or consent wording without a repeat of the personal-queue acceptance tests. A colour adjustment may need only a visual check, while a query change needs the independent visitor suite. The classification should be made by the owner and reviewer, not inferred from how short the prompt was. A one-sentence request can still change the security boundary.

Agree how editors coordinate. For a small team, a single change owner at a time is a sensible recommendation. Have that person state which candidate they are editing and what review is pending. Avoid overlapping instructions in separate conversations unless the team has a reliable way to reconcile them. Do not claim the product automatically serialises or merges every concurrent change; the purpose of this operating rule is to keep the human decision trail understandable.

To remove editing rights, the owner uses Share, finds the editor under Who has access and changes Can edit to Can view or removes the person. OpenAI says the person’s ability to continue viewing depends on the remaining audience settings. [Creating and using ChatGPT Sites]

Removing edit access is not the same operation as proving that all viewing access has ended.

Test an editor downgrade during the pilot with the collaborator’s agreement. After the owner changes the role, ask the collaborator to check that editing is no longer available under the intended account. Then test ordinary viewing separately. If the person remains a permitted visitor, that may be the intended outcome, not a failed revocation. If the goal was complete removal, review all audience routes and verify that broader sharing has not kept the person in scope.

Teams often reuse role names across tools and assume they carry identical powers. The guide to Library viewer and editor governance covers folder ownership, revocation and file custody in that separate sharing surface. Use it to compare the questions you ask, not to import Library permissions into the Sites editor role described here.

Keep the permission review understandable

The administration guide separates network access from plugin authorisation: allowing an external destination does not grant access to a connected app. It also says a plugin’s Sites permission neither connects accounts for members nor replaces visitor consent and connected-service permissions. [Sites administration]

Troubleshooting should identify the failing layer rather than widen unrelated permissions.

Use a permissions worksheet with separate rows for Site audience, workspace membership, plugin availability, organisational approval where applicable, provider account, visitor consent and editor role. Mark who owns each row and what evidence establishes it. This prevents a support discussion from collapsing into the unhelpful phrase “the permissions are fine”. One layer may be correct while another is missing, and the person who can change one layer may have no authority over the others.

A good escalation message identifies the failed step and the intended outcome. For example, “Owen can open the private pilot, but the approved issue-tracker connection is unavailable after he signs into the intended workspace” is more useful than “Sites is broken”. Add the exact safe error wording and the last working observation. Do not attach an entire issue export, a private conversation transcript or another user’s account details merely to give the administrator more context.

End the testing phase with a human decision. Mira should review the completed positive and negative cases, the editor list, any unresolved gaps and the proposed audience for the next stage. Approval should state what has been verified and what remains limited. If a material personal-data boundary is still uncertain, retain the restricted pilot or remove access while investigating. A polished page, an enthusiastic tester or an enabled plugin is not a substitute for that decision.

Operate the dashboard with a recovery plan

Step 10: troubleshoot one failed layer at a time

Use the following table as an editorial diagnostic sequence for the documented controls discussed above. It is not a catalogue of tested defects or guaranteed fixes. Start with the narrowest observation you can establish safely, identify the responsible person and avoid expanding access until you understand the cause. Record the candidate, account context and time, because a later change to the source or Site can otherwise make two observations appear contradictory.

Observed symptom	First recommended check	Safe next action
The builder cannot find Sites	Confirm account, eligible workspace, supported surface and role with the administrator	Resolve entitlement or rollout uncertainty before attempting a different account
The plugin works elsewhere but not in the Site	Review its saved Sites-specific permission and ordinary app availability	Ask the authorised administrator to identify the denied layer; do not enable unrelated plugins
The plugin control is disabled	Read the notice and determine whether tenant approval is relevant	Escalate to the correct organisational administrator rather than a random workspace owner
The visitor can open the page but sees no connection option	Check workspace membership, selected account, plugin availability and consent state	Distinguish a viewer invitation from eligibility to use connected features
The queue is empty after authorisation	Compare the provider account, assignment rule, filters and expected source records	Separate a successful empty result from a denied or failed request
Mira’s issue appears for Owen	Stop the pilot and preserve minimal evidence of the mismatch	Restrict access and obtain technical review before any wider sharing
A count seems smaller than expected	Check filters, completed-item rules and whether more results remain	Mark completeness unverified until the relevant case is checked
A refresh appears ineffective	Compare the source change, request outcome and meaning of the displayed time	Investigate freshness without promising an undocumented cache interval
A visitor is being asked to approve writes	Compare the request with the approved read-only action inventory	Decline the unexpected scope and review the implementation and plugin policy
An editor removal did not end viewing	Review the remaining direct, group or workspace audience routes	Test editing and viewing separately against the actual removal goal
A required external request fails	Ask the administrator to review any applicable destination policy	Do not treat a network allowance as provider-account authorisation

For an empty queue, take care not to over-correct. Ask the source owner whether the expected issue is still assigned to the tester and whether its status falls within the agreed filter. Check that the visitor selected the intended account. If those facts are right, have the technical reviewer inspect the request and response handling. Do not broaden the query to the whole organisation just to make rows appear. That would change the question from “is the personal queue correct?” to “can the source return anything?”

For an apparent cross-user leak, stop ordinary troubleshooting and use the organisation’s incident process. Do not ask additional colleagues to reproduce the problem with real data, and do not circulate a screenshot containing the exposed information. Preserve only the evidence the responsible security team requests, in its approved location. The owner should contain access while qualified reviewers determine what happened. This tutorial is not incident-response or legal advice and does not replace the organisation’s obligations.

When a connector or administrator control is missing, avoid guessing at renamed settings. The official pages already show a label and default discrepancy, so use the control visible in the actual workspace and keep the dated documentation beside it. If the intended approval cannot be verified, hold the deployment. A well-written support request should state the intended read-only personal dashboard, the affected workspace scope, the displayed label or message and the exact point where progress stops.

Step 11: recover without confusing code, access and data

Sites publishing separates saving a deployable version from deploying that version. The Sites guide says to ask ChatGPT to list or inspect saved versions to identify a previous deployment candidate. [Sites]

Use that documented distinction for recovery planning, while treating data changes and access changes as separate review items.

Before the first wider release, prepare a recovery note identifying the last approved candidate and the person authorised to restore service. Include the audience and action inventory that were approved with it. Do not assume that returning to an earlier code version also repairs a permission change or removes data that was copied elsewhere. Review those as separate questions. The proposed recovery should explain what it changes and what remains outside its scope.

If a newly published version is wrong but no sensitive-data exposure is suspected, ask the owner to inspect the earlier approved candidate and decide whether redeploying it is appropriate. Recheck its compatibility with the current source and settings rather than relying on its age or familiar appearance. Then repeat the relevant acceptance cases as both users. Label the recovery complete only after the observed result matches the approved contract; a deployment completion message is not the same as a passed personal-queue test.

If the defect involves audience or connection scope, address that scope before restoring ordinary use. For example, a correct query does not justify leaving an unintended audience in place while a layout repair is made. Decide whether to restrict the Site, remove an editor, disable the relevant plugin path or obtain an administrator’s help. Keep the change list explicit so the team can understand why an earlier candidate was or was not sufficient to recover safely.

Where the administrator controls are available, Sites administration lists Suspend to stop access while investigating and Reinstate to make a Site available again. It also documents restricting a Site’s sharing audience without deleting it. [Sites administration; Sites]

Ask the authorised owner or administrator to use the narrowest effective containment control and verify the visitor result.

Prefer reversible containment while a qualified reviewer investigates, when that is sufficient for the risk. Ask the owner to tell the pilot group that the dashboard is temporarily unavailable and that the source issue tracker remains the place to verify assignments. Avoid a vague message suggesting that people have no tasks. If the team has made the dashboard part of a daily routine, the handover should include the approved alternative workflow so a suspension does not turn into an operational blind spot.

After containment, test access as the previously permitted visitor. Do not rely only on what the owner sees in settings. Record which account was used, whether the page was reachable and whether connected features remained usable. If a view is still accessible, establish whether another audience route explains it before declaring containment successful. Keep the investigation within authorised accounts and avoid experimenting with access-control bypasses.

Step 12: remove access or retire the pilot deliberately

To stop a particular plugin being used in Sites, the administration guide says to turn off Allow site visitors to use this plugin and verify the affected Site. It warns that another allowed plugin may expose the same connector, so disabling one plugin alone is not proof that all access through that connector has ended. [Sites administration]

Distinguish four retirement goals: end one person’s editing, end one person’s viewing, stop the Site from using a connector, or remove the Site entirely. Choose the control that matches the goal and then verify its effect. A visitor may still be an approved editor, an editor may still be an approved viewer after downgrade, or another authorised plugin may provide the same source. The retirement record should describe the desired end state rather than simply say “access removed”.

For a departing collaborator, have the owner and administrator review the person’s Site roles and any relevant wider workspace access through the organisation’s normal offboarding process. Do not ask the collaborator to send connection secrets as part of the handover. Assign a new accountable maintainer before the old owner becomes unavailable. If continuity cannot be assured, prefer a controlled suspension or retirement to leaving a personal-data tool without someone responsible for its behaviour.

For a connection shutdown, identify every approved path used by the dashboard and the scope of the requested change. Ask the administrator to confirm whether the action affects just this pilot or other Sites in the workspace. Notify affected users before a planned removal. Then test that the dashboard produces the intended unavailable-connection state without displaying previously retrieved content as if it were current. Do not promise that disabling one control erases all previously created copies.

Permanent removal is a separate action: OpenAI documents Sites > Delete site, entering the Site slug and selecting Permanently delete. Deleted Sites cannot be restored. [Sites]

We recommend using deletion only after the accountable owner approves irreversible removal, and never presenting it as a reversible pause.

Before deletion, ask the accountable owner to decide what non-sensitive operational evidence should be retained under policy: the approved purpose, access review, test outcomes and retirement decision. Do not preserve a full issue export merely because it might be useful later. Review any separate records or copies created during the pilot according to their own handling requirements. Keep the distinction between deleting the hosted Site and resolving the lifecycle of other material; do not claim universal erasure from one deletion action.

After removal, verify the intended former visitor experience and update the team’s working instructions. Remove obsolete references from the places your organisation controls, and tell users where to find the authoritative issue list instead. Record the date and responsible person. If the pilot is to be rebuilt later, treat the replacement as a new candidate requiring an access review and the two-user tests, not as an automatically approved continuation of the old page.

Maintain a small, honest operating record

Once the pilot is accepted, keep a simple review rhythm chosen by the team. A weekly check may be reasonable for a small operational tool, but the frequency is your policy decision, not a platform requirement. Review whether the owner and editors are still appropriate, whether the approved plugin and source scope have changed, whether users reported incorrect queues and whether the last acceptance evidence still describes the current implementation. Repeat the affected cases after material changes.

Use a change classification that makes retesting proportional. A wording correction needs a content review; a project-filter change needs inclusion and exclusion checks; an account-mapping change needs the full independent-user sequence. Changes to persistence, actions, audience or editor roles require their own access review. Document why a smaller test set was sufficient when you choose one. This is easier to maintain than a large checklist whose completed boxes no longer correspond to the current Site.

Keep the release note short enough that people will use it. State the purpose, owner, source, audience, editor list, candidate, executed tests, unresolved limitations and recovery contact. If the page is still a pilot, say so. If pagination or a particular account transition remains untested, preserve that limitation. Do not replace missing evidence with a percentage confidence score or a claim that the tool is secure in general. The useful statement is what this team checked under these conditions.

Personal-queue release record
Purpose: read-only assigned-issue view for the approved pilot group
Owner: Mira
Independent visitor reviewer: Owen
Administrative reviewer: Priya
Approved source and actions: record the reviewed plugin and read actions
Audience: record the saved private audience and any group-based access
Editors: record approved maintainers, or state owner-only
Candidate: record the saved version reviewed for this release
Tests executed: record positive, negative, declined-consent and repeat-visit cases
Unresolved limits: record blocked or unexecuted cases honestly
Recovery: identify the approved earlier candidate and responsible owner
Decision: human approval required before broader sharing

OpenAI places responsibility for the Site and its content on the operator, including rights to share material and compliance with applicable law. If the Site processes visitor personal data, the operator remains responsible for applicable privacy and data-protection obligations. [Understanding responsibilities for your ChatGPT Sites]

A private audience does not replace that review.

Apply minimisation to the support process as well as the dashboard. Ask users to report the kind of mismatch and a safe record reference rather than copy full issue descriptions into a team chat. Restrict detailed diagnostic evidence to the people who need it. Decide how long the pilot records should be retained and who will dispose of them. Where employment, customer confidentiality or regulated information is involved, obtain the organisation’s qualified advice before extending the data scope.

We recommend keeping retrieved issue content out of a shared dashboard database unless the team has separately approved that storage design. This recommendation combines two documented premises: connected data should use each visitor’s own account, and editors can read live Site database data. It is an editorial safeguard, not a claim that Sites automatically discards every retrieved value or prevents all copying. [Creating and using ChatGPT Sites; Sites]

Resist feature growth that blurs the original purpose. An export button, a team leaderboard, a persistent history view or a background digest may be useful, but each changes the data or authority question. Ask for a separate proposal describing who benefits, what new information is processed, who can see it and how it will be tested. A modest dashboard with clear boundaries is more useful than an ambitious one whose personal-queue promise no longer matches its implementation.

If the team’s actual need is a shared decision page rather than a live personal queue, reconsider the chosen output before expanding this Site. The Space and shared Projects permission comparison covers collaborators, inherited access, linked files and proposed edits. It provides a related planning route without changing the connection and publication checks required for this dashboard.

A private queue needs two-user evidence

The acceptance standard is straightforward: build the approved read-only view, review its account mapping and fields, publish to the smallest suitable private audience, and test it as a different authorised person. Keep visitor consent separate from editing authority, and keep an owner-approved recovery path. Expand the audience only when the evidence supports the personal-queue promise. If the account, permission or data boundary remains uncertain, hold the release rather than disguise the uncertainty with a populated dashboard.

Useful Links

• Creating and using ChatGPT Sites
• Sites
• Understanding responsibilities for your ChatGPT Sites
• Managing ChatGPT Sites for your workspace
• Sites administration
• ChatGPT release notes
• ChatGPT & Codex changelog
• ChatGPT Business release notes