A summary of the recommended approach for connecting Claude (and other AI assistants) to NetSuite, Smartsheet, and SharePoint with proper permissions, role design, and human-in-the-loop controls.
Projex has connected Claude Teams to NetSuite and is using AI across NetSuite, Smartsheet, and SharePoint. The core challenge isn't whether AI works — it's how to scope what AI can see and do, given that not every team member uses NetSuite, and operational roles often have write access that shouldn't extend to AI by default.
How do we let AI accelerate reporting and analysis across the team — without inheriting transactional permissions, exposing sensitive data, or building infrastructure that NetSuite's native roadmap will obsolete in 12 months?
Oracle now offers an official NetSuite AI Connector Service (the MCP Standard Tools SuiteApp) that connects Claude directly to NetSuite via the Model Context Protocol. This is the right primary path for users with NetSuite access. For team members who don't use NetSuite, scheduled saved-search exports to SharePoint give them AI-assisted reporting without granting them ERP access.
Define exactly which fields, filters, and records each role can see. The saved search is the contract.
Daily, hourly, or on-demand exports to role-organized folders. Auditable, repeatable, traceable.
Claude only sees what the SharePoint folder permissions allow. No direct NetSuite access required.
Read-only by design. Humans review and act on AI-surfaced insights inside their normal workflow.
The NetSuite MCP connector binds to one role at a time per user. Whatever permissions that role has, Claude inherits. This is the safety boundary — and it's why role design matters more than any other technical decision.
If a user has an "AP Clerk" role with write access to bills and journals, and they connect Claude using that role, Claude can also write bills and journals. The right pattern is to create separate, read-only AI roles scoped to functional areas:
Note: Oracle blocks the Administrator role from MCP entirely. Custom roles with the "MCP Server Connection" and "OAuth 2.0 Access Tokens" permissions are required.
The NetSuite role bound to the AI connection determines exactly what Claude can read and do. If the role can't see a field or take an action, neither can Claude.
For exported data, SharePoint folder permissions control which team members' Claude instances can access which datasets. AP team sees AP data. Ops team sees ops data.
For Phase 1, AI is read-only and advisory. Any transaction Claude proposes flows through a human review and approval step before being booked in NetSuite.
Stand up native MCP for NetSuite users with dedicated AI roles. Stand up SharePoint export pipeline for non-NetSuite users. Claude reads, summarizes, and analyzes. Zero write access. Establish trust, document use cases, train the team.
Expand to live API queries (Claude triggers saved searches on demand). Allow Claude to draft transactions for human approval — never to book them autonomously. Add data warehouse layer if cross-system queries (NetSuite + Smartsheet) become a recurring need.
As NetSuite's native agentic AI capabilities mature, evaluate whether to migrate workflows from the custom MCP setup to Oracle's embedded agents. The investments in role design and saved searches transfer cleanly — the front-end changes, the governance doesn't.
AI booking transactions autonomously. Even with the native MCP connector technically able to create and update records, the right design choice is to keep AI advisory until trust, audit patterns, and review workflows are established.
Replacing operational roles with AI roles. Operational users still need their full operational roles for daily work. AI roles are additive and dedicated — used only when connecting an AI assistant.
Custom integration buildout that NetSuite native AI will obsolete. Oracle's roadmap is moving fast. We use the official MCP service where it fits and avoid building custom infrastructure that has a 12-month half-life.