CRM module in a business suite

Oracle Fusion Sales

CRM

Every verdict, with its evidence

Core objects

In full

Opportunities, accounts, contacts and activities are four separate REST resources, each with its own base path under /crmRestApi/resources/11.13.18.05/. Contacts are people - Oracle defines a contact as "an individual who is a customer or a prospect, or a contact for an existing customer or a consumer" - and accounts are the selling organization, served by a different endpoint family with its own child collections. The Opportunity object carries `TargetPartyId`, "the unique identifier of the sales account that owns the opportunity", and `KeyContactId`, the primary contact, alongside an `OpportunityContact` child collection. The Activity object is a first-class record carrying `OpportunityId`, `AccountId`, `LeadId` and `PrimaryContactId`, so work attaches directly to the sale rather than through an intermediary.

Source: https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html, https://docs.oracle.com/en/cloud/saas/sales/faaps/api-contacts.html, https://docs.oracle.com/en/cloud/saas/sales/faaps/rest-endpoints.html, https://docs.oracle.com/en/cloud/saas/sales/faaps/op-activities-get.html

Verification: Verified

Pipeline stages

In full

An opportunity belongs to a sales method and sits at a sales stage, carrying `SalesMethodId` and `SalesStageId` on the record. Stage order is held on the stage itself: when defining a stage the administrator is told to "Enter a number for the order of this sales stage in the sales method", and each stage also carries a default win probability and a status. Administrators can edit the sales methods Oracle predefines or "create a new sales method entirely".

Source: https://docs.oracle.com/en/cloud/saas/sales/fadsi/manage-sales-methods-and-stages.html, https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html

Verification: Verified

Status

In full

The REST reference for the Opportunity resource enumerates `StatusCode`, "the code indicating the status of the opportunity", drawn from the lookup MOO_OPTY_STATUS, held on the opportunity beside but separate from `SalesStageId`. Oracle ships four statuses - Lost, No Sale, Open and Won - and each status is assigned a Status Category, which the API exposes read-only as `LookupCategory`, "the status category of the opportunity status". Whether an opportunity is still running is therefore an attribute of the record and needs no stage lookup. The separate read-only `StageStatusCd` holds only "the default status for the opportunity's sales stage", which is the value a new opportunity inherits, not the answer itself.

Source: https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html, https://docs.oracle.com/en/cloud/saas/sales/fadsi/modify-opportunity-statuses.html

Verification: Verified

Resolution

In part

The outcome is read from the same `StatusCode` attribute that says whether the opportunity is open, whose shipped values are Open, Won, Lost and No Sale, and from the status category derived from it. The API reference lists no separate won flag or outcome column. `ReasonWonLostCode` records why an opportunity was won or lost rather than whether it was, and Oracle's business logic only enables it once the opportunity is closed.

Source: https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html, https://docs.oracle.com/en/cloud/saas/sales/fadsi/modify-opportunity-statuses.html, https://docs.oracle.com/en/cloud/saas/sales/oasal/opportunity-business-logic-summary.html

Verification: Verified

Value

In full

The Opportunity object ships `Revenue`, "the estimated revenue amount from the opportunity", together with `ExpectAmount`, `UpsideAmount` and `DownsideAmount`. Oracle treats the figure as money rather than as a number: `CurrencyCode` sets the opportunity's currency from the ZCA_COMMON_CORPORATE_CURRENCY lookup, and `CrmConversionRate` is documented as the rate "used for the conversion of the revenue amount to the CRM common currency to facilitate the computation of the revenue forecast metrics".

Source: https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html

Verification: Verified

Scope of work

In full

Revenue items attach to the opportunity as a child collection, described by Oracle as "products, services, or other items a customer might be interested in purchasing", each viewable, creatable, updatable and deletable through the ChildRevenue resource. The opportunity also carries `Description`, "the description of the opportunity including the sales objective".

Source: https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html, https://docs.oracle.com/en/cloud/saas/sales/faaps/api-opportunities-revenue-items.html

Verification: Verified

Expected close date

In full

