How to Set Up Connectors in Oracle AI Agent Studio — SharePoint, Web Crawler & Custom Content Sources

A Connector in Oracle Fusion AI Agent Studio is the governed pipe that lets an AI agent read from — or write to — a system outside itself, such as SharePoint, a public website, a custom knowledge base, or a chat app like Slack or Microsoft Teams, without ever bypassing Oracle's identity and permission model. Strip away the branding and a connector is really just three promises stacked on top of each other: I know how to talk to this external system, I know who is allowed to see what it returns, and I will keep that content fresh on a schedule. Everything else in AI Agent Studio — the agent's reasoning, its prompts, its guardrails — is only as good as the data the connector hands it. 🔌

This matters because the fastest way to sink an enterprise AI rollout isn't a bad prompt — it's a connector that leaks the wrong document to the wrong employee, or one that silently stops syncing and lets an agent answer customer questions from six-month-old policy text. Oracle ties every connector to its Content Intelligence security model and to real named companies already staking service-level metrics on it: TIM Brasil built agents on Oracle Cloud Infrastructure to run call-center workflows and reported 90% accuracy with 30% faster service times, and Oracle brought ABC Corp in as a launch partner specifically to operationalize agent workflows "at scale" across Fusion customers. Get connectors wrong and none of that materializes — the agent just becomes a well-spoken guesser. 🏢

📑 In This Post

1. What a Connector Actually Is (and the Kid-Friendly Version)
2. The SharePoint Connector — Reading Enterprise Files Safely
3. The Web Crawler Connector — Turning Websites into Agent Memory
4. The Custom Content Source Connector — Your Own Living Database
5. External Application Connectors — Slack, Jira, Confluence, Gmail, MCP & More
6. Client Connectors — Putting the Agent Inside Teams and Slack
7. Enterprise Rollout at Scale: Governance, Ownership, Metrics
8. Common Mistakes (and Why Teams Keep Making Them)
9. FAQ
10. References & Further Reading

🔀 Quick Comparison

Connector Type	What It Connects To	Sync Model	Typical Use
SharePoint Connector	Microsoft SharePoint sites/files	Scheduled job, files copied in as attachments	Policy docs, HR handbooks, support KBs
Web Crawler Connector	Public or intranet websites	Scheduled crawl with depth/scope control	Product pages, FAQs, help centers
Custom Content Source	A schema you design yourself	No batch job — agents write directly, live	Event logs, case notes, proprietary datasets
External App Connector	Slack, Jira, Confluence, Gmail, Drive, MCP servers	Function-level calls, exposed per tool	Ticket lookups, sending mail, searching docs
Client Connector	Slack app / Microsoft Teams app	Live bot conversation, no content sync	Letting employees chat with the agent in-app

1. What a Connector Actually Is (and the Kid-Friendly Version)

Picture a school library where the librarian will only hand a book to a student if that student's library card says they're allowed to read it. The librarian also keeps a cart that goes around every morning, picking up new books from the classrooms and shelving them so they're ready before anyone asks. In AI Agent Studio, the connector is that librarian-plus-cart: it fetches content from an outside place (SharePoint, a website, Slack), checks who's allowed to see it, and keeps the shelf updated. The AI agent never goes rummaging through SharePoint itself — it always asks the librarian. 🧸

Mechanically, a connector in AI Agent Studio is a configured integration record — Oracle's own architecture separates the connector (the credentialed link to a system) from the tool (what you expose to an agent) and the agent (which decides when to call the tool). This three-layer separation is not decorative. It means a security administrator can rotate a SharePoint client secret without touching a single agent prompt, and a solution architect can expose only two of a Slack connector's ten functions to a given agent — say, "search channel history" but not "post message" — without disabling Slack access for everyone else.

✅ Worked example: Oracle's own implementation playbook uses a fictional company, Vision Corp, that sells laptops and servers. Vision Corp's admin, John Allens, holds both the IT Security Manager and Knowledge Author roles — which matters, because creating a connector touches security policy (who can see synced content) and knowledge authoring (how that content becomes searchable articles) at once. That dual-role requirement is the single most under-planned line item in real rollouts.

🎯 Use this when: you're deciding who on your team even qualifies to build a connector — treat it as a security decision, not just an integration task.

2. The SharePoint Connector — Reading Enterprise Files Safely

