Use the Data Plugin in ChatGPT Work and Codex: Semantic Layers, Permissions, Dashboard Publishing, and Validation

The Data plugin is an analytics workflow, not a permission bypass

OpenAI describes the Data plugin as a way to investigate connected business data in ChatGPT Work and Codex, explain changes, and create interactive dashboards and reports. The practical interpretation for administrators and data leaders is narrower than “ChatGPT can query everything”: the plugin operates only when the workspace allows it, the relevant source connection exists, the source app has been authorized, and the user’s connected account already has permission to the underlying data.

The most important operating rule is that a successful connection does not expand access. According to OpenAI’s Data plugin help documentation, queries use the connected account’s existing permissions, including table, row, and column restrictions. If a finance analyst cannot see a restricted column in the warehouse, the Data plugin should not be treated as a route around that restriction; if a sales manager only has regional row-level access, analysis should be planned around that scoped view.

The plugin can work with approved warehouse sources such as Amazon Redshift, ClickHouse, Databricks, Google BigQuery, MongoDB, and Snowflake. OpenAI also says it can use files and documents from services such as Google Drive and SharePoint when those connections are available, and it can work with BI tools including Omni, Oracle BI, Power BI, Sigma, Tableau, and ThoughtSpot, subject to the connected tool’s capabilities and the user’s access. Those lists should be read as integration categories that still require setup, authorization, and governance rather than as a guarantee that every workspace can immediately reach every source.

This article provides 35 copy-ready ChatGPT Work prompts for enterprise automation connectors and AI connector workflows. The complete 35 ChatGPT-5.6 Work Prompts for Enterprise Automation Connectors article provides the destination-specific detail for this section’s ChatGPT Data Connectors decision because it is the closest match for a marker about ChatGPT data connectors because it focuses on ChatGPT Work connector usage in enterprise automation contexts.

The seven layers to separate before anyone asks a business question

Most failed rollouts happen when teams treat “the plugin is installed” as the whole governance model. A safer mental model is a stack of separate layers: plugin availability, source-app authorization, connected-account permissions, business definitions, analysis behavior, artifacts, and publication. Each layer can be correct or incorrect independently, so troubleshooting must isolate the layer that actually failed.

This layer model matters because a single question can cross several control boundaries. For example, “Why did enterprise churn increase last quarter?” may require a warehouse connection, a BI report definition, account-level row permissions, a customer-segment definition, a quarter-to-quarter comparison, and a decision about whether a resulting dashboard can be published outside the analytics team.

What the Data plugin is

The Data plugin is best understood as a governed analysis assistant inside ChatGPT Work and Codex. It can help users investigate business data that is already connected, inspect changes, ask follow-up questions, and assemble interactive dashboards or reports. In Codex contexts, the same governance principle applies: the tool may assist with data-related investigation or artifacts, but it still depends on workspace policy, connected applications, and the permissions of the account involved.

OpenAI’s guidance emphasizes that users should provide the source, metric, time period, comparison, and authoritative business definitions or semantic layer. That is a concrete prompt-design requirement, not a stylistic preference. If a user asks “What happened to conversion?” without specifying whether conversion means visitor-to-signup, trial-to-paid, sales-qualified-lead-to-opportunity, or invoice-paid conversion, the plugin may produce an answer that is syntactically useful but operationally ambiguous.

This article offers GPT-5.5 prompts for data engineers covering ETL pipelines, data quality, warehouse design, and real-time streaming. The complete 50 GPT-5.5 Prompts for Data Engineers: ETL Pipelines, Data Quality, Warehouse Design, and Real-Time Streaming article provides the destination-specific detail for this section’s Semantic Layer Design decision because semantic layers depend on well-modeled warehouse and data-engineering foundations, making this the most relevant available target for design guidance around governed data structures.

What the Data plugin is not

The Data plugin is not a universal database credential, a replacement for BI governance, a data-quality repair tool, or an auditor of record. It should not be described internally as “ChatGPT can access our warehouse” unless the sentence immediately includes the conditions: approved source, installed plugin, authorized app, connected account, inherited permissions, workspace settings, and required human validation.

The plugin also is not a reconciliation authority. If its answer differs from an existing executive dashboard, OpenAI’s guidance is to review the source, filters, timeframe, and metric definition. That review should be treated as a required validation step because the discrepancy could come from a stale dashboard, a different definition, a permission-limited view, an omitted filter, a source-model change, or a genuine business movement.

The plugin is not a publication safety system by itself. OpenAI states that dashboards published through Sites copy the data used in the analysis into the published Site, so sharing choices must account for data permissions. The key implication is that a user who could query restricted data may create a published artifact containing that data; the decision to share the artifact must be reviewed as a new distribution event, not merely as a link to an existing permission-controlled dashboard.

Operational warning: Treat every dashboard, report, table, or Site created from the Data plugin as a data artifact with its own audience, sensitivity, retention, and approval questions. The fact that the original query honored source permissions does not prove that the published artifact is safe for every recipient.

ChatGPT Work and Codex setting: the administrator’s starting point

Workspace administrators control the Data plugin’s installation policy and access by role or group. This is the first gate because a user cannot build a compliant workflow around a tool that the workspace has not permitted for that user population. Administrators should document which roles or groups are allowed to use the plugin, which data domains are in scope, and which use cases require additional review before results are shared.

Plugin access should be mapped to job function rather than curiosity. A finance planning group may need access to approved revenue and expense datasets; a support operations group may need case-volume and response-time analysis; an engineering analytics group may need product telemetry that excludes sensitive customer fields. Role or group access should reflect those operating needs and should not be used to compensate for weak source permissions.