`EffectiveDate` ships on the Opportunity object and is documented as "the date when the opportunity is expected to close". It appears under the same definition in the opportunity extract data store, and Oracle's import documentation calls it the Effective Date field.

Source: https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html, https://docs.oracle.com/en/cloud/saas/sales/oadcx/OpportunityExtractPVO.html, https://docs.oracle.com/en/cloud/saas/sales/faiem/import-your-opportunity-data.html

Verification: Verified

Actual close date

In full

Oracle keeps an Actual Close Date separate from the expected close date and fills it in itself. The opportunity business logic states that on the transition "From open to closed" the application sets the actual close date to the system time stamp, and that reopening a closed opportunity sets it back to undefined. The field is Oracle's to maintain rather than the buyer's: the import documentation states that "You can only import into the Effective Date field and not in the Actual Close Date field." On a loss or no sale the expected close date is separately reset to the current date, so the two dates do not share one column.

Source: https://docs.oracle.com/en/cloud/saas/sales/oasal/opportunity-business-logic-summary.html, https://docs.oracle.com/en/cloud/saas/sales/faiem/import-your-opportunity-data.html

Verification: Verified

Opportunity owner

In full

`OwnerResourcePartyId` ships on the Opportunity object as "the unique identifier of a valid employee resource who owns and manages the opportunity", with `OwnerPartyNumber` and `PartyName1` exposing the same owner read-only. Ownership is distinct from the creation stamp and carries access rights: Oracle documents that the opportunity owner has full access to the record, including adding and removing sales team members.

Source: https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html, https://docs.oracle.com/en/cloud/saas/sales/oasal/how-sales-users-gain-access-to-opportunities.html

Verification: Verified

Linked buyer

In full

`KeyContactId` ships on the Opportunity object as "the unique identifier of the primary contact of the opportunity", with the contact's name, party number, email address and phone number exposed read-only alongside it. Further people attach through the OpportunityContact child collection, where "You can specify a contact's role, affinity, and influence level on an opportunity" and "A single contact can be marked as primary." This is separate from `TargetPartyId`, which links the sales account.

Source: https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html

Verification: Verified

Record preservation

In full

Closing an opportunity changes its status rather than removing it: Oracle's business logic describes the transitions from open to closed and back from closed to open on the same record. Closed opportunities stay reportable in Oracle's own analytics. The Sales - CRM Pipeline subject area exposes Won Revenue and Open Pipeline alongside the number of opportunities and a historical sales stage dimension, and the subject area list includes Sales - CRM Historical Pipeline and Sales - CRM Opportunity Sales Stage Snapshot for reporting on what has already happened.

Source: https://docs.oracle.com/en/cloud/saas/sales/oasal/opportunity-business-logic-summary.html, https://docs.oracle.com/en/cloud/saas/sales/facaa/create-an-opportunity-analysis.html, https://docs.oracle.com/en/cloud/saas/sales/faoec/toc.htm

Verification: Verified

Structured lost reasons

In full

`ReasonWonLostCode` ships on the Opportunity object as "the code indicating the reason for winning or losing the opportunity", with its values defined in the lookup MOO_SETID_WIN_LOSS_REASON and maintained by administrators through the Manage Standard Lookups task, so the reasons are a controlled list rather than free text. Oracle's business logic enables the field when an opportunity is closed and clears it if the opportunity is reopened, and the profile option MOO_CLOSE_WINLOSS_REQD makes it mandatory at close. As a shipped attribute of the opportunity it is available to the opportunity subject areas in Oracle's own analytics.

Source: https://docs.oracle.com/en/cloud/saas/sales/faaps/op-opportunities-get.html, https://docs.oracle.com/en/cloud/saas/sales/oasal/opportunity-business-logic-summary.html, https://docs.oracle.com/en/cloud/saas/sales/fasqa/how-can-i-make-the-opportunity-s-win-loss-reason-field-required.html

Verification: Verified

Email sync

In full