Kid analogy first: imagine your school keeps every worksheet in one giant filing cabinet, but different drawers are locked for different grades. The SharePoint Connector is like a trusted teacher's aide who has a master key, but who still checks your hall pass before opening any drawer for you — so a 3rd grader never accidentally gets handed the 8th grade final exam. 🗂️

Under the hood, this connector authenticates to SharePoint via OAuth 2.0 against a Microsoft Entra ID app registration — meaning Fusion has to be registered as a real application inside your Microsoft tenant before Oracle ever touches a file. It then pulls files in on a schedule and stores them as attachments on generated knowledge articles, all filtered through Oracle's Content Intelligence permission model rather than exposing raw SharePoint ACLs directly to the agent.

Implementation steps (SharePoint Connector):

1. In Microsoft Entra ID, register Fusion as an application; record the Client ID, Client Key/Certificate, and Tenant ID.
2. From your SharePoint site, note the Site Name (the segment right after /sites/ in the URL).
3. In Fusion, go to Tools > AI Agent Studio > Credentials > Connectors > Add Connector, search "SharepointO365," and add it.
4. Name the connector, keep the autogenerated code (you'll need this exact code later for data security policies), and choose a Family and Product (e.g., CX / Service).
5. Enter the Client Key and Client Certificate under Authentication.
6. Choose "Start From Root Folder" or hand-pick specific folders — start narrow, since SharePoint sites can hold enormous file counts.
7. Click Create, then schedule the "Content Intelligence SharePoint Connector Job" (Tools > Scheduled Processes) to run daily so content stays current.
8. Grant Authoring access to admins who need to troubleshoot or adjust content security for synced files.

💡 Contrasting example / warning: Files aren't guaranteed to sync just because the job ran. Attachments are capped at 100 MB, and only allow-listed file extensions get attached to articles — unlike Vision Corp's tidy laptop manuals, a real enterprise SharePoint site often has CAD files, video walkthroughs, or huge PDFs that silently fail the job and never reach the agent. Always check the process log for the "succeeded" file count, don't assume success from a green checkmark alone.

🎯 Use this when: your source of truth is document-based (policies, manuals, contracts) and already lives in SharePoint with existing permission structures you want to inherit rather than rebuild.

3. The Web Crawler Connector — Turning Websites into Agent Memory

Kid analogy: think of a kid with a backpack walking through a neighborhood, but only allowed to knock on doors the map says are okay, only going a certain number of streets deep before turning back, and writing down what each house told them in a notebook everyone can search later. That's the Web Crawler Connector — it starts at one URL, follows links to a configured depth, respects robots.txt and site rate limits, and normalizes whatever it finds (HTML, PDFs) into searchable text. 🚶

"Crawl depth" is the detail teams most often misjudge: depth 1 is only the starting page, depth 2 pulls in every page directly linked from it, and so on — so a shallow depth on a documentation hub might miss entire product lines that sit three clicks deep, while too high a depth can accidentally ingest an entire marketing site's blog archive nobody wanted the agent quoting from.

✅ Worked example: Continuing Vision Corp — after the SharePoint connector, John Allens creates "Vision Web Connector" pointed at the public support site, so customer-facing agents can answer product questions using the same pages a human agent would browse to, without anyone manually copy-pasting content into a knowledge base.

Implementation steps (Web Crawler Connector):

1. Go to Tools > AI Agent Studio > Credentials > Connectors > Add Connector, search "WebCrawler," and add it.
2. Name it, keep the connector code, set Family/Product, and add a description.
3. Provide the Article ID Prefix (used to tag every generated article, e.g. VWEB).
4. In the Configure section, set the Starting URL and Crawl Depth. The connector also supports basic form authentication and JavaScript-rendered navigation for gated or app-like sites.
5. Assign a User Group (e.g., Content Intelligence Users) to control visibility of crawled content.
6. Click Create, then schedule the same Content Intelligence sync job used for SharePoint — the crawl content lands in the search index, but note the raw page text doesn't display inside the generated article itself.

🎯 Use this when: your source of truth lives on the open web or an intranet site with no native SharePoint/Confluence structure — support portals, product pages, public documentation.

4. The Custom Content Source Connector — Your Own Living Database

Kid analogy: this one is like handing a kid a completely blank notebook and letting them design their own labeled sections — "My Pet Facts," "Homework Due Dates" — and then letting them (or their friends) keep writing new entries in it forever. Unlike SharePoint and Web Crawler, which pull from something that already exists, a Custom Content Source starts empty, and you define its shape yourself. 📓

This is the connector type enterprises underuse the most, because it's the only one built for agent-generated, living data rather than static document ingestion. Fields carry a Field Type (e.g., Full Rich Text Area), a searchable flag, and lifecycle metadata — start, review, and end dates — so content can auto-retire instead of quietly going stale forever, and agents can create, update, retrieve, or delete entries programmatically as part of an automated flow rather than a human authoring every record.

✅ Worked example: In Oracle's own reference implementation, Vision Corp builds a "Customer Appreciation Events" content type with a Body field and an Event Date field, both marked Searchable — letting an agent later answer "what events are coming up this quarter?" against structured, current data instead of a static PDF someone forgot to update.

Implementation steps (Custom Content Source Connector):

1. Go to Connectors > Add Connector, search "Custom Content Source," and add it.
2. Set Name, Description, and Reference Key (record this key — you'll need it for Data Security Policies).
3. Set an Article ID Prefix; every generated record inherits it (e.g., VCC37).
4. Decide whether to allow unrestricted JavaScript/HTML in rich-text fields — leave this off unless you specifically need it, since it's a deliberate XSS/content-injection guardrail.
5. Design the Content Schema: edit the default Title field's description, then add fields like Body (Full Rich Text Area, Searchable) and any domain-specific fields (dates, categories, IDs).
6. Optionally enable file attachments for the content type.
7. Click Create — no sync job is needed here; content populates live via Authoring UI or the /v2/articles REST API, including from within an agent's own workflow.

💡 Contrasting example / warning: Unlike SharePoint records, custom content isn't tied to products, categories, or business units the way standard Knowledge Management articles are — only user groups. Teams that assume full parity with the Knowledge module get surprised when a report or filter they relied on elsewhere simply doesn't apply to custom content types.

🎯 Use this when: no existing system holds the data you need, or the data needs to be created and updated by the agents themselves — event logs, case annotations, proprietary taxonomies.

5. External Application Connectors — Slack, Jira, Confluence, Gmail, MCP & More

Kid analogy: this is like a kid having a whole set of walkie-talkies, one tuned to each friend's house, and only being allowed to say the specific pre-approved phrases on each channel — "ask if they're home," but not "let yourself in." Each external application connector is a pre-built bridge to a named third-party system, and the functions you're allowed to call through it are chosen deliberately, not wide open. 📻

Oracle currently lists a broad supported set, including Box, Confluence and Jira (via Atlassian ROVO), Dropbox, Gmail, Google Drive, Microsoft OneDrive and Outlook, Slack, plus MCP-native connectors (Box MCP, Dropbox MCP, Firecrawl MCP, Slack MCP) and search/data connectors like Brave, Exa, Firecrawl, Tavily, and Vertex AI. That MCP presence is notable — it means AI Agent Studio isn't just building Oracle-proprietary bridges, it's also treating the Model Context Protocol as a first-class connector category, letting an enterprise plug in any compliant MCP server rather than waiting for Oracle to hand-build every integration.

Implementation steps (External Application Connector, general pattern):

1. Go to Connectors > Add Connector, search the target app (e.g., "Jira"), and click the Learn More icon to review scopes before adding it.
2. Click + to add it, name it, set Family/Product, and enter the app-specific Configuration details (typically an OAuth app registration or API key from that vendor).
3. Click Create — the connector now appears under Configured connectors.
4. Build a Tool of Tool Type "Connector," attach this connector, and — critically — hand-pick which Connector functions to expose (e.g., "search issues" but not "delete issue").
5. Use the function's play/test icon to validate before assigning it to a live agent.
6. Attach the tool either to an AI agent (broad access, guarded by prompt instructions) or directly to an AI workflow step (narrow, parameter-locked access).

💡 Contrasting example / warning: Oracle's own reference material is explicit that beyond the client connectors and a handful of confirmed integrations, exact function-level capability per connector should be verified against your licensed environment rather than assumed from a marketing list — the supported-connector catalog moves release to release, so a function your architecture diagram assumes exists in 26B may not ship until 26C, or may require an additional duty role.

🎯 Use this when: the agent needs to act inside an existing SaaS tool your teams already live in — filing a Jira ticket, searching Confluence, sending a Gmail follow-up — instead of duplicating that system's data into Fusion.

6. Client Connectors — Putting the Agent Inside Teams and Slack

Kid analogy: every connector so far is the agent going out to fetch something. A Client Connector flips it — it's like inviting the librarian to sit at your kitchen table instead of you walking to the library. The agent shows up inside the chat app your employees already have open all day, rather than requiring them to log into Fusion separately. 🪑

Each client connector instance is scoped to one external application instance — its own app identity, workspace/tenant identity, and credential lifecycle — so a company can run "Slack – HR Workspace" and "Slack – Finance Workspace" as two entirely separate, independently permissioned instances rather than one giant shared bot.

Implementation steps (Microsoft Teams Client Connector):

1. In Azure, create an Azure Bot resource (single-tenant), note the App ID and Tenant ID, and set the Messaging Endpoint to your Fusion pod's orchestrator URL.
2. Generate a client secret for the bot and record it.
3. Grant Microsoft Graph User.ReadBasic.All under both Application and Delegate permissions, then grant admin consent for each.
4. Enable the Microsoft Teams channel on the bot resource.
5. In AI Agent Studio, add a "Microsoft Teams (Client)" connector, entering the Bot/App ID, Tenant, and Secret, plus manifest details (short name, full name, schema version) and Valid Domains — including token.botframework.com with your pod's fully qualified name.
6. Download the generated manifest.json and icon files, zip them together, and upload the zip in the Teams Admin Center under Manage Apps.
7. Publish the app and add it to an Org Wide Policy so employees can install it.

Implementation steps (Slack Client Connector):

1. In AI Agent Studio, add a "Slack (Client)" connector with a name, manifest schema version, and app display name.
2. Download the generated manifest.json.
3. At api.slack.com/apps, create a new app "from a manifest," paste in that JSON, and append your workspace_id and app_id query parameters to both the event-subscriptions and interactivity request URLs.
4. Install the app to your workspace; record the App ID, Client ID, Client Secret, Signing Secret, and Bot User OAuth Token.
5. Verify the Event Subscriptions Request URL is confirmed (retry if it isn't).
6. Back in AI Agent Studio, open the connector, set "Configure Bot Credentials" to True, and paste in all the Slack-side values collected above.
7. In Slack, have users Add the app so they can start chatting with the published agent directly.

💡 Contrasting example / warning: Unlike the content connectors in Sections 2–4, client connectors don't sync any content at all — they carry live conversation, not documents. Teams that assign the wrong AI agents to a Slack client connector without reviewing that agent's existing tool access end up exposing far more capability inside chat than they intended, because access wasn't re-scoped for the new, lower-friction surface.

🎯 Use this when: adoption is the bottleneck, not capability — employees already live in Slack or Teams and a separate Fusion login is friction you don't need.

7. Enterprise Rollout at Scale: Governance, Ownership, Metrics

Treating connector rollout as "just another integration" instead of a governed program is where most Fortune 500-scale efforts stall after the pilot.

A workable enterprise pattern looks like this:

1. Ownership split. One named owner per connector (not per team) — typically whoever holds both a security duty role and the relevant Knowledge Authoring role, mirroring Oracle's own dual-role case study.
2. Naming and code conventions. Standardize connector codes and Article ID Prefixes before anyone clicks Create — these values get baked into Data Security Policies and are painful to rename later.
3. A connector request template. Require a one-page justification per connector: which data source, which user groups can see it, what functions (for external app connectors) are actually needed versus available.
4. Scheduled-job monitoring as a first-class metric. Track sync job success/failure counts for every SharePoint and Web Crawler connector the same way you'd track a batch ETL job — a silently failing sync is functionally the same as an agent hallucinating from stale data.
5. Least-function exposure by default. For external app and MCP connectors, start every new tool with the minimum function set, and require a documented reason to add write/delete-capable functions.
6. Centralized client-connector inventory. Because each Slack/Teams client connector instance is its own credentialed app, maintain a single register of every workspace-level instance so a departing admin doesn't leave an orphaned bot with live credentials.

Partner-level programs are already forming around exactly this operating model — ABC Corp's "Agent Powered Performance" engine was announced explicitly to help "streamline adoption and measure value" across Fusion-powered agent workflows at scale, which is a signal that outcome tracking, not just technical connectivity, is what separates a pilot from a program.

8. Common Mistakes (and Why Teams Keep Making Them)

• Assuming the sync job ran just because the connector was created. The SharePoint and Web Crawler connectors don't pull content on creation — you must separately schedule the Content Intelligence Connector Job. Teams demo a connector the same day, see no content, and wrongly conclude the connector is broken.
• Ignoring file-size and extension limits until production. The 100 MB attachment cap and the allow-listed extensions list are easy to miss in a small test folder and painful to discover mid-rollout when a legal or engineering SharePoint site is full of large or unusual file types.
• Treating custom content sources like standard Knowledge articles. Custom content types don't support products, categories, or business units — only user groups — so any workflow built assuming that parity breaks quietly.
• Exposing every function on an external app connector "just in case." Broad function exposure feels efficient early on but turns into an unreviewable permission surface once dozens of agents share the same tool — the fix is scoping functions per tool from day one, not retrofitting later.
• Skipping the Entra/Slack app-side setup and blaming Fusion. Both the Teams and Slack client connectors require real work in Microsoft Entra or api.slack.com (bot registration, permissions, manifest upload) before Fusion's half of the connection can succeed — a failure here often gets misdiagnosed as an Oracle-side bug.
• No inventory of who owns which connector. When rollout scales past a handful of connectors, undocumented ownership means credential rotations, deprecated SharePoint sites, or expired Slack tokens go unnoticed until an agent starts failing silently in production.

❓ FAQ

Do I need Oracle Database 26ai to use connectors?

Yes — Oracle's implementation guide notes connectors only work if Oracle Database 26ai is provisioned on your Fusion Cloud Application POD; if agents fail to return connector content after full setup, that's the first infrastructure item to check with an SR.

What's the difference between a connector and a tool?

A connector is the credentialed link to an external system; a tool wraps a connector (or connector functions) into something you assign to an agent or workflow. You can create multiple tools from a single connector to expose different functions to different agents.

Can an agent write back to a custom content source, or only read it?

Both. Custom content sources start empty and are designed for agents to create, update, retrieve, or delete entries programmatically — unlike SharePoint or Web Crawler connectors, which are read-oriented and populated by a scheduled sync job.

Does AI Agent Studio support MCP (Model Context Protocol) connectors?

Yes — Oracle's supported connector list includes MCP-native options such as Box MCP, Dropbox MCP, Firecrawl MCP, and Slack MCP, alongside its own proprietary integrations, letting agents reach any compliant MCP server.

Is putting an agent in Slack or Teams the same as giving it a connector to Slack/Teams data?

No. A client connector (Slack/Teams) is the surface where users talk to the agent — it carries live conversation, not synced content. If you also want the agent to search Slack message history, that's the separate Slack content/API connector with its own scoped functions.

🔗 References & Further Reading

• Oracle Docs — How Do I Use Connectors in AI Agent Studio?
• Oracle Docs — How Do I Use AI Agent Studio? (Connector Tool)
• Oracle Readiness — AI Agent Studio, 25C What's New
• Oracle Newsroom — AI Agent Studio Expansion with Agentic Applications Builder
• Oracle Newsroom — AI-Native Builder Experience for Agentic Applications

Oracle, Oracle Fusion Cloud Applications, AI Agent Studio, SharePoint, Microsoft Teams, and Slack are trademarks of their respective owners. This post synthesizes and explains publicly available product documentation and news coverage in original wording; it does not reproduce source text verbatim, and it is not official Oracle, Microsoft, or Slack documentation. Always verify current behavior, licensing, and role requirements against your own Oracle environment.

📝 Summary

• A connector is the governed link between an AI agent and an outside system — separate from the "tool" that exposes it and the "agent" that uses it.
• The SharePoint Connector syncs files via OAuth 2.0 and a scheduled job, respecting attachment size and extension limits.
• The Web Crawler Connector ingests websites within a configured depth and scope, honoring robots.txt and rate limits.
• The Custom Content Source Connector is the only type built for live, agent-writable, schema-defined data.
• External application connectors (Slack, Jira, Confluence, Gmail, MCP servers, and more) should expose the minimum function set needed per tool.
• Client connectors (Slack, Teams) bring the agent into chat but carry conversation, not synced content — they require real setup in Entra or Slack's own app console.
• Enterprise-scale rollout needs named ownership, sync-job monitoring, and least-function defaults, not just technical connectivity.
• Most production failures trace back to unscheduled sync jobs, over-broad function exposure, or undocumented connector ownership — not the connector technology itself.