For enterprise administrators, the practical checklist begins with four questions: is the Data plugin allowed in the workspace, is the relevant source plugin or app configured, does the user’s connected account have the intended access, and is there an approved definition for the metric being requested. A “no” at any point should stop the workflow until the responsible owner resolves that layer.

Authorization is separate from permission

Source-app authorization determines whether ChatGPT Work or Codex can interact with a connected system at all. Permission determines what the specific connected user can see or do inside that system. Those concepts are often confused during rollout because both can produce similar user-facing failure modes: no accessible source, missing tables, incomplete fields, unavailable BI assets, or denied actions.

An administrator can approve or install a connection without granting every user broad data rights inside the source. Conversely, a user may have broad warehouse access but still be unable to use the Data plugin if the workspace has not allowed the plugin or the source app has not been authorized for that context. Troubleshooting should therefore avoid vague labels like “access issue” and identify the failing layer precisely.

Connected actions and outbound sharing require the same separation. OpenAI’s documentation notes that actions and sharing remain subject to tool capabilities, user permissions, and approval requirements. A workflow that creates a report, sends information to another system, or publishes an artifact should include an explicit confirmation step when the action affects other users, external audiences, regulated data, or operational systems.

A baseline prompt that keeps analysis inside the governance model

The opening prompt should constrain the analysis before the assistant queries or summarizes anything. The user should name the intended source, define the metric, set the period and comparison, state the business definition, and request a validation report that exposes filters and assumptions. This does not make the output automatically correct, but it makes errors easier to detect.

Sample prompt for governed analysis:

Use the approved source for <business domain> and analyze <metric name> for <time period> compared with <comparison period>.

Use this authoritative definition:
<paste metric definition, semantic-layer reference, or approved reporting rule>

Before giving conclusions, show:
1. The source or connected asset used.
2. The timeframe and comparison window.
3. The filters, segments, and exclusions applied.
4. The metric definition interpreted from my instructions.
5. Any assumptions, missing fields, or permission-related limitations visible from the analysis.

Do not publish, export, send, or share an artifact unless I explicitly approve that action after reviewing the result.

This prompt structure follows OpenAI’s recommendation to provide source, metric, time period, comparison, and authoritative definitions. It also creates a practical audit trail for the human reviewer: the reviewer can compare the stated source and filters against the BI system, warehouse model, or reporting policy before using the answer in a decision.

Validation starts before publication, not after

The safest operating pattern is to validate analysis before turning it into a dashboard or Site. A reviewer should confirm that the source is approved, the query reflects the intended permission scope, the metric definition matches the semantic layer or reporting policy, the timeframe is correct, and the result is consistent with known reports or explainably different from them.

When a generated dashboard is useful, publication should be treated as a separate approval stage. Because Sites publication copies the data used in the analysis into the published Site, the sharing audience must be evaluated against the sensitivity of the copied data, not only against the viewer’s access to the original warehouse or BI tool. If the artifact includes restricted rows, columns, customer records, employee information, financial details, or nonpublic operating metrics, the reviewer should narrow the artifact, aggregate the data, or avoid publication until the proper owner approves.

The opening rule for this guide is therefore simple: use the Data plugin as a governed accelerator for analysis, not as a substitute for data stewardship. The plugin can help users ask better questions, investigate changes faster, and assemble useful dashboards, but the organization still owns installation policy, source authorization, permission design, semantic definitions, validation, approval, and publication discipline.

Build a governed setup path before the first Data plugin query

OpenAI’s Data plugin guidance makes one control boundary explicit: the plugin can investigate connected business data only when the workspace, source plugin, app connection, and user authorization all permit it. Treat setup as a chain of approvals rather than a single “connect data” event, because a successful connection does not create new warehouse, document, BI, table, row, or column permissions for the user.

The practical operating model is to separate four responsibilities. Workspace administrators decide whether the Data plugin is permitted and who can use it by role or group. Data platform owners decide which warehouse, document, or BI connections are authorized. Application owners approve the individual app or source plugin configuration where required. Business metric owners provide semantic definitions so users do not ask the plugin to infer definitions for revenue, active users, churn, margin, incidents, or other governed metrics from table names alone.

Use the workflow below when enabling warehouse sources such as Amazon Redshift, ClickHouse, Databricks, Google BigQuery, MongoDB, or Snowflake, and when enabling document or file sources such as Google Drive and SharePoint where those connections are available. The same governance pattern also applies when the plugin works with BI tools such as Omni, Oracle BI, Power BI, Sigma, Tableau, or ThoughtSpot, subject to the capabilities of the connected tool and the user’s access inside that tool.

This ChatGPT Sites security and privacy guide covers access controls, secrets, data residency, and safe publishing, supplying a concrete permission-governance model for Data plugin sources and downstream dashboards. The complete ChatGPT Sites Security and Privacy Guide: Access Controls, Secrets, Data Residency, and Safe Publishing article provides the destination-specific detail for this section’s Data Permission Governance decision because the target is specifically about access, secrets, and residency boundaries and is more operationally useful than a broad governance trend article.

Setup matrix: split installation, source authorization, and data permissions

The first matrix prevents a common implementation error: assuming that workspace-level plugin access is enough to make a data source safe to use. OpenAI states that workspace administrators control the Data plugin’s installation policy and access by role or group, while the relevant data-source plugin and included app may need separate setup and authorization. That means enterprise administrators should not mark the rollout complete until both AI-workspace access and source-side access have been reviewed.

Use the matrix as an approval checklist, not as documentation after the fact. A governed rollout should capture the workspace group that can invoke the plugin, the source connection being used, the source account or identity pattern, the metric owner, and the publishing rule before analysts begin producing reports for executives or customers.