The Microsoft Exchange email integration "lets salespeople send emails from the Contacts, Accounts, Opportunities, and Leads work areas in Oracle Sales", and it "saves sent emails to the activity feed and to the Sent Items folder of the native email client". Replies come back on their own: the integration inserts a hidden keyword into the outgoing message and "displays the reply on the Sales activity feed by identifying the keyword", while Exchange also files the reply in the sender's inbox. The connection is server to server rather than a mail-client add-in, set up by registering an application in Microsoft Azure with read, write and send permissions so "the application access the mailbox". Mail can also be pushed the other way from Exchange, through the Shared with Oracle category or the add-in's Share button. Coverage is Microsoft Exchange and Microsoft 365 only.

Source: https://docs.oracle.com/en/cloud/saas/sales/faeml/exchange-email-integration-for-digital-sales.html, https://docs.oracle.com/en/cloud/saas/sales/fasms/overview-of-the-sync-between-sales-and-microsoft-365.html

Verification: Verified

Calendar sync

In full

Oracle documents that the Microsoft 365 integration "supports bidirectional sync for appointments, tasks, and contacts, as well as the automatic sync of appointments from Exchange to Sales", with appointments, tasks and contacts synced from Sales to Exchange on saved-search criteria set by the administrator or the user. The sync is on the activity object rather than on a date: the Activity resource carries `OutlookFlag`, `OutlookIdentifier`, `OutlookGlobalId` and `OutlookAutoSyncFlag`, the last of which indicates "whether an appointment was automatically generated by the synchronization process from Microsoft 365". Coverage is Microsoft only.

Source: https://docs.oracle.com/en/cloud/saas/sales/oasal/about-integrating-the-outlook-add-in-with-oracle-sales.html, https://docs.oracle.com/en/cloud/saas/sales/fasms/overview-of-the-sync-between-sales-and-microsoft-365.html, https://docs.oracle.com/en/cloud/saas/sales/faaps/op-activities-get.html

Verification: Verified

Schedulable activity types

In full

Activities are scheduled inside Oracle Sales with a start and end date and time, a due date, an owner, assignees, a priority and links to an opportunity, account, lead or contact. Every activity carries `ActivityTypeCode`, "the code indicating the type or category of the activity", drawn from the lookup ZMM_ACTIVITY_TYPE, plus a subtype. The set is not fixed: administrators "Add a new type using the Manage Activity Type and Subtype task", and Oracle's own instruction is that a new lookup type must tag the functions it applies to, APPOINTMENT:TASK:CALLREPORT, so buyer-defined types reach both appointments and tasks.

Source: https://docs.oracle.com/en/cloud/saas/sales/oasal/about-activity-type-and-subtype.html, https://docs.oracle.com/en/cloud/saas/sales/faaps/op-activities-get.html

Verification: Verified

Opportunity reporting

In full

All three are reachable from Oracle's own reporting. Forecasting is a shipped feature of the sales application rather than a separate tool, projecting opportunity revenue into forecast periods and rolling it up the sales territory hierarchy. Win rate and stage conversion are built in Oracle Transactional Business Intelligence against the shipped subject areas: Sales - CRM Pipeline supplies Won Revenue, Open Pipeline, the number of opportunities and a Historical Sales Stage dimension, and the subject area list adds Sales - CRM Opportunity Sales Stage Snapshot and Sales - CRM Historical Pipeline for stage history. The arithmetic is available in the builder, which is what makes a rate rather than a distribution possible: a column's formula can be edited "to add functions, conditional expressions, and so on", referencing other columns by folder and name, and calculated measures combine one measure with another. Neither the win rate nor the stage conversion rate was found as a prebuilt report, so both are reports the buyer assembles.

Source: https://docs.oracle.com/en/cloud/saas/sales/fasqa/how-do-i-configure-sales-forecasting-by-opportunity-revenue-rolling-up-the-territory-hierarchy-in-the-redwood-user-experience.html, https://docs.oracle.com/en/cloud/saas/sales/faoec/toc.htm, https://docs.oracle.com/en/cloud/saas/sales/facaa/create-an-opportunity-analysis.html, https://docs.oracle.com/en/cloud/saas/otbi/otbi-user/edit-formulas-or-calculated-measures.html, https://docs.oracle.com/en/cloud/saas/sales/faoec/Sales-CRM-Opportunities-and-Products-Real-Time-SA-107.html

Verification: Verified