WHITE PAPER
Providing a governance framework for full adoption and discussion of abilities.
Every build described in this paper was performed live in a Smartsheet environment. However, the client and schedule data are fictious: created by Emendo for training purposes. The prompts, outputs, findings, and screenshots are real results from the test data.
The role of AI assistants in project environments has changed materially with the introduction of connectors. Until recently, such tools could merely answer questions or generate documents within chat environments while leaving the user to perform the remaining leg work. With the use of connectors, users can ask AI to perform the work itself: allowing them to create advance workflow structures they may lack the technical ability to develop. Smartsheet’s published figures for its Claude connector make the shift concrete: within weeks of general availability, nearly half of all connector usage went beyond simple data queries.
This shift brings greater opportunities for an organization to use Smartsheet to its full potential. The platform is among the most capable workflow tools in enterprise use, supporting hierarchical project structures, cross-sheet formulas, automated reporting, and executive dashboards. That capability, however, requires specialist knowledge that is typically concentrated to a small number of power users, leaving the platform underused by everyone else. The connector narrows this gap. A project manager who could not construct a cross-sheet formula or configure a dashboard can now describe the intended outcome in plain language and direct the AI to build it, placing advanced Smartsheet capability behind a conversational interface.
While incredibly useful, these capabilities carry risks that may be unintuitive to the average user. An assistant that can update a project schedule can update the wrong project’s schedule. A tool that has access to every workspace the user has can reference has greater potential to hallucinate. These risks, however, are not gaps in the technological abilities of AI, but gaps in governance and technical knowledge within an organization.
While the methods discussed in the paper can be applied to any adoption process, we will primarily focus on the adoption path for the Smartsheet connector as well as risk-mitigation strategies: including permission architecture and a small set of named safeguards. To demonstrate the model, we present a complete build comprising a hierarchical program tracker, live data edits, a self-updating dashboard, and an automatically regenerated client deck, performed against a fictional client in roughly thirty minutes.
The first part is addressed to the decision-maker evaluating whether adoption is warranted. The remainder is a demonstration of features, discussion of limitations, and final overview of the processes.
The Smartsheet connector for Claude enables Anthropic’s AI assistant to view, create, and manage Smartsheet work (sheets, reports, workspaces, and dashboards) directly from a conversation. Asked about project status, Claude reads the live data; directed to build a tracker or update a schedule, it performs the operations, subject to the permission controls discussed below. The connector reached general availability in March 2026 and, according to Smartsheet’s published account, was in use at more than 1,400 organizations within its first thirty days.
The connector is built on the Model Context Protocol (MCP), an open standard, originally developed by Anthropic and now governed under the Linux Foundation, that defines how AI models communicate with external systems. For a semi-technical reader, MCP matters for one architectural reason: it standardizes the interface rather than the individual integration. Smartsheet publishes one MCP server describing its operations, and any MCP-capable AI client can use it. For an adopting organization, the practical consequence is that a governance model built for one connector generalizes to the next, because the connector pattern itself is consistent: meaning that these methods should be applicable to most other major models, not just Claude.
Two operating principles define the connector’s security posture, and the remainder of this paper builds on them:
Claude sees what your account sees. The connector operates entirely within the authorizing user’s Smartsheet permission level: every workspace, sheet, report, and dashboard that account can access.
Claude acts only when asked. There is no background scanning or continuous monitoring of the Smartsheet environment. Access occurs on demand, within a conversation, in response to an instruction.
The first principle is the reason account hygiene functions as a governance control: an account with access to many clients gives the connector visibility into all of them. The second is the reason instruction quality matters.
An adoption roadmap is critical to ensure successful adoption of AI. These six stages proved a solid foundation for successful adoption: govern, configure, train, pilot, roll out, and automate.
Figure 1. The Emendo adoption path: governance and training precede business use.
Govern: Developing the business strategy around AI. It’s here you get stakeholder buying to establish what AI tools may be used, who will have access, and establish an AI budget. In this stage, risk assessments are performed before anything is connected. Sensitive data must be secured. Three common risks when using AI tools are: editing in the wrong location (especially when access is granted to multiple clients), data leaking between simultaneously enabled data sources, and vague instructions producing broader changes than intended.
Configure: Using the permission architecture the connector provides to mitigate / eliminate risks. Every tool the connector exposes can be set, per user, to one of three modes: Allow (Claude may use it freely), Ask (Claude must request approval each time), or Deny (Claude may never use it). As a rule of thumb, every tool that writes, edits, or deletes should be set to Ask or Deny, never Allow. Read-only tools may remain on Allow, but the user should be aware that the wrong data could be accessed. Users whose roles never involve editing Smartsheet should set the write tools to Deny outright.
Within the configuration step, organizations should also consider concentrating write authority. Rather than granting every user’s account the ability to create, edit, and delete through the connector, the permission architecture supports a designated-operator model. A small number of individual accounts are authorized for the full set of create, edit, and delete operations, while the remainder of the users operates with those tools set to Deny. This concentrates the highest-risk capability to individuals who are trained for it. It also aligns connector authority with existing Smartsheet roles, in that those who build and maintain sheets hold write access while those who consume them do not, and it simplifies both training and incident review, since every write action traces to a small, known set of operators. The two primary trade-offs are
For organizations handling regulated or multi-client data, that routing is frequently a control worth having rather than a cost to be minimized.
Train: Hands-on practice against fictional data before anyone touches live data: building real assets, triggering real permission prompts.
Pilot: Using the connector in business use case. This could be as simple as creating a simple management sheet to allocate resources, first production use with a defined scope and formal review.
Roll Out: Delivers tool beyond pilot use case. The tool is now available to everyone for routine use.
Automate: Automation removes the human from the loop, allowing models to act upon triggers. Best practices are critical when developing these tools.
Lakeshore Manufacturing (again, a fictional company invented for this exercise) is a mid-sized industrial firm running a multi-week AI adoption pilot across four departments. The program has distinct phases: IT establishes the foundation first (accounts, single sign-on, connector governance, and security review), then develops and delivers foundation training for the whole organization. From here each department run its own integration activities, all rolling up to a single top-level goal of Total AI Adoption. The client’s project lead requires three things: a single source of truth for every task, live visibility she can consult at any time, and a status deck for a recurring steering committee meeting.
Before the first request, the environment was configured per Section 3: all create, add, update, and delete tools set to Ask; read tools on Allow; and every other connector disabled for the working conversation. The entire build that follows (tracker, edits, metrics engine, dashboard, and deck workflow) took roughly thirty minutes of working time from first prompt to finished deliverables.
Five named safeguards recur throughout the builds; we introduce them here and refer to them by name:
Scoped requests. Every instruction names its full target chain (workspace, sheet, and where applicable the specific row) so that nothing is left for the tool to infer.
Plan-before-action. Claude is required to state exactly what it intends to create or change, for review, before doing it.
Permission gating. Write operations sit behind Ask, producing an approval prompt for every individual action.
Source verification. After every AI action, the result is independently confirmed in Smartsheet itself.
ID pinning. Assets are referenced by their unique Smartsheet identifiers rather than by name wherever precision matters, and always in anything automated.
Claude was directed to create a new workspace and, inside it, a seven-column tracking sheet covering task, owner, status, due date, department, percent complete, and completion date, and then to populate it from a structured task list we supplied: eighteen tasks carrying an explicit hierarchy level, so that phases nest under the program goal and department tasks nest under their integration groups. Rather than allowing the tool to improvise structure, the input data encoded it. The request applied plan-before-action (announce every create and add operation before executing) in addition to permission gating (each write individually approved through the Ask prompt).
Claude created the workspace, built the sheet with correct column types, including dropdown and contact columns, and loaded the full hierarchy in a single conversation: the program goal as top parent, three phases beneath it, and department task groups nested below those, with parent rows correctly left without status data. Each write arrived as a separate approval prompt describing exactly what was about to occur.
Figure 2. The generated tracker in Smartsheet: nested phases and department groups, correct column types, and live status data. (The At Risk column at right was added in Build Two.)
Two observations merit attention. First, per-action approval did not meaningfully slow the process. Each prompt takes seconds to review, and that review is precisely the point, since each is an opportunity to identify a wrong target before it becomes a wrong change. Second, supplying structure as data rather than describing it in prose proved decisive. The hierarchy column in the task list converted a generative task into a deterministic one, leaving the tool no interpretive ambiguity. For organizations adopting the connector, this is a reusable technique: where the structure of the output matters, encode that structure in the input.
Editing existing data is the connector’s highest-risk capability, and this build exercised it deliberately. We directed two changes: a single-row status update (one named task moved to Blocked) and a structural change (a new checkbox column automatically flagging any task that was blocked or past due). Both requests used the full scoped-request chain of workspace, sheet, and named row, and both required Claude to state exactly which rows and cells it would touch before touching them (plan-before-action), with permission gating providing the final approval step.
Both edits executed exactly as scoped: one status changed, the new column added, and the risk flags applied only to the qualifying rows, with nothing else touched. The results were confirmed in Smartsheet directly (source verification).
Figure 3. After Build Two: the blocked pilot task and the At Risk flags, applied only to qualifying rows.
The value of this build is the layered-protection model it demonstrates. A scoped request, a stated plan, and a permission prompt are three independent barriers, and an error must pass all three to reach client data. Consider an alternative instruction such as “update the Q3 numbers.” The request contains no scope, has no review before acting, and, if write tools sat on Allow, would meet no gate. The same tool that performed these two precise edits could equally perform fifty imprecise ones; the difference lies entirely in the discipline of the request and the configuration of the permissions.
The client’s requirement for live visibility depended on weekly numbers that exist nowhere as rows: completions per week, forecast per week, and running totals of both. Meeting it involved two distinct components, built in sequence: a metrics sheet that computes those figures from the tracker, and a dashboard that presents them. The two are performed separately because they exercised different connector capabilities and produced different findings.
Claude was directed to design a dedicated metrics sheet computing the weekly figures with live formulas, with actuals counted from completion dates and forecast counted from due dates, together with running totals of each, spanning the full program. The request required Claude to present the formulas it had written and the expected table for approval before creating anything (plan-before-action, applied in this case to generated logic rather than generated structure).
The metrics sheet returned with correctly constructed formulas and a forecast profile spanning the full program. One step, however, required manual completion. Formulas that read data from another sheet depend on Smartsheet’s cross-sheet references. Claude is currently unable to build cross-sheet references. The references were configured manually. Once configured, Claude was able to build complex formulas with the references we provided. The configuration is brief, one-time step and once a reference is established, Smartsheet maintains it meaning any alterations to the formula can be performed by Claude. With the references in place, the sheet automatically updated as changes were made to the schedule sheet.
Figure 4. The formula-driven metrics sheet: weekly actuals counted from completion dates and forecast from due dates.
Two practices from this component are worth adopting. The first is verifying AI-written formulas. Weekly counts were spot-checked against the tracker’s dates (source verification) before treating the metrics as authoritative. The second is planning for the manual reference step. While a simple task, users should be aware of this limitation as on its own, Claude will instead calculate each value and manually update each cell: making a snapshot in time.
We then directed a dashboard drawing on both sheets: an open-task list, paired actual-versus-forecast charts, and status summaries. As with every build, Claude was required to present its plan before creating anything (plan-before-action).
Two attempts were made to deliver a stakeholder ready dashboard. The first attempt produced dashboard where none of the visuals made any sense in the context of the data. The second attempt improved results but did not produce a finished dashboard. The refined direction yielded the correct inventory of components: a weekly progress chart, a forecast trend, and a status summary, each connected to the correct source sheets. The execution of those components, however, remained flawed. The weekly bar chart continued to render each week as its own legend series, with the weeks displayed out of chronological order; the trend chart carried the forecast line but omitted the completed line it was intended to be paired with; a redundant duplicate of the weekly chart appeared alongside the requested one. The dashboard was serviceable as a working draft, and because its charts draw on the formula-driven metrics sheet, the figures present update as the tracker changes. Bringing it to a client-ready standard would require manual correction of the widgets in the Smartsheet interface.
Figure 5. The second-iteration dashboard: the correct components are present and connected, but series configuration, week ordering, chart pairing, and the treatment of parent rows all require manual correction.
This example produced the most interesting result and is worth exploring further. The connector does not create the dashboard deterministically. Claude uses the dashboard operation which creates a dashboard whose widgets are generated by Smartsheet’s own AI (Smartsheet, 2026). This means the request passes through two interpreting systems in sequence: the user’s intent is first interpreted by Claude, and the resulting brief is then interpreted a second time by Smartsheet’s generator as it selects and configures widgets (graphs). When intent is relayed between two independent systems, some loss of fidelity at each step is expected. This essentially acts a game of AI telephone.
It is important to note dashboard operation is among the newest capabilities in the connector, added to its toolset in late June 2026 (Smartsheet, 2026), roughly one month before our build. Smartsheet’s own documentation positions AI dashboard generation as producing a starting point to be reviewed and customized before publishing rather than a finished product (Smartsheet, n.d.). Given that context, the tool performed as expected and is likely to improve in the future.
In its current state the tool has two sound uses. For simple dashboards consisting of single-series charts, counts, and lists, it performs adequately in a single pass. For anything more ambitious, it is best treated as scaffolding: the generator stands up the widgets and their data connections in seconds, and a person then corrects series, ordering, and filters by hand, which remains considerably faster than assembling the dashboard from nothing.
The final requirement was the recurring steering committee deck. Rather than have the AI design slides from scratch on each occasion, we prepared a brand-locked PowerPoint template in advance, with layout, typography, and identity fixed and roughly thirty tokenized data fields for the figures, summaries, risks, and dates. Using Claude’s agentic Cowork mode, we directed a task to read the tracker and metrics sheets and fill the template’s tokens from live data. Two safeguards were central: ID pinning, in that the task references both sheets by their unique Smartsheet identifiers with an explicit instruction never to search by name, and a save-as-new-file rule protecting the template itself. A scheduled recurrence was created to automatically create the deck ahead of each committee meeting.
The workflow produced a finished, on-brand status deck generated from live sheet data, covering status counts, the weekly trend, department progress, flagged risks, and upcoming due dates, reproducible on demand and on schedule, with each run saved as a new dated file.
Figure 6. The second-iteration dashboard: the correct components are present and connected, but series configuration, week ordering, chart pairing, and the treatment of parent rows all require manual correction.
Two lessons from this build justify the structure of the adoption path. First, template-fill is superior to from-scratch generation for repeatable deliverables: fixing the layout converts a creative task into a constrained data task, which is faster, brand-safe, and, critically, verifiable, since every number in the deck traces to a token and a source. Second, and more important: automation converts best practices into requirements. While a human watches, referencing sheets by identifier rather than by name is good hygiene. In a scheduled task that runs with nobody watching, it is the entire safety model; a name-based task pointed at the wrong client’s sheet would repeat its mistake, unobserved, on every run. This is why automate is the final step of the adoption path rather than the first: every safeguard the earlier builds rehearsed is required once humans aren’t monitoring each step.
No tool is without limits, and some only become apparent in use. The following limitations were identified encountered during our use and are listed here for you knowledge.
Deletion Asymmetry: The connector can create an entire workspace but cannot delete one: its delete operations stop at rows, columns, comments, and attachments. Workspace and sheet deletion remain manual actions performed in the Smartsheet interface.
Dashboards Require Constrained Conditions: AI dashboard generation is capable but variable; loosely specified requests produced extra or misconfigured widgets. Explicit widget counts, named series, and a required plan review made results reliable.
Limitation in Smartsheet Workflow Features Automation workflows, such as alerts and approval requests, are built in the Smartsheet interface rather than through the connector. Knowing the boundary between what Claude performs and what Claude guides a user through prevents unplanned interruptions mid-workflow.
Cross-sheet requires additional set up: AI-written formulas referencing other sheets performed correctly in our build but required additional set up from the user.
The model demonstrated above reduces to one table and five habits. The table maps the connector’s capabilities to their risk and mitigation and can serve as a basic reference guide.
The five safeguards of Section 4 are the behavioral half of the model, and they are deliberately tool-agnostic. The three risks named in our work instruction (wrong target, cross-connector leakage, and vague instruction) are in essence three ambiguities: of scope, of source, and of instruction. Every safeguard addresses one of them. As the number of connectors are used across an organization the same safeguards are applicable, with only the tool names changing. The designated operator model of Section 3 generalizes in the same way: concentrating write authority in a small, trained, auditable set of accounts is a control applicable to any connector capable of modifying systems of record.
The Smartsheet connector for Claude is an execution tool rather than a chat feature. Our thirty-minute build produced a governed program tracker, precise live edits, a self-maintaining dashboard, and an automated client deliverable, with every write reviewed and nothing changed unintentionally. None of this required specialized engineering. It required a well thought out permission configuration, five habits applied consistently, and an adoption order that places governance and training before production, with automation last. Companies that adopt these strategies will be able to make full use of Smartsheet, and also have the framework to extend AI across their other service connectors.
Emendo Consulting Group is a project-management consultancy serving clients across industries. Emendo helps organizations adopt AI tooling with the same rigor they apply to any regulated process: governed, trained, and verified.
Disclosure: Lakeshore Manufacturing, its personnel, and all associated data are fictional, created by Emendo for demonstration and training. Adoption and usage statistics for the Smartsheet connector are as published by Smartsheet (March and April 2026). Product capabilities described reflect the connector and Claude Cowork as of July 2026 and are subject to change.
Smartsheet. (2026, June 29). Smartsheet AI & MCP server changelog. Smartsheet Developer Portal. See source here.
Smartsheet. (n.d.). Smartsheet AI features. Smartsheet Learning Center. Retrieved August 03, 2026. See source here.
KEEN TO LEARN MORE?
Our people are the true driving force behind our success. We’ve assembled an incredible team of experts who come from diverse backgrounds, but they all share a common thread: a genuine passion for their industry and an unwavering commitment to exceeding our clients’ expectations.