ChatGPT Data: how Sigma and Sites dashboard sharing differ

OpenAI’s Data plugin can turn a business question into a dashboard, but the destination of that dashboard changes what happens next. Publishing an analysis through ChatGPT Sites copies data into a hosted site with its own audience. Building a workbook in Sigma keeps the result inside Sigma’s data and document system, where sharing can itself grant access to underlying information. Neither path makes the audience decision disappear. That distinction follows [OpenAI’s September 10 launch](https://openai.com/index/put‑data‑to‑work/) which lets more employees build and distribute analyses from a conversation, without first handing the request to a data team. Consider a sales director investigating a revenue decline across several regions. The director may be allowed to examine the whole business, while the intended dashboard is for a smaller team. A correct answer to the director’s question is only the start: the published version also needs the right audience, an appropriate way to retrieve data, and someone responsible for keeping it current.

OpenAI introduced the product as the Data agent on September 10; its current setup guide calls it the Data plugin, available in ChatGPT Work and Codex. It combines approved data connections with business context such as metric definitions and existing dashboards. An organization’s definition of revenue or an active customer therefore belongs in the analysis alongside its tables. OpenAI lists warehouses and databases including Snowflake, Databricks, BigQuery and MongoDB, plus document sources such as Drive and SharePoint. The point is to investigate a question across those systems while using definitions the business already trusts, rather than reconstructing a metric from a suggestive column name. [OpenAI’s launch description](https://openai.com/index/put‑data‑to‑work/) sets out those connections and semantic sources. The [Data plugin’s access rules](https://help.openai.com/en/articles/20001518) apply the connected account’s existing table, row and column restrictions. Installing the plugin does not supply missing source access. Workspace availability, enabled app actions and provider authorization are also distinct controls: an available plugin may still contain an app the user cannot access, and an allowed read does not establish permission to perform a write. OpenAI’s [administrator guidance](https://help.openai.com/en/articles/11509118) separates those settings from the policy governing when ChatGPT asks for approval. For the sales director, this means naming the intended source and metric first, then checking the analysis before deciding where its results should go.

The Sigma integration announced alongside Data adds dashboard construction to an existing ability to search and query Sigma. Users can refine charts and filters conversationally, then continue working with the result as a Sigma workbook. The announcement assigns dashboard building to users with a Build license; query access is available more broadly across paid Sigma licenses. Those license descriptions sit alongside operational permissions, so having a subscription that supports a feature does not establish that a particular account can use it on every document.

Sigma’s plugin documentation requires the account’s Use Sigma MCP with OAuth permission. Creating a workbook also requires Create, edit, and publish workbooks; editing an existing one requires Can edit access. The guide then identifies a practical stopping point: the plugin creates new workbooks in Your documents, cannot create them in shared folders, and cannot share a workbook. A returned workbook link is therefore a handoff to a document the team still needs to distribute, rather than evidence that everyone named in the original request can open it.

That next step has its own requirements. Sigma’s sharing guide requires Share documents permission plus ownership or Can edit access. An authorized person can open Share, choose the intended people or team, and assign the appropriate document access. For the revenue dashboard, this is the point to check whether the regional team should view, explore or edit the workbook. The plugin’s ability to produce the analysis does not eliminate that decision or perform it on the publisher’s behalf.

Keeping a dashboard in Sigma retains Sigma’s governance, but that governance is more specific than a promise that every viewer must already have an independent warehouse grant. Under [Sigma’s shared‑document data rules](https://help.sigmacomputing.com/docs/data‑permissions‑overview), a recipient without source access can receive implicit access to query the data as the document owner. Row‑level security remains an exception that protects the data, and OAuth‑authenticated source connections use the viewer’s identity. The distinction is between the person asking Data to build the analysis and the identity used when somebody later opens the shared workbook. They are not necessarily the same. The workbook’s connection settings refine that behavior further. Sigma documents a [Run as service account option](https://help.sigmacomputing.com/docs/run‑a‑workbook‑with‑service‑account‑credentials) under which the published workbook uses configured service‑account credentials instead of each viewer’s OAuth credentials. The toggle requires a Sigma Admin account and an OAuth connection with a configured service account. Without that setting, an OAuth connection uses the viewer’s credentials; a non‑OAuth connection evaluates the owner’s source access and uses the credentials configured for the connection. A workbook combining different connection types can follow different rules for different data sources. These are existing Sigma behaviors that an agent‑created workbook enters, not new permissions granted by ChatGPT. For the sales director, the useful question is consequently more precise than “Does Sigma preserve permissions?” It is whether the intended team should receive the data available through this document, given its owner, connection mode and row‑level restrictions. That is also why an ownership handoff deserves attention: Sigma warns that reducing the owner’s data access can cause errors for recipients relying on implicit access. Sharing the workbook is part of authorizing the report, not merely passing around its URL. A saved copy can change that result again. Sigma’s [data‑access guide](https://help.sigmacomputing.com/docs/data‑permissions‑overview) says someone relying on implicit access becomes the owner when they save a copy, and the copied document queries with their own access. Without the relevant data grants, they may see permission errors even though the original shared workbook worked. Tagged documents introduce another identity: viewers without source access inherit the tagger’s access. The director should therefore test the actual version the regional team will use, including any copied or tagged workbook, rather than checking only the original. Implicit data access also stops short of several interactive capabilities. The same guide excludes stored procedures called by actions, API connectors and credentials used by Call API actions, and MCP connectors used by an agent. A viewer needs direct access to those items. A dashboard that displays its charts successfully may still be unable to perform a button‑driven action for that viewer. These distinctions give the handoff three separate checks: whether the document opens, which identity supplies its data, and whether its intended actions have their own required access.

Sites first has to be available to the publisher. OpenAI’s [current availability guidance](https://help.openai.com/en/articles/20001339‑creating‑and‑managing‑chatgpt‑sites) says it is in public beta, may still be rolling out to an account, and is unavailable in the EEA, Switzerland or the United Kingdom at launch. Free and Go are also excluded. Those limits are separate from installing Data or connecting a warehouse: access to the analysis tool does not establish access to this publishing destination. The Sites route then has a different starting point. OpenAI’s [Data publishing instructions](https://help.openai.com/en/articles/20001518) say that data used in the analysis is copied into the published Site. The audience therefore needs to be appropriate for the information included in that output. The director’s successful source query is not enough to establish that a wider group should receive the copied result. This does not make a new Site public by default: [Sites begins with access limited to its owner and workspace admins](https://help.openai.com/en/articles/20001339‑creating‑and‑managing‑chatgpt‑sites), and available sharing choices depend on the account and workspace. Those choices can distinguish a private invitation from public distribution. Named external viewers receive view‑only access and do not become workspace members or editors. In Enterprise, inviting external viewers requires its own permission; public publishing is off by default and needs administrative enablement. The [workspace administration guide](https://help.openai.com/en/articles/20001338) treats those as separate checks. A company can therefore permit some external viewing without opening a Site to the whole internet. The reader’s task is to check the saved audience against the actual contents of the dashboard, including any detailed tables or files the analysis carries into it. Editing introduces another distinction. Eligible workspace members with Sites editor access can read the Site’s live database and publish later versions once the owner has completed its first publication. They cannot change its audience or invite other people, according to the [Sites developer guide](https://learn.chatgpt.com/docs/sites). An owner who gives a colleague editing access is granting meaningful control over the published report, even while retaining control of its audience. Removing an editor or a direct invitation also requires checking remaining workspace, group or public access; one removed grant does not necessarily remove every way that person can view the Site.

An interactive dashboard is not necessarily an automatically current dashboard. For Sites, Data documents a cloud‑automation option to keep a published analysis updated. That calls for a deliberate refresh arrangement, rather than assuming the initial Publish action established one. Sigma’s workbooks query the connected data platform, but [its freshness documentation](https://help.sigmacomputing.com/docs/caching‑and‑data‑freshness) also describes browser and warehouse caching. Manual or scheduled refresh bypasses those caching options. A report built against live systems can therefore still need an explicit freshness policy, particularly when its readers use it to make recurring operational decisions. | Before sharing | Sigma workbook | ChatGPT Site | |---|---|---| | Confirm the destination | New workbooks start in Your documents; plugin sharing is unsupported. | Published analysis data is copied into the Site. | | Confirm the audience | Check document access, owner, connection credentials and row‑level restrictions. | Check the Site’s saved audience and any external‑viewer permissions. | | Assign maintenance | Establish workbook ownership and refresh expectations. | Assign the owner, appropriate editors and any recurring refresh workflow. | The final check should cover the numbers as well as the access. [VentureBeat’s launch interview](https://venturebeat.com/data/openais‑new‑data‑agent‑skips‑the‑one‑thing‑rivals‑like‑databricks‑are‑racing‑to‑publish‑a‑benchmark) reported that no external‑product accuracy benchmark had been published at launch. A useful handoff for the sales director would identify the revenue definition, source, reporting period and last refresh, then let an intended recipient open the actual published result. If that recipient sees the right information, understands its age and knows who maintains it, the dashboard is ready to become part of the team’s work. Generating the charts is one step in that delivery; the publishing destination determines the rest. *Photo: Greg Brockman, Sam Altman and Frederic Lardinois at TechCrunch Disrupt in San Francisco, October 3, 2019. “TechCrunch Disrupt San Francisco 2019 - Day 2”, by Steve Jennings/Getty Images for TechCrunch. © 2019 Getty Images. Source: [TechCrunch](https://www.flickr.com/photos/techcrunch/48838198916/), via [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Disrupt_SF_TechCrunch_Disrupt_San_Francisco_2019_-_Day_2_%2848838198916%29.jpg), [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/). Cropped for display.*