---
title: "Oracle Fusion Cloud Sales Integration"
description: "Connect AI agents to Oracle Fusion Cloud CX Sales, the CRM inside Oracle Fusion Cloud Customer Experience. Agents create and update accounts, contacts, leads, and opportunities, and log the activities against each."
url: https://flowrunner.ai/integrations/oracle-fusion-cloud-sales
date_modified: 2026-08-11T09:36:14-07:00
---

# Oracle Fusion Cloud Sales

[CRM](https://flowrunner.ai/integrations/category/crm-sales)

Connect AI agents to Oracle Fusion Cloud CX Sales, the CRM inside Oracle Fusion Cloud Customer Experience. Agents create and update accounts, contacts, leads, and opportunities, and log the activities against each.

25 actions · Basic auth · available

[Oracle Fusion Cloud Sales website](https://www.oracle.com/) · [Platform Documentation](https://docs.oracle.com/en/cloud/saas/sales/) · Capability data verified 2026-08-11

1.  A qualified lead arrives from a marketing platform, a spreadsheet, or an upstream flow
2.  Create Lead writes the record into the tenant's own Fusion pod with Oracle attribute names
3.  List Leads with a \`q\` expression of \`LeadNumber=...\` resolves the numeric \`LeadId\` the conversion requires
4.  List Opportunities and List Accounts confirm no opportunity already exists for this buying centre
5.  The resolved \`LeadId\` is checked to match exactly one lead, not zero and not several
6.  The territory owner receives the lead, the resolved identifier, and any opportunity it would duplicate
7.  A person authorises Convert Lead to Opportunity, which Fusion offers no way to reverse

## What This Integration Enables

Oracle Fusion Cloud Sales is the CRM that lives inside a broader Fusion Cloud Customer Experience deployment, and the important thing about integrating with it is that it is single tenant. There is no shared api.oracle.com to point at. Every call goes to the customer's own pod, for example `https://your-pod.fa.us2.oraclecloud.com`, under `/crmRestApi/resources/11.13.18.05`, authenticating as a Fusion application user over HTTP Basic. That has a consequence worth stating plainly rather than treating as configuration trivia: the agent inherits the tenant's security model instead of sitting outside it. Oracle enforces object and field level security per user, so what this integration can read and write is whatever the connection's Fusion user has been granted, decided by the customer's own security administrator in the system where that decision belongs. The same applies to the custom fields a tenant has configured. This is what an [Orchestration as a Service](https://flowrunner.ai/concepts/orchestration-as-a-service) layer should look like against an enterprise system of record: the agent works inside the governance that already exists rather than negotiating a way around it.

The surface covers the core sales objects with full lifecycle support, accounts, contacts, leads, opportunities, and activities, plus the one operation that is not simple CRUD. Convert Lead to Opportunity calls Fusion's own `convertLeadToOpty` custom action against a numeric `LeadId`, with any additional action parameters merged into the request body. Reads are where Fusion is genuinely powerful and worth using properly. List actions accept a raw Fusion `q` expression, so `OptyNumber=12345` or `OrganizationName LIKE '%Acme%'` filters at the server, multiple conditions join with `;` for logical AND, and the convenience name filters use a contains match combined with your own `q` using AND. `fields` limits the returned attributes to keep payloads sensible and `expand` inlines child collections such as `Address`, `ContactPoint`, `OpportunityContact`, `Revenue`, and `ActivityContact` on a Get. Collections come back in Oracle's native envelope with `items`, `count`, `hasMore`, `limit`, `offset`, `totalResults`, and `links`, defaulting to 25 records per page. Identifiers are not uniform and this is where flows most often go wrong: accounts and contacts are addressed by `PartyNumber`, opportunities by `OptyNumber`, activities by `ActivityNumber`, and leads by the numeric `LeadId` rather than the public `LeadNumber`, which has to be resolved with a List Leads call first. Create and Update take an object of Fusion attribute names, so field names must match Oracle's exactly. Deletes on accounts, contacts, opportunities, and activities are permanent with no undo. This connector ships no triggers and registers no webhook subscription, so change detection is a scheduled List call with a `q` filter on a modification attribute, and a flow that expects Fusion to notify FlowRunner when a deal moves will wait indefinitely.

### Without FlowRunner

**Leads arrive outside the system of record**: Marketing holds a list, sales holds a pipeline, and reconciling them is a quarterly project

**Identifiers get guessed**: An integration writes against a number that looks like a lead id and turns out to be the public lead number

**Conversion is a manual queue**: Qualified leads wait for someone to open Fusion and convert them one at a time

### With FlowRunner

**Records land in the tenant**: Accounts, contacts, leads, and opportunities are written directly into the customer's own Fusion pod

**Identifiers are resolved before use**: \`LeadNumber\` is resolved to \`LeadId\` through a \`q\` filter, and an ambiguous match stops the run

**Conversion is deliberate**: Convert Lead to Opportunity runs against a lead a person confirmed, because Fusion does not offer an undo

## Use Case Scenarios

### A campaign response that becomes a qualified lead in the system of record

Marketing responses collect in a spreadsheet or a campaign platform. The agent reads each row, calls List Accounts with a `q` expression such as `OrganizationName LIKE '%Northgate%'` to see whether the company already exists in the tenant, and where it does not, calls Create Account with Oracle attribute names taken from the tenant's own configuration rather than from a generic mapping. Create Contact adds the person against the resolved `PartyNumber`. Create Lead then writes the lead with its source, its qualification answers, and any tenant specific custom attributes the security administrator has exposed to this user. Create Activity logs the campaign touch against the account so the first sales conversation starts with the context rather than without it. Nothing is converted in this pass. Conversion is a separate, gated decision.

### Pipeline hygiene driven by server side filters rather than full extracts

On a schedule the agent calls List Opportunities with a `q` expression that names the stage and the close date window, uses `fields` to return only the attributes the report needs, and pages through the collection envelope until `hasMore` is false rather than trusting a single response. For each opportunity above a value threshold it calls Get Opportunity with `expand` set to `Revenue` and `OpportunityContact` so the revenue lines and the buying contacts arrive inline instead of as a second round of calls. List Activities filtered on the opportunity shows whether anything has actually happened against it. The result is a per territory summary in [Slack](https://flowrunner.ai/integrations/slack) naming deals with no activity in the period, and a copy in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) for the forecast call. Every action in this scenario is a read.

### A closed deal handed to finance without a retyping step

When an opportunity is marked won, the agent calls Get Opportunity by `OptyNumber` with `expand` set to `Revenue` to read the agreed lines rather than an assumed total, and Get Account by `PartyNumber` for the billing party. It then hands the structured result to [Oracle Fusion Cloud ERP](https://flowrunner.ai/integrations/oracle-fusion-cloud-erp) so the billing document is raised from the same numbers the sales team agreed, and calls Create Activity against the opportunity to record that the handover happened and when. Update Opportunity writes back the reference finance returned, so someone reading the deal in six months can find the invoice without asking. The interesting part is what the agent does not do, which is decide that the revenue lines and the billing lines disagree quietly. That difference surfaces as an [automation exception](https://flowrunner.ai/concepts/automation-exceptions) rather than as a rounded number.

## Human-in-Loop Highlight

Convert Lead to Opportunity is the operation to gate, and the reason is structural rather than cautious. It calls Fusion's `convertLeadToOpty` action, which is a one way transformation: the lead becomes an opportunity, the opportunity lands in a territory, and it starts contributing to a forecast a sales vice president will read on Friday. Fusion offers no inverse action, and this connector has no Delete Lead either, so an incorrect conversion is cleaned up by a person inside Fusion, in a forecast that has already been reported on. The failure mode is not usually a bad lead, it is a bad identifier. Conversion takes the numeric `LeadId`, but every human facing artefact in the business carries the public `LeadNumber`, so the agent has to resolve one to the other with a List Leads call using a `q` expression. A `q` expression that matches nothing returns an empty collection, and a `q` expression that is slightly too loose returns several leads, and neither of those is an error. So the agent stops on the resolution step, not on the conversion. It posts to the territory owner: "38 leads passed qualification scoring this morning. 33 resolved from `LeadNumber` to exactly one `LeadId` and are ready to convert. 3 resolved to nothing, which usually means the lead was already converted or deleted in Fusion. 2 resolved to more than one lead: `LeadNumber` CN-4471 matches two records, one owned by the North territory and one by Partner Sales, and converting the wrong one puts the opportunity in the wrong forecast with no way to convert it back. Convert the 33, and tell me which record to use for the 2?" The owner answers once. Convert Lead to Opportunity then runs only against identifiers a person confirmed, and the flow records the resolved `LeadId` alongside each created opportunity so the next run can trace what it did. This is the [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) moment on an enterprise CRM where the agent is fast at resolving and a person is the only one who can say which of two plausible leads is the real one.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

## Agent Capabilities

25 actions

### Accounts

5

-   **List Accounts** Returns accounts in Oracle's collection envelope with \`items\`, \`count\`, \`hasMore\`, \`limit\`, \`offset\`, and \`totalResults\`. Accepts a raw Fusion \`q\` expression for server side filtering, which is how a flow avoids extracting a module to answer one question.
-   **Get Account** Retrieves a single account by \`PartyNumber\`, with \`expand\` available to inline child collections such as \`Address\` and \`ContactPoint\`.
-   **Create Account** Creates an account from an object of Fusion attribute names. Field names must match Oracle's exactly, including any custom attributes configured on the tenant.
-   **Update Account** Updates an account by \`PartyNumber\`. Used to keep the system of record current from a source that genuinely owns the field.
-   **Delete Account** Permanently removes an account with no undo.

### Contacts

5

-   **List Contacts** Returns contacts with \`q\` filtering, \`fields\` to limit attributes, and offset paging.
-   **Get Contact** Retrieves a single contact by \`PartyNumber\`, with \`expand\` for child collections such as \`ContactPoint\`.
-   **Create Contact** Creates a contact against a resolved account, using Fusion attribute names.
-   **Update Contact** Updates a contact by \`PartyNumber\`.
-   **Delete Contact** Permanently removes a contact with no undo.

### Leads

5

-   **List Leads** Returns leads with \`q\` filtering. This is the action that resolves a public \`LeadNumber\` to the numeric \`LeadId\` every other lead operation needs, and the one whose match count decides whether a conversion is safe to run.
-   **Get Lead** Retrieves a single lead by its numeric \`LeadId\`.
-   **Create Lead** Creates a lead from an object of Fusion attribute names, including tenant configured custom attributes the connection's user is permitted to write.
-   **Update Lead** Updates a lead by \`LeadId\`, for example to record a qualification outcome or reassign it.
-   **Convert Lead to Opportunity** Calls Fusion's \`convertLeadToOpty\` action against a numeric \`LeadId\`, with additional action parameters merged into the request body. Fusion offers no inverse, so this runs against a lead a person has confirmed.

### Opportunities

5

-   **List Opportunities** Returns opportunities with \`q\` filtering on stage, close date, or any Fusion attribute, paged through the collection envelope until \`hasMore\` is false.
-   **Get Opportunity** Retrieves a single opportunity by \`OptyNumber\`, with \`expand\` available for \`Revenue\` and \`OpportunityContact\` so the lines and contacts arrive inline.
-   **Create Opportunity** Creates an opportunity directly, for deals that do not start life as a lead.
-   **Update Opportunity** Updates an opportunity, including advancing its sales stage and revising revenue amounts as a deal progresses.
-   **Delete Opportunity** Permanently removes an opportunity with no undo.

### Activities

5

-   **List Activities** Returns activities with \`q\` filtering, used to find accounts and opportunities where nothing has actually happened in a period.
-   **Get Activity** Retrieves a single activity by \`ActivityNumber\`, with \`expand\` available for \`ActivityContact\`.
-   **Create Activity** Logs a task, call, or appointment against an account or opportunity, which is how a flow leaves an auditable record that it acted.
-   **Update Activity** Updates an activity, including completion and reassignment.
-   **Delete Activity** Permanently removes an activity with no undo.

## Frequently Asked Questions

### What can FlowRunner do with Oracle Fusion Cloud Sales?

FlowRunner agents can run List Accounts, Get Account, and Create Account in Oracle Fusion Cloud Sales, plus 22 more actions.

### Does connecting Oracle Fusion Cloud Sales to FlowRunner require OAuth?

No. Oracle Fusion Cloud Sales connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.

### Can Oracle Fusion Cloud Sales trigger a FlowRunner workflow automatically?

Oracle Fusion Cloud Sales doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

**Work at Oracle Fusion Cloud Sales?** This integration exposes Oracle Fusion Cloud Sales to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current.

---
Markdown version of https://flowrunner.ai/integrations/oracle-fusion-cloud-sales. Site index: https://flowrunner.ai/llms.txt
