Oracle Fusion Cloud Sales
CRMConnect 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.
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 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
With FlowRunner
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 naming deals with no activity in the period, and a copy in 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 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 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 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 Capabilities
25 actionsAccounts
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.
Start building with Oracle Fusion Cloud Sales
$100 in credits. No card required. Connect in minutes.