A Workiva plugin: what works today, and the ChatGPT path

“Why is this still showing last month?” is a familiar reporting question. Answering it can mean finding a source spreadsheet, checking a range, inspecting a Wdata query, and working out whether a refresh or link publication happened. A failed Chain adds another place to look.

We built the plugin to help with that inspection. It gives the assistant a small set of Workiva tools, tied to a configured connection and a list of allowed objects. The answer can point to the spreadsheet, section, table, query, or run that was actually read. It can also say when a needed object was outside the permitted scope or a result was incomplete.

That is the starting point for a useful conversation: enough native evidence to explain the next check. A confident explanation without the right source is not an acceptance test.

The current capability page lists the supported reads and proposal types. The first release is a private pilot, with administrator setup and sandbox acceptance before customer operation.

Version 0.2 has 32 tools across connection discovery, native reads, proposals, and operation status. Tool count is a description of this version, not a measure of how much of Workiva it covers.

In spreadsheets, it can list sheets, read a range of up to 2,000 cells, and inspect native cell or source metadata. It does not infer a cell value from a screenshot. The caller must name a permitted spreadsheet and a sheet that belongs to it.

In documents, it can list sections, read a section’s native text, and inspect content tables. A table ID has to belong to the permitted parent. Reading content is different from checking how that content lays out on a printed page.

In Wdata, it can inspect table schemas and datasets, including accessible freshness metadata. It can inspect existing import error codes and row numbers. Raw error messages are withheld because diagnostics can contain data that should not be passed into the conversation.

For queries, it can inspect a saved query, its job state, and bounded rows from a completed result. A draft-check tool screens SELECT-style text locally and reports whether the saved query’s dependencies are permitted. It does not validate the draft’s table references or ask Wdata to validate, save, or execute the draft.

For data connections and Chains, it can inspect permitted connection status, a Chain’s metadata, and a run’s state. Failed-run inspection returns bounded native failure metadata. It does not fetch raw command output or full logs.

These pieces are deliberately separate. A Wdata table can contain new data while a spreadsheet still contains an old result. A spreadsheet can be current while a linked report still needs publication. The report-not-updating guide explains that sequence, and the Wdata guide covers how tables, queries, and Chains fit together.

A question sometimes leads to a correction. The current service implements proposals for:

• An exact spreadsheet cell edit, including the range and full value matrix.
• A document text insertion at a specified paragraph and offset.
• A run of an existing saved query with reviewed parameters.
• A refresh of one permitted data connection.
• A run of one permitted Chain, in its authorized environment, with reviewed inputs.

Preparing any of these stores a proposal. It does not perform the Workiva action. The proposal carries its target, payload, owner, and expiration so the reviewer can see what will run.

The assistant has no approval tool. A human approves the stored proposal through an authenticated approval page or an explicit operator command. Apply then uses that exact proposal once and observes the native result.

If the source changed, the approval expired, or the actor no longer has the required permission, the request cannot proceed as though nothing changed. If an upstream call times out and the outcome cannot be established, the operation stays indeterminate. Replaying it automatically could duplicate a change or run.

A Chain deserves particular care. Its commands can affect systems beyond Workiva. Approval has to mean understanding the configured Chain and inputs, not just recognizing its name.

The plugin cannot save query SQL, upload or replace datasets, alter table schemas, build arbitrary Chain nodes, change schedules or connectors, stop a Chain, or cancel a query job.

It also cannot publish document links or export reports. It cannot inspect page layout, decide that a reporting package is ready, or establish that a financial number is correct merely because a job finished.

The data-load workflow is useful within those limits. It can compare a supplied CSV’s columns with a permitted table schema and inspect existing import errors. It returns a mapping or validation report. The operator still performs the upload through the normal Workiva route.

Those limits should be visible before installation and during use. A request outside the catalog should produce an explanation of the missing capability, not an invented workaround.

The private build has automated checks for authentication and tenant isolation, object ownership, input validation, separate approval, expired proposals, one-use application, and replay prevention. Tests also exercise the actual MCP tool protocol.

Synthetic scenarios cover a stale reporting flow, an actuals-to-budget comparison, a failed Chain, and validation of a data load. They let us check expected behavior and known failure states without copying client information into fixtures.

Live acceptance is a different record. The current record contains 33 bounded GET checks across all six Workiva areas. It also proves a spreadsheet cell edit, readback and overwrite rollback, and a plain-paragraph text insertion in a document. Those writes used newly created synthetic Workiva files.

The other three change families—saved-query execution, connection refresh, and Chain start—have synthetic test coverage only. The live reads establish their selected objects and responses, not every completed query result, failed run, or customer permission pattern. Every customer connection needs checks against a dedicated Workiva sandbox with known objects, inputs, expected results, and a rollback or readback plan, even if the same code passed elsewhere.

For spreadsheet changes, preflight and readback help detect changes to the source, but they cannot exclude every external writer between checks. The pilot needs one clear owner for the range being changed. For asynchronous queries, refreshes, and Chains, the result needs native completion evidence and any relevant destination check.

This is why “the demo passed,” “the API returned success,” and “the report is ready” are separate statements. The review should name the statement it has actually proved.

First, an administrator sets up a Workiva API integration identity, permitted users, workspace and regional routes, allowed objects, and allowed actions. The integration identity may see different things from a human Workiva user; the service applies its own user and tenant checks on top of that identity.

Next, the operator establishes the private plugin connection through SSH stdio in a Codex-compatible client. This is the client route we have actually tested. A ChatGPT connection requires a hosted authenticated HTTPS MCP service; that service has not been deployed or accepted yet.

The first request should list the available connections and capabilities. That makes the scope visible before anyone assumes the assistant can see an entire workspace.

Then choose one bounded question. For example: “Read this range and show its native source metadata,” or “Inspect this saved query’s completed result.” Include the object and range or run you mean. If a proposed correction is needed, ask for the exact proposal, review it, approve it separately, and check the resulting operation and destination.

Keep API credentials in the configured service environment. Do not paste secrets into a prompt or an inquiry. Before customer use, agree who can approve, which surfaces can change, how ambiguous outcomes are handled, and who owns the final report check.

As of October 1, 2026, this is a private Lockfield pilot with a tested Codex-compatible SSH route. ChatGPT HTTPS hosting and a public plugin-directory listing are still pending. This article is not an install link or a promise of unrestricted Workiva access.

For a pilot, start with one report or data flow and one question the team already spends time answering. We can scope the access, test it in a dedicated sandbox, and document what the team can operate. See the current capabilities and pilot access, or read about our Workiva data and integration work.