Access matrix: map roles to source behavior before enabling broad use

Role-based access control needs to be evaluated at two levels: who can use the Data plugin in the workspace, and what the connected source account is allowed to retrieve. The first level is controlled through the ChatGPT Work or Codex workspace policy. The second level is enforced by the warehouse, document repository, or BI tool through the connected account’s permissions.

This matrix should be reviewed whenever a source permission changes. If a user gains access to a new warehouse schema or document folder, the Data plugin may be able to query that newly available material through the connected account. Conversely, if a source administrator removes a table, row, or column permission, the plugin should be expected to inherit that reduced visibility rather than compensate for it.

Warehouse source setup: favor curated interfaces over raw schema exploration

For warehouse-backed use cases, the safest starting point is a curated semantic layer, governed BI dataset, approved view, or documented mart that already represents the organization’s metric logic. OpenAI recommends supplying the source, metric, time period, comparison, and authoritative business definitions or semantic layer. That recommendation matters because many warehouse schemas contain staging tables, deprecated fields, backfill artifacts, duplicate timestamps, and operational columns that can produce plausible but incorrect analysis if the user asks a vague question.

A warehouse setup record should identify the source system, the approved datasets or schemas, the disallowed schemas if relevant, the metric owner, the intended business audience, and validation obligations. For example, a revenue operations team might authorize a curated bookings view and a finance-approved revenue definition while explicitly excluding staging tables, customer-support free-text notes, and raw personally identifiable information columns from the intended workflow.

Table restrictions should be handled in the source system rather than in user prompts. A prompt that says “do not use payroll tables” is not a substitute for warehouse permissions, because user instructions can be omitted, misunderstood, or copied into another conversation. The authoritative control is the connected account’s existing permission model, including table restrictions, row restrictions, and column restrictions enforced by the warehouse or connected BI tool.

Row-level restrictions require special care because the plugin may produce comparative answers that appear complete while reflecting only the user’s permitted slice. A regional sales leader with row-level access to one territory can ask for “company revenue,” but the result may be constrained to that leader’s authorized rows. The validation step must therefore verify not only the SQL or dataset but also the access scope represented by the connected account.

Column restrictions and masking rules should be tested with representative questions before broad rollout. If a user can query customer records but cannot see email address, national identifier, compensation, health, or other sensitive columns, administrators should confirm that the source system enforces those restrictions when queried through the connected app. Do not rely on the Data plugin to discover and redact columns that the connected account is already allowed to retrieve.

Document and file setup: define corpus boundaries and citation expectations

Document-backed analysis has a different failure mode from warehouse-backed analysis. A warehouse question can fail because the wrong table, filter, or metric definition was used; a document question can fail because the wrong folder, outdated policy, draft contract, obsolete slide deck, or incomplete evidence set was included. When using services such as Google Drive or SharePoint where connections are available, administrators should define which libraries, folders, or document collections are appropriate for Data plugin workflows.

A document setup record should include the business purpose, permitted repositories, document freshness expectations, owner of the canonical version, and handling rule for drafts or archival material. For example, a procurement team might permit analysis over finalized supplier scorecards and approved policy documents, while excluding negotiation drafts, privileged legal advice, and personal working folders.

Ask users to specify whether they want the plugin to analyze documents as evidence, context, or source material for a generated artifact. Evidence analysis requires the response to identify which documents support each conclusion. Context use means the documents can shape interpretation, but the user should still require explicit uncertainty where the documents conflict. Artifact generation, such as creating a report or dashboard narrative, needs a final human check against the authoritative source before publication.

Document permissions also flow through the connected account. If a user has access to a restricted SharePoint folder or a sensitive Drive document, the plugin’s ability to use that content is governed by that connected access and the relevant workspace and app settings. Sharing a generated summary can still create a new exposure path, especially if the summary includes extracted data or sensitive conclusions from documents that recipients cannot access directly.

Use app templates as controlled starting points, not final governance

App templates can speed adoption by giving users a repeatable structure for common tasks such as revenue analysis, support trend summaries, operational review packets, or executive dashboards. They should be treated as governed starting points that encode required fields, validation reminders, and approval steps, not as evidence that every downstream answer is correct or approved for sharing.

A useful app template should force the user to fill in the source, metric, timeframe, comparison, filters, grain, and business definition. It should also include a verification section that asks the plugin to restate the source used, the time period applied, the filters selected, and the metric definition interpreted. This structure turns OpenAI’s recommended question ingredients into an enforceable workflow for analysts and nontechnical business users.

Templates should also identify which outputs are allowed. A template for internal operations may allow draft charts and narrative explanations but prohibit external sharing. A finance template may require reconciliation against an existing report before publication. A legal or HR template may require review by the relevant owner before any generated dashboard, report, or summary is distributed.

Question specification: make the Data plugin’s job narrow and auditable

The best question to the Data plugin is not the shortest question; it is the most auditable question. A vague request such as “Why did revenue drop?” leaves the plugin to infer the source, metric, period, filters, comparison, and definition. A governed request specifies each of those fields and asks the plugin to restate its assumptions before drawing conclusions.

Recommended prompt structure:

@Data
Use source: [approved warehouse dataset, BI object, or document collection].
Metric: [authoritative metric name and definition].
Timeframe: [start and end date, fiscal period, or rolling window].
Comparison: [prior period, target, forecast, segment, cohort, or benchmark already present in the approved source].
Filters: [regions, products, customer segments, statuses, or exclusions].
Required validation: Before analysis, restate the source, filters, timeframe, metric definition, and access-scope limitations you can infer. If the available data does not support the question, say what is missing instead of estimating.
Output: [table, explanation, dashboard draft, report outline, or investigation plan].

The explicit @Data invocation is a practical discipline because it tells the assistant that the user intends to use the Data plugin rather than rely on general model knowledge. Teams should train users to include @Data when they expect connected business data to be used, and to avoid asking business-performance questions in ordinary chat when the answer must come from governed sources.

For warehouse analysis, the prompt should name the approved dataset or semantic layer and should avoid asking the plugin to “find the best table” unless the user is performing a documented discovery task. For document analysis, the prompt should identify the folder, library, or document collection and should ask the plugin to distinguish between finalized, draft, outdated, and conflicting documents where that distinction is visible from the available material.

For BI-tool workflows, the prompt should specify the dashboard, workbook, model, dataset, or metric object that the business already treats as authoritative. Because connected-tool capabilities and user access vary, the user should ask the plugin to state what it could and could not inspect rather than assuming that every underlying calculation, filter, extract, or permission is visible.

Sample governed questions for common operating scenarios

The following examples are sample prompts, not guaranteed outputs. They demonstrate how to specify source, metric, timeframe, comparison, and validation while keeping permission enforcement in the connected systems and preserving human review before publication.

Sales variance investigation:

@Data
Use the approved sales performance source for the North America enterprise segment.
Metric: closed-won bookings, using the Revenue Operations definition that excludes renewals booked before the period start and excludes test accounts.
Timeframe: fiscal Q3 2026 through the most recently closed week.
Comparison: fiscal Q2 2026 and the approved Q3 operating plan.
Filters: enterprise segment only; exclude partner-sourced opportunities if they are not part of the Revenue Operations definition.
First, restate the source, metric definition, filters, timeframe, and any access-scope limitations. Then identify the largest contributors to variance by product line and region. Do not publish a dashboard; produce a validation checklist and draft explanation for review.

Support document analysis:

@Data
Use the approved support policy and escalation document collection.
Question: identify policy changes that could explain an increase in escalations for premium customers.
Timeframe: policies finalized between January 1, 2026 and June 30, 2026.
Comparison: finalized policies in the prior six-month period.
Validation: separate finalized policy language from drafts, archived documents, and documents where status is unclear. List the documents relied on and note conflicts or missing context.
Output: a review memo for the support operations owner, not a published report.

Finance dashboard draft:

@Data
Use the finance-approved revenue dataset and the current executive reporting semantic definitions.
Metric: net revenue, gross margin, and refund rate as defined by Finance.
Timeframe: last closed fiscal quarter.
Comparison: prior fiscal quarter and approved plan.
Filters: company-wide, with breakdowns by product family and geography only where the connected account has permission.
Before creating any dashboard draft, restate source, filters, timeframe, metric definitions, and limitations. Create a draft dashboard outline and identify which figures require reconciliation against the official monthly close report before sharing.

Each sample prompt includes a publication constraint because OpenAI’s guidance warns that dashboards published through Sites copy the data used in the analysis into the published Site. The safest default is to produce a draft, validation checklist, or review memo first, then approve dashboard publishing only after the data owner confirms that the copied-data implication is acceptable for the intended audience.

Validation checkpoints to require inside every answer

A governed answer should not jump directly to conclusions. Require the Data plugin workflow to show the source used, the timeframe applied, the filters included and excluded, the metric definition interpreted, and any limitation caused by permissions or available data. This makes the answer reviewable by a business owner, data steward, or analyst who can compare the output against existing reports.

The validation requirement is especially important when a Data plugin result differs from an existing report. OpenAI recommends reviewing the source, filters, timeframe, and metric definition in that situation. The operational rule is simple: a generated explanation of variance is not a reconciliation; it is an investigation artifact that must be checked against the authoritative report and the data owner’s definition.

Publishing readiness: decide before the dashboard exists

Dashboard generation should have a separate approval gate from analysis. The Data plugin can create interactive dashboards and reports, but a dashboard’s visual polish does not make it an audited source of truth. Teams should decide whether a dashboard is a draft, an internal working artifact, a recurring management report, or a shareable Site before the user asks the plugin to build it.

Published Sites require particular caution because OpenAI states that the data used in the analysis is copied into the published Site. This means the publishing decision must consider the audience of the Site, the sensitivity of copied figures or extracts, and whether recipients would have been permitted to access the underlying data directly. The correct approval question is not “can the analyst see this data?” but “may this copied analysis be shared with this audience in this format?”

Connected actions and outbound sharing also remain separate controls. OpenAI’s guidance says actions and sharing depend on connected-tool capabilities, user permissions, workspace settings, and approval requirements. A governed setup should therefore require explicit approval before the plugin sends results to another system, publishes externally, updates a dashboard, or performs any action that changes the visibility or state of business data.

The final setup deliverable should be a short runbook that users can follow: invoke @Data, name the approved source, specify the metric, timeframe, comparison, and filters, require validation restatement, produce a draft, reconcile against authoritative reporting, and obtain publishing approval where data is copied or shared. That runbook is what turns the Data plugin from a convenient interface into a controlled analytics workflow.

Validate the answer, reconcile the report, and publish only after the data boundary is clear

OpenAI’s Data plugin guidance makes validation a user responsibility: the plugin can investigate connected business data, explain changes, and create dashboards or reports, but users should review the source, filters, timeframe, and metric definition, especially when a result differs from an existing report. Treat every useful answer as a candidate analysis packet that still needs reconciliation, not as an audited record that automatically supersedes your BI layer.

The safest operating pattern is to separate three events that often get blended together in a fast conversation: follow-up investigation, dashboard construction, and publication. Follow-up investigation asks whether the result is plausible; dashboard construction decides how to represent the result for repeated consumption; publication decides who can see the copied analysis output and whether connected actions may run. Keeping those events separate prevents a correct-looking chart from becoming a data-permission or business-definition incident.

Run follow-up investigation before changing the visualization

A good follow-up investigation starts with the most boring question: “What exactly did the plugin query or inspect?” Ask the Data plugin to restate the source system, tables or BI objects used where visible, connected files or documents considered, timeframe, filters, metric formula, and any assumptions it made. If the connected tool or source does not expose those details, the answer should say so rather than invent lineage.

1. Freeze the first answer. Copy the original prompt, answer, timestamp, named source, filters, and visible metric logic into your review notes before asking new questions that could change the thread context.
2. Ask for a lineage recap. Require the plugin to identify the warehouse, BI tool, file corpus, or document source it used, and to distinguish observed fields from inferred business meaning.
3. Ask for a delta explanation. When the result moved versus a prior period, require the plugin to decompose the change by the dimensions that are already governed for that metric, such as segment, region, product, channel, or account tier.
4. Ask for counter-checks. Require at least one alternate cut that could reveal filter leakage, date-boundary errors, duplicate records, or use of a non-authoritative measure.
5. Record unresolved uncertainty. If the plugin cannot verify a definition, source, or permission boundary, preserve that uncertainty in the dashboard notes instead of removing it during formatting.

Recommended follow-up prompt

Restate the analysis packet before we build or publish anything.

Include:
1. The connected source or BI object used.
2. The metric definition you applied, including numerator, denominator, aggregation, and exclusions if visible.
3. The exact timeframe and comparison period.
4. The filters and segments applied.
5. Any assumptions you made because the source, semantic layer, or field descriptions were incomplete.
6. The top three checks a human analyst should perform before this result is used in a dashboard.

Do not create a new chart yet. Separate verified facts from assumptions.

This article teaches how to use ChatGPT structured outputs for reliable JSON with schema validation and error handling in API workflows. The complete How to Use ChatGPT Structured Outputs for Reliable JSON: Complete API Tutorial with Schema Validation and Error Handling article provides the destination-specific detail for this section’s Metric Validation decision because metric validation in data workflows benefits from structured output schemas and error handling, making this a practical adjacent guide for validating machine-readable results.

Reconcile plugin findings with existing reports instead of choosing the nicer number

When the Data plugin returns a number that differs from a standing dashboard, the immediate task is not to decide which output is “smarter.” The task is to reconcile scope, time, filters, source freshness, and business definition. A discrepancy can be legitimate if the plugin is answering a narrower question than the dashboard, but it can be dangerous if it silently used raw warehouse fields instead of an approved metric.

A practical reconciliation note should be short enough to paste into a ticket or dashboard description. Use language such as: “The Data plugin result uses Snowflake source A through the connected account’s permissions, covers fiscal Q3 through the close date, excludes trial accounts, and differs from the Tableau report because the Tableau view includes renewals booked after the close date.” That statement gives an analyst a concrete starting point and avoids vague claims that the AI “found a discrepancy.”

Validate sources and filters as a publication prerequisite

OpenAI states that Data plugin queries use the connected account’s existing permissions, including table, row, and column restrictions, and that a successful connection does not create additional data-source permissions. This is a strength for least privilege, but it also means validation must consider the user’s visibility. A manager with restricted regional access and a finance analyst with broader access may both ask a revenue question and receive different valid answers because the underlying account permissions differ.

• Source validation: Confirm whether the answer came from an approved warehouse source, a BI tool, a connected document store, a file, or a mixture of sources. Mixed-source answers need extra review because file and document context may not share the same governance lifecycle as warehouse facts.
• Permission validation: Confirm whose connected account was used and whether row-level or column-level restrictions could make the answer incomplete for a broader audience.
• Filter validation: Require the plugin to list active filters in plain language and to flag any implied filters derived from the user’s wording.
• Semantic validation: Compare the applied definition against the authoritative metric catalog, semantic layer, BI-certified object, or finance-approved rulebook.
• Freshness validation: Ask for visible freshness indicators where the connected source provides them, and document when freshness cannot be verified from the conversation.

Source and filter validation should happen before visual design because chart formatting can hide errors. A stacked bar chart may look polished even if it includes test accounts, mixes fiscal and calendar periods, or calculates conversion using a denominator that excludes churned users. Require plain-language validation notes first, then approve the visual layout.

Respect BI-tool boundaries when using the plugin to investigate dashboards

OpenAI lists BI tools such as Omni, Oracle BI, Power BI, Sigma, Tableau, and ThoughtSpot as tools the Data plugin can work with, subject to connected-tool capabilities and user access. That wording matters: the plugin’s behavior depends on the connected BI tool, the specific integration capabilities, and the user’s permission in that tool. Do not assume the plugin can modify, publish, refresh, certify, or share BI assets unless the connected tool, user authorization, and workspace settings allow that action.

This tutorial explains how to embed Codex into an internal operations dashboard using an app server, MCP tools, streaming, and human approvals. The complete How to Embed Codex in an Internal Operations Dashboard with App-Server, MCP Tools, Streaming, and Human Approvals article provides the destination-specific detail for this section’s AI Dashboard Workflows decision because it is highly relevant to AI dashboard workflows because it covers production dashboard integration patterns with approvals and operational tooling.

Create dashboards as reviewable analysis products, not decorative outputs

The Data plugin can create interactive dashboards and reports, but a dashboard should be treated as a reviewable analysis product with a stated audience, source boundary, and decision purpose. Start by asking for a dashboard specification before asking for the dashboard itself. The specification should define the business question, the audience, the metric owner, required filters, acceptable granularity, and the decisions the dashboard is allowed to inform.

Recommended dashboard-spec prompt

Create a dashboard specification, not the dashboard yet.

Business question:
[Insert the decision or operating review question]

Required source or semantic layer:
[Insert approved source, BI object, or metric catalog reference]

Audience:
[Insert role or group, not individual names unless needed for review]

Required controls:
- Timeframe selector:
- Segment filters:
- Metric definitions:
- Data freshness note:
- Known exclusions:
- Permission-sensitive fields to avoid:

Output:
1. Proposed dashboard sections.
2. Chart types and why they fit the question.
3. Validation checks required before publication.
4. Sharing risks if this is later published through Sites.
5. Questions that must be answered by the metric owner.

Review the specification with the metric owner before visual creation when the dashboard will be used for operating decisions, customer reporting, budget discussions, regulated workflows, or executive communication. A well-formed dashboard specification prevents the plugin from optimizing for visual completeness when the real requirement is definitional accuracy.

After the first dashboard draft, ask for a “dashboard evidence panel” that can be shown to reviewers. This panel should include the source, timeframe, filters, metric definitions, freshness status if visible, known limitations, and approval status. If the dashboard cannot include that panel directly, maintain it as a companion note in the review ticket or publication request.

Understand Sites publishing and copied-data implications

OpenAI’s Data plugin guidance states that dashboards published through Sites copy the data used in the analysis into the published Site. This is a critical permission boundary: the audience for the Site may not be the same as the audience that could independently query the original warehouse, BI tool, file store, or document system. Publishing can therefore expose copied analysis data to people who would not have reached the same data through the original connected account permissions.

Operational warning: Do not treat a published Site as a live permission mirror of the original data source. Before sharing, review the copied data, aggregation level, sensitive fields, audience, and downstream sharing settings available in the publishing workflow.

The copied-data rule changes how teams should design dashboards for publication. Prefer aggregate views over row-level extracts, remove unnecessary identifiers, avoid columns that encode sensitive attributes, and document whether a viewer is allowed to see the underlying analysis data outside the original system. If a chart only needs a count, do not publish the transaction-level dataset that produced the count.

Perform a sharing review before the dashboard leaves the workspace context

A sharing review should be short, mandatory, and owned. The reviewer should confirm that the dashboard’s audience matches the data classification, that copied data is appropriate for publication, and that the dashboard notes disclose unresolved assumptions. For sensitive or regulated datasets, include privacy, security, legal, records, or compliance review according to the organization’s own policy rather than relying on the plugin conversation as approval evidence.

• Owner approval: The metric or data-product owner confirms that the definition and source are appropriate for the audience.
• Permission approval: The source-system owner or administrator confirms that sharing copied data through the chosen destination is acceptable.
• Business approval: The operational owner confirms that the dashboard supports the intended decision and does not overstate certainty.
• Security and privacy approval: The appropriate review function confirms that sensitive data, personal data, contractual data, or confidential business data is handled under policy.
• Publication approval: The publisher confirms the final Site, report, or outbound destination matches the approved audience and content.

Use explicit status labels such as “Draft,” “Validated for internal review,” “Approved for team sharing,” and “Approved for external distribution” if your organization already supports those states. If no formal labels exist, place the approval status in the dashboard description and review ticket so viewers do not mistake an exploratory dashboard for a certified report.

Automate refresh only when source capability, ownership, and review rules are clear

Refresh automation is not a single Data plugin guarantee; it depends on the connected source, BI tool, app capability, user authorization, and workspace settings. Before automating any recurring update, define whether the dashboard is a point-in-time Site publication, a regenerated report, a BI-tool asset with its own refresh process, or a recurring conversational analysis that a human reviews before sharing.

A safe refresh plan names the owner, source, cadence, freshness expectation, failure notification path, and approval rule for material changes. If the refreshed output can change business decisions, require a human review step before broad redistribution. If the output is informational and low risk, the review can be lighter, but the dashboard should still show when the data was last validated or refreshed where that information is available.

Approve connected actions as separate changes, not as part of analysis

OpenAI’s guidance says connected actions and outbound sharing remain subject to tool capabilities, user permissions, workspace settings, and approval requirements. Treat every connected action as a separate change request, even if it originates from a validated dashboard. Sending a report, updating a ticket, creating a task, posting to a channel, or writing to another system can have consequences that are independent of whether the analysis itself is correct.

Before approving an action, require the plugin or user to restate the destination, recipients, payload, fields included, source of authority, and rollback or correction path. If the action writes to a system of record, require a higher approval threshold than an action that drafts a message for human review. If the action shares copied data outside the original access boundary, repeat the Sites-style sharing review before approval.

Connected-action approval checklist

Approve only after confirming:
- The action is supported by the connected tool and allowed by workspace settings.
- The user has the required permission in the destination tool.
- The payload contains only approved fields and approved aggregation levels.
- The audience or destination matches the sharing review.
- The metric owner has approved the source and definition where required.
- A human approver has reviewed high-impact, external, sensitive, or irreversible actions.
- The team knows how to correct, retract, or supersede the output if an error is found.

The final gate is simple: analysis can be conversational, but publication and connected actions must be governed. If the team cannot identify the source, metric definition, filter set, copied-data audience, refresh model, and approval owner, keep the dashboard in draft and continue investigation before publishing or triggering an outbound workflow.

Operate the Data plugin with owners, gates, and evidence

A production Data plugin program needs an operating model because the plugin can make analysis faster without changing the accountability chain for business metrics, privacy, access, or publication. OpenAI’s guidance says the Data plugin can investigate connected business data in ChatGPT Work and Codex, explain changes, and create interactive dashboards and reports, but the same guidance also says users should verify the source, filters, timeframe, and metric definition. Treat that verification requirement as a workflow control, not as an optional final glance before sharing.

The core rule is simple: the person who can connect to data is not automatically the person who can define a metric, approve a dashboard, publish copied data, or trigger an outbound action. A revenue analyst may have legitimate read access to a curated warehouse table, while the finance metric owner still controls the definition of “bookings,” “recognized revenue,” or “net retention.” A product manager may be allowed to inspect a Tableau dashboard through a connected tool, while the data governance team still decides whether the underlying data can be copied into a published Site.

This article explains how eligible ChatGPT Business and Enterprise Site owners can share a live ChatGPT Site with named external viewers without making it public. The complete How to Share a ChatGPT Site with External Clients Without Making It Public article provides the destination-specific detail for this section’s ChatGPT Sites Sharing decision because it exactly matches the sharing angle of ChatGPT Sites by focusing on controlled external access rather than public publishing.

Role model for governed Data plugin use

Require metric-owner approval before a plugin result becomes a business number

Metric-owner approval should be required whenever a plugin-generated answer will be used in a board packet, financial review, customer communication, operational target, compensation discussion, compliance response, or public-sector reporting package. The approval should confirm that the source, metric definition, timeframe, filters, grouping logic, and comparison baseline match the organization’s authoritative definition. A dashboard that looks persuasive can still be wrong if it uses order date instead of invoice date, gross revenue instead of recognized revenue, or active users instead of billable users.

A practical approval packet should fit on one page for routine metrics and expand only when the analysis is novel or disputed. The packet should identify the connected source, the business question, the semantic-layer version or definition source, the time period, the comparison period, the applied filters, the population excluded, the reconciliation target, the reviewer, and the publication destination. If the Data plugin produced a narrative explanation, preserve the narrative with a reviewer note that separates accepted findings from unverified interpretations.

Metric approval packet template

Business question:
Decision or audience:
Connected source or BI tool:
Authoritative metric definition:
Semantic-layer version or definition owner:
Time period:
Comparison period:
Filters:
Excluded rows, entities, products, regions, or accounts:
Known data-quality limitations:
Reconciliation target:
Sampling method:
Discrepancies found:
Metric owner decision: approve / approve with caveats / reject
Publication destination:
Sharing audience:
Reviewer names and date:

Use standard analysis templates instead of free-form dashboard generation

Standard templates reduce ambiguity because they force the user to specify the same controls OpenAI recommends: source, metric, time period, comparison, and authoritative business definitions or semantic layer. A template also makes follow-up review faster because reviewers know where to find the source boundary, assumptions, caveats, and publication status. For teams using Codex to generate supporting analysis artifacts, the same template should be stored with the work item so the dashboard, notebook, or report can be traced back to its original analytical intent.

Governed Data plugin prompt template

Use only the connected sources I name below. If a required source, table, field, file, dashboard, or permission is unavailable, stop and explain what is missing.

Question:
Approved source:
Approved metric definition:
Semantic-layer reference:
Timeframe:
Comparison:
Filters:
Required breakdowns:
Do not use:
Validation requirements:
Expected reconciliation target:
Publication status: draft only until metric-owner and privacy review are complete.

In your answer, show:
1. The source used.
2. The timeframe and filters used.
3. The metric definition applied.
4. Any assumptions or missing fields.
5. A reconciliation checklist.
6. Questions that require a human owner before publication.

Templates should include a “do not use” field because connected accounts may have access to raw, deprecated, sensitive, or experimental tables that are technically reachable but not appropriate for the analysis. OpenAI states that queries inherit the connected account’s existing permissions, including table, row, and column restrictions; that inheritance prevents unauthorized expansion but does not automatically choose the best governed dataset. The analyst remains responsible for steering the plugin toward approved semantic definitions and curated sources.

Control semantic-layer changes as production changes

A semantic-layer change should be reviewed like a production analytics change when it affects a metric used outside a local exploratory conversation. Changing “active customer,” moving a region mapping, adding an exclusion, or renaming a field can alter trend lines even when the underlying warehouse query still runs successfully. The change-control record should state what changed, which dashboards or reports are affected, whether historical values will be restated, who approved the change, and when plugin templates should be updated.

Use versioned definitions in prompts and review packets whenever possible. Instead of asking for “weekly active accounts,” require “weekly active accounts using the metric definition approved by the Growth Metrics Council on the specified date” or the internal equivalent. If the organization has a governed semantic layer in a BI tool, instruct users to reference that layer rather than asking the plugin to infer business logic from raw table names. OpenAI says authoritative business definitions or a semantic layer improve reliability, but they do not guarantee correctness, so semantic references must still be reconciled against known reports.

Sample enough rows and totals to catch plausible errors

Sampling should combine row-level checks, aggregate checks, and edge-case checks. Row-level sampling verifies that individual records match the expected inclusion rules. Aggregate checks compare totals, counts, and period-over-period changes against an existing report or trusted query. Edge-case checks target boundary conditions such as refunds, deleted accounts, trial conversions, late-arriving events, currency changes, region remaps, and customers with multiple identifiers.

Do not let the plugin’s fluency substitute for sampling. If a result differs from an existing report, OpenAI recommends reviewing source, filters, timeframe, and metric definition. That review should be documented before anyone decides that the new analysis is “better” than the legacy dashboard. Many discrepancies are caused by different grains, calendar rules, inclusion criteria, or data freshness rather than by a single obvious error.

Handle discrepancies with a stoplight procedure

Use a stoplight procedure so analysts know when they can proceed and when they must pause. A green discrepancy is immaterial, explained, and documented; for example, a dashboard refresh at 9:00 a.m. differs from a warehouse query at 9:07 a.m. because new rows arrived between runs. A yellow discrepancy changes interpretation but not the immediate decision; it requires a caveat and metric-owner acknowledgment. A red discrepancy changes the decision, affects external reporting, exposes sensitive data, or cannot be explained; it requires publication hold, owner review, and possible incident triage.

1. Freeze the draft. Preserve the prompt, generated output, source names, filters, timeframe, and dashboard state before changing the analysis.
2. Identify the reconciliation target. Name the official report, approved query, BI dashboard, or metric-owner definition used as the comparison point.
3. Compare definitions before numbers. Confirm grain, calendar, population, exclusions, deduplication, currency, timezone, and refresh timing.
4. Assign severity. Classify the discrepancy as green, yellow, or red based on decision impact and data-sensitivity risk.
5. Document disposition. Record whether the plugin output was accepted, revised, rejected, or escalated for source remediation.

Run privacy review before Sites publishing or outbound sharing

Privacy review is mandatory when a dashboard will be published through Sites, shared outside the original analysis group, exported, embedded, or used to trigger an action in another connected tool. The review should classify the data copied into the published Site, identify the intended audience, confirm whether row-level or column-level restrictions from the original source are still appropriate for the new sharing context, and decide whether aggregation, redaction, suppression, or a narrower audience is required.

A successful source connection does not prove that broader sharing is allowed. OpenAI states that a successful connection does not create additional data-source permissions, but Sites publishing copies the data used in the analysis into the published Site. Those two facts create an operational distinction: source access may be correct for the analyst, while publication may still be inappropriate for a wider audience. Treat publishing as a separate data-handling event with its own approval record.

Prepare an incident path for wrong, stale, or overshared analysis

The incident path should cover at least four scenarios: a dashboard was shared with the wrong audience, a metric was published with an incorrect definition, sensitive copied data appeared in a Site, or an external action was initiated from an unvalidated analysis. The first step is containment: restrict sharing where possible, pause downstream use, notify the dashboard owner, and preserve evidence. Do not overwrite the only copy of the erroneous output before reviewers can determine what was exposed and who may have relied on it.

The response owner should collect the prompt, source list, connected app or BI tool involved, dashboard version, sharing audience, approval history, screenshots or exports where policy permits, and timestamps. The metric owner decides whether the business number must be corrected. Privacy, security, legal, or compliance reviewers decide whether notification, retention, or additional containment steps are required under organizational policy. The workspace administrator should separately review whether role or group access should be narrowed, but access changes should not be used to erase evidence of what happened.

Maintain connectors, templates, and dashboards on a calendar

Maintenance should be scheduled because permissions, schemas, business definitions, and publication audiences drift. A monthly review can confirm whether connected sources still match approved domains, whether group membership is still appropriate, and whether high-use templates reference current semantic definitions. A quarterly review should test representative dashboards against their reconciliation targets and remove drafts that are no longer owned. A major business change, such as a new fiscal calendar, product taxonomy, or customer segmentation model, should trigger an immediate template and dashboard review.

Maintenance also applies to refresh automation. Do not automate refresh merely because a generated dashboard is attractive or because the source connection works. Automation requires a named owner, a known source-refresh pattern, a reconciliation plan, an exception alert path, and a publication policy for stale or failed refreshes. If the connected tool requires separate authorization or approval for actions, treat that authorization as a different control from the analytical refresh itself.

Promotion criteria: from exploration to operational dashboard

Use promotion gates to separate exploration from operational reporting. A draft can be useful for local investigation with minimal ceremony if it stays within the analyst’s permitted workspace and is clearly labeled as unapproved. A team dashboard needs metric-owner approval, source validation, and a stated audience. An executive or external-facing dashboard needs privacy review, reconciliation evidence, publication approval, and a named owner responsible for maintenance and correction.

What connection success and visual polish do not prove

A successful connection does not prove that the user should analyze every reachable table, that row and column permissions are appropriate for publication, that a separate app has been fully authorized for the intended workflow, or that the data is fresh, complete, or governed. It proves only that the connection worked within the connected account’s existing permissions and tool capabilities.

An attractive dashboard does not prove that the metric is authoritative, that the semantic layer was applied correctly, that filters match the business question, that the comparison period is fair, that copied data can be shared through Sites, that external actions are approved, or that the result is ready for executive or public use. Visual polish can make an unvalidated number more persuasive, which is why promotion gates, owner approvals, and discrepancy handling must exist before teams scale dashboard creation.

Conclusion: make the plugin fast inside a slow-enough control system

The safest way to use the Data plugin in ChatGPT Work and Codex is to let it accelerate investigation while keeping governance explicit. Administrators control installation and role or group access. Source owners configure the underlying warehouse, document, app, or BI connection. Connected-account permissions continue to matter. Metric owners approve definitions. Analysts document prompts, sources, filters, and assumptions. Privacy and security reviewers decide whether copied data, Sites publishing, outbound sharing, or connected actions are appropriate.

That operating model preserves the plugin’s practical value without pretending it replaces BI governance, reconciliation, privacy review, or human judgment. When every dashboard carries a source record, semantic definition, validation trail, owner, sharing decision, and maintenance schedule, teams can move faster while still knowing which numbers are drafts, which numbers are approved, and which numbers must stop until the discrepancy is resolved.

Useful Links

• OpenAI Help: Data plugin in ChatGPT Work and Codex
• OpenAI Help: ChatGPT Enterprise and Edu release notes
• OpenAI Help: article 11509118
• OpenAI Help: article 20001256
• OpenAI Help: article 20001494