This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:
Date | Product | Feature | Notes |
---|---|---|---|
11 JAN 2021 | Created initial document. |
This guide outlines the information you need to know about new or improved functionality in this update.
GIVE US FEEDBACK
We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20D Revision 7 (20.4.7) in the body or title of the email.
Column Definitions:
Report = New or modified, Oracle-delivered, ready to run reports.
UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.
UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.
Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.
Ready for Use by End Users Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features. |
Customer Must Take Action before Use by End Users Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing. |
|||||
---|---|---|---|---|---|---|
Feature |
Report |
UI or |
UI or |
|
||
With this CX Commerce update, Agents can now respond to shopper issues with a goodwill credit applied to an order when a shopper has experienced difficulties. Appeasements may be required in multiple circumstances – for example, when a shopper is dissatisfied with merchandise purchased, displeased with a delay in delivery, or upon receiving damaged product.
The appeasement may be issued against the cost of the items in the order or against the cost of shipping associated with the order.
Capability highlights:
- Ability for an Agent to create and view appeasements at an order level within Agent Console.
- Issue an appeasement against a submitted or fulfilled order, including multiple appeasements for an order.
- Capture appeasement details such as type, reason, amount, or specific notes.
- Issue appeasement to the original payment method including, promotion, coupon, loyalty points, gift card, store credit, and online payments within Agent Console or to an external payment method.
- Validate appeasement data against external rules engine (via webhook) to process the appeasement refund in an external OMS.
- On submission, webhook will be triggered to pass the appeasement related data.
- Admin API returns an update on status and transactions.
- Retain shoppers following a difficult shopping experience.
- Avoid a return or cancellation on the order.
- Protect shopper interest, shopper loyalty, or brand value.
Steps to Enable
Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.
APIs available for order appeasement capability:
- Appeasements - API to be used for the POST/appeasements createAppeasement - Create an Appeasement. If an Id is provided in the payload and it exists in the system do not proceed or else create an appeasement.
- GET/appeasements listAppeasements - List Appeasements. Get appeasements by the search criteria entered. The search criteria includes appeasement properties and sub-items(appeasementRefunds, profile & order) properties like refund types, amount, first name, email, order state etc. Details are mentioned below in parameter description.
- GET/appeasements/{id} getAppeasement - Get Appeasement. Gets a detailed appeasement information based on the appeasement ID provided.
- DELETE/appeasements/{id} deleteAppeasement - Delete an incomplete appeasement. Delete an incomplete appeasement - Agent one deletes the incomplete but using admin delete endpoint we can delete any appeasement
- PUT/appeasements/{id} updateAppeasement - Updates specified appeasement.
- POST/appeasements/initiate initiateAppeasement - Initiates an Appeasement (Agent only). This endpoint is mainly to validate the order and populate the possible refundTypes.
- POST/appeasements/submit submitAppeasement - Submits an Appeasement (Agent only). Submits an existing appeasement if an Id is provided in the payload. Creates and submits a new appeasement altogether otherwise. Custom properties are supported directly at both appeasement level and each appeasementRefund level.
Appeasement Types: API to get appeasement type by ID and SCIM query.
- GET/appeasementTypes listTypes - List appeasement types based on the search criteria entered.}
- GET/appeasementTypes/{id} getType - Gets an appeasement type based on the ID provided.
- POST /appeasementTypes createType - Create appeasement type (Admin Only). Creates a new appeasement type with the provided type ID else system generated ID, by default.
- PUT /appeasementTypes/{id} updateType - Updates the specified appeasement type (Admin Only).
Reasons: API to get reasons by reason ID and SCIM Query. Reasons on Admin does not support SCIM capability.
- GET/reasons listReasons - List appeasement reasons based on the search criteria entered.
- GET/reasons/{id} getReason - Gets an appeasement reason based on the ID provided.
- POST /reasons createReason - Create Reason (Admin Only). Create the reason of given type with the given data. Valid reason types are appeasementReason, cancelReasons, priceOverrideReasons, returnReasons and returnItemDisposition. eg. /ccadmin/v1/reasons?type=returnItemDisposition
Tips And Considerations
- Out-of-the-box (OOTB) validation restricts an appeasement that is more than the order total.
- Appeasements should be settled externally for appeasements created with external refund type.
- OOTB support pertains to order type appeasements only. If merchants want non-order-based appeasements, the validations and payments should be handled externally.
- OOTB appeasements are limited to fulfilled orders and orders submitted post remorse period.
- Only Agent supervisor role can carry out appeasements.
Longtext Dynamic Property Support for Products/SKUs
This CX Commerce revision provides merchants the ability to create product and sku dynamic properties with type long text which can be used to store a large amount of plain unformatted text, such as content in CSV, JSON, or new line separated list format.
Capability highlights:
- A business user can create a long text dynamic property via Administration UI or API.
- The business user can view and update the values of these dynamic properties on the general or custom product tabs of the product/SKU editor in the catalog Administration UI.
- The new long text property will be a plain text rather than rich text editor.
Leveraging this feature enables improvements such as:
- A business user can add promotional slots to the middle of the Product Details Page with each slot containing information on position within the list of slots, how many columns it occupies, how many rows it occupies, and the content. This can be achieved by storing the configuration in a JSON and entering it into the plain text editor.
- The ability to display up to three promotional content slots on some product pages. Each promotional content can have an image, text, and a link. This can also be achieved by storing the configuration in a JSON and entering it into the plain text editor.
API details for creating a long text dynamic property:
- A dynamic property of type long text can be created for the base product type or custom product types by using POST /ccadminui/v1/productProperties.
- The productTypeId in the request payload will need to be changed to product for base product type OR to the name of the custom product type created for custom product types.
- A dynamic property of type long text can be created for the base SKU type or custom SKU types by using POST /ccadminui/v1/SKUProperties.
- The productTypeId in the request payload will need to be changed to product for base product type OR to the name of the custom product type that they have created for custom product types.
Dynamic properties of long text can be created to add promotional content and media or to apply product-specific styling to product detail pages. Merchants can now enter data used by custom presentations and widgets without being interpreted as HTML.
Steps to Enable
You don't need to do anything to enable this feature.
Tips And Considerations
- The business user can extend product and SKU attributes with dynamic property type long text by using the text area property editor in the product types area within the catalog Administration UI.
- If using the API, the longtext option is used. The new text area property will be a plain text editor rather than rich text editor.
- The business user can view and update dynamic property values on the general tab or custom product tabs of the product/SKU editor in the catalog Administration UI.
This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:
Date | Product | Feature | Notes |
---|---|---|---|
15 DEC 2020 | Created initial document. |
This guide outlines the information you need to know about new or improved functionality in this update.
GIVE US FEEDBACK
We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20D Revision 6 (20.4.6) in the body or title of the email.
Column Definitions:
Report = New or modified, Oracle-delivered, ready to run reports.
UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.
UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.
Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.
Ready for Use by End Users Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features. |
Customer Must Take Action before Use by End Users Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing. |
|||||
---|---|---|---|---|---|---|
Feature |
Report |
UI or |
UI or |
|
||
Oracle CX Commerce is excited to launch its latest innovation, our next generation Open Storefront Framework (OSF) exclusively running on Oracle Cloud Infrastructure (OCI). OSF is an evolution of our Storefront that is focused on minimizing coding required, maintaining business level control, leveraging the latest technology frameworks, and providing robust tooling for the modern developer.
Capability Highlights
- Front-end developers can deliver faster, more responsive, and richer user experiences.
- OSF is built with React so developers get to work with technology they know and love, but you also have flexibility and can develop in any front-end library of choice (e.g. React, Angular, Vue) without fear of lock-in.
- Headless without compromise – develop in your preferred front-end technology and still leverage business tooling.
- OSF leverages a fully-featured platform with drag-and-drop experience tools, context-aware preview, personalization, content, merchandising, search, catalog, inventory, A/B testing, reporting, and more.
- The UI layer provides a clean separation between the presentation layer and the state model to support local development and testing.
- Micro (not macro) updates simplify how experiences are assembled and delivered with reusable, granular components to create, swap, and go without writing code.
- Experiment in a low-risk, low-effort way. Easily insert commerce into new buying experiences, plug in new technologies, and test new sites and regions.
- Streamline collaboration by incorporating command line tools in bespoke processes.
- Monitor performance and optimization across development & release cycles.
- Accelerated development through local rendering & testing and CLI tools, providing support for customer/partner CI/CD processes.

Tools for Business and IT Working in Harmony
- Developers build storefront applications using IDE of their choice in a CLI.
- Core technologies include: node, yarn, and JavaScript.
- Test framework includes functional, quality and performance tests.
- OSF reference storefront developed with React.
- Business users employ Design Studio to create experiences with a full drag-and-drop interface.
- Layout and widget framework deliver dynamic experiences based on unique needs.
- Typical users include front-end designers, merchants, and brand owners.

OSF Reference Stores
With the Open Storefront Framework, you are getting a fresh new reference store built in React following mobile-first best practices, the core framework which includes a state management layer, and a JavaScript API which streamlines interacting with the CX Commerce REST API. This all works in conjunction with Design Studio and allows you to extend the reference application to build your own storefront or other needed touchpoint.
The reference stores significantly help to accelerate development and maintain a best practice implementation. Currently, OSF includes a starter store with common and account-based shopping flows as well as a “blank” starter store.

OSF Widgets
OSF includes a large library of React-based page components (widgets), across a wide variety of commerce functionality. With over 120 widgets available out-of-the-box, you will find a common widget for home and landing pages, such as image widgets and widgets used within the header such as the mini-cart and language selectors. For the product listing and search results pages we provide faceted navigation widgets, support for type-ahead and product listing widgets. And of course, we have all the profile, cart and order management widgets you would expect in a commerce experience.
We also provide a large selection of checkout, shipping, address entry and payment widgets.
In addition to a full set of mobile optimized widgets, we have a selection of desktop optimized widgets to optimize the interactions for these widgets when using a desktop device. Last, but not least we have a library of account-based shopping widgets for customers selling to other businesses.
Top Five Differences that Users Will Notice with OSF vs. the Classic Framework
The existing storefront framework for CX Commerce is now called Storefront Classic.
- Developers will have much more control over the behavior of the storefront application including dependencies, how modules are loaded on the storefront, and the page code/structure.
- Developers will be able to do most of their development locally as part of their own continuous integration (CI) and continuous delivery (CD) processes using the new OSF development tools including the ability to deploy and test their own sets of changes without interrupting the work of others.
- While Design Studio no longer contains “elements,” users will notice that widgets are broken into smaller components and grouped into nested “containers” which is a new feature for Design Studio.
- CSS management no longer requires the usage of LESS, nor is Bootstrap used OOTB. However, developers can make use of Bootstrap if they choose to do so and optionally make use of the CSS pre-processor of their choice.
- Storefront pages load much more quickly and are more easily crawlable without the need for a separate HTML snapshot service.
Availability and Migration Options
Newly signed CX Commerce customers are now provisioned in OCI, and they will be automatically provisioned with OSF enabled.
Starting with the initial release of OSF in mid-December, existing customers will have two main migration options available:
- Full Migration: Migrate all existing sites from Storefront Classic (our current CX Commerce framework) to Open Storefront Framework.
All existing sites will switch over at the same time to point to the new OSF application.
- Side by Side: Launch a new site on OSF that runs side by side with the other existing live sites OR migrate one or more existing sites over to OSF, leaving the rest on Classic.
Perfect for launching a new country, brand, or channel site to test out OSF.
Beginning the migration process
- First, ensure you have migrated your existing CX Commerce instance over to OCI as OSF only runs on OCI.
- Once migrated to OCI, existing customers can then decide at a future date to request to have OSF enabled on their environment. Typically, this would align with a site refresh plan or rollout of a new regional or brand site. Additionally, for now, requests to migrate to OSF will be reviewed by CX Commerce product management.
- Start to develop your OSF application in parallel to your current storefront in your dev / test environments.
- After thorough testing, switch your production site over to using OSF.
OSF will be included in publicly available product documentation and REST API doc starting with 21A in January 2021. Additional OSF enablement content, including FAQ, JS API doc, videeos, and more, will be available prior to January 2021 in the CX Commerce Cloud Customer Connect forum.
Steps to Enable
You don't need to do anything to enable this feature.
This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:
Date | Product | Feature | Notes |
---|---|---|---|
04 DEC 2020 | Created initial document. |
This guide outlines the information you need to know about new or improved functionality in this update.
GIVE US FEEDBACK
We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20D Revision 4 (20.4.4) in the body or title of the email.
Column Definitions:
Report = New or modified, Oracle-delivered, ready to run reports.
UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.
UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.
Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.
Ready for Use by End Users Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features. |
Customer Must Take Action before Use by End Users Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing. |
|||||
---|---|---|---|---|---|---|
Feature |
Report |
UI or |
UI or |
|
||
Enhanced Boost and Bury in the Dynamic Curation UI
With this CX Commerce revision, we’ve introduced an enhancement to the UI for boosting and burying products in a dynamic curation rule. As a reminder, dynamic curation allows you to influence the ordering of search results when the shopper navigates to a category (collection) or enters a search term. You can also create dynamic curation rules. Each rule has a destination (a collection or search terms), a set of criteria for ordering the search results, and an importance level for each criterion. Search uses your prioritization and blends the criteria to generate a sort order.
This new enhancement provides an easier and more efficient way to choose and sequence the products you want to boost or bury. You can view and sequence your boosted or buried products in a light table that is always visible in the rule. For example, if you have a rule that prioritizes products that are newest and most viewed, you can boost specific products to the top of the product listing, and easily sequence them for the most appealing visual experience.
Capability highlights:
- Sequence boosted or buried products using drag and drop in a light table.
- Switch to list view to edit sequence numbers
- Select multiple products at a time to boost or bury
- Visualize which products appear “above the fold”
More easily and efficiently curate product listings to align with business goals
Steps to Enable
You don't need to do anything to enable this feature.
Tips And Considerations
- Dynamic curation rules apply to search-driven collection pages, not collection pages driven from the catalog.
- You can boost up to 200 products and bury up to 200 units.
With this update, all Commerce orders are now placed in pending payment state prior to initiating payment. This ensures that orders are captured, and problems resolved, if there is an error during the payment or order submit process.
Capability highlights:
- When configured to allow partial payments, Commerce places orders in a pending payment state at the start of checkout.
- If payments fail in a way that Commerce does not receive an error, the order will remain in the pending payment state.
- Allows shopper to change or retry payment.
- Prevents further order changes or deletion by purchaser.
- Pending payment orders will be canceled after the defined time period set in the Admin (see screenshot). A record of the order will be visible in our Agent UI.
For example:
- Shopper fills cart and begins checkout process with payment using client-based/web checkout.
- Shopper enters payment information into web checkout window and submits. Payment is authorized.
- Issue arises, such as the response from the payment provider being lost or not received by the client, or browser client crashes, resulting in payment not being sent to the server.
- In this case, the order would remain in Pending Payment state and the shopper would not receive an order confirmation number or order confirm page or email.
- Shopper can see the order in Pending Payment and resubmit with payment again. The merchant can also see the order in this state and take steps to resolve.

Allows the merchant to respond when payment has been authorized on an order but not successfully submitted and provides an historical record of the transaction causing the authorization.
Steps to Enable
Existing customers need to enable this feature via the CX Commerce Administration UI setting, and order history and checkout widgets need to be updated to handle pending payment state.
Tips And Considerations
- Deploying this feature requires merchants to create a storefront experience for a shopper to resolve declined or failed orders that are in a pending payment state. This could include adding a feature to shopper accounts where a shopper can see order status, including orders in pending status, update their credit card number, and resubmit an order that has not been successfully submitted.
- For new customers, the feature is enabled by default and order history and checkout widgets must handle pending payment state. The feature can be disabled by changing the setting in the Administration UI.
This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:
Date | Product | Feature | Notes |
---|---|---|---|
20 NOV 2020 | Created initial document. |
This guide outlines the information you need to know about new or improved functionality in Oracle CX Commerce 20D Update and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.
GIVE US FEEDBACK
We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20D Update in the body or title of the email.
Column Definitions:
Features Delivered Enabled
Report = New or modified, Oracle-delivered, ready to run reports.
UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.
UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.
Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.
Ready for Use by End Users Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features. |
Action is Needed BEFORE Use by End Users Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing. |
|||||
---|---|---|---|---|---|---|
Feature |
Report |
UI or |
UI or |
|
||
Edit Catalog Directly on Storefront
With this feature, businesses requiring frequent or high-volume catalog updates can now edit catalog items and move them directly to production, bypassing the publishing process.
Capability highlights
- Ability to edit catalog items via Admin UI and CSV file import.
- Ability to edit catalog items via Bulk Import API and Admin API.
- To accommodate direct edit, a search indexing schedule is automatically created and run every 15 minutes by default.
Editing directly on the storefront cannot be used simultaneously with pricing or catalog edits that must be published. Business users should select the catalog editing model that best fits their business needs, as the feature is not intended to be turned on and off.
Business users and merchandisers can see results of the changes immediately on the storefront, providing increased productivity whether changes are nightly or throughout the day.
Steps to Enable
Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.
This feature must be turned on via API.
Integration with Subscription Management
With subscriptions becoming an increasingly popular way to buy products and services online, businesses are looking to strengthen customer relationships and evolve their strategies by taking advantage of a solution that also supports complex products and services.
With the release of the Integration with Subscription Management feature, CX Commerce customers now have access to new functionality for generating loyalty and long-term customer relationships while simplifying the commerce experience.
Key benefits:
- Self-service for managing the entire life cycle of subscription management
- Self-service capability for subscription management of complex configurable services
- Subscriptions can be created and modified seamlessly across CX Commerce, CPQ and Subscription Management applications.
- Enables subscriptions of configurable services to the shoppers.
- Capability highlights.
Integrating with Subscription Management, shoppers are now able to:
- Create subscriptions of complex configurable services with recurring prices and flexible durations as defined in the CPQ application.
- Modify configurations, change quantity, upgrade/downgrade the service as defined in the CPQ configuration.
- View all subscriptions in Commerce that are created across Commerce, CPQ and Subscription Management applications.
- Pay via credit card and invoices.
- Modify, upgrade/downgrade, suspend/resume anytime through self-service Commerce application.
- Renew subscriptions at the end of period of their original subscription date.
This integration makes it easy to set up subscription services with flexibility for the needs of your product.
For example, as a distributed remote workforce becomes the norm, video conferencing and remote working technology has become a necessity. This example scenario illustrates options that may be offered when selecting the right service for your business needs and shows the kind of complex offering that can be set up using this integration.
Video Conferencing solution for five users:
- Device: Panoramic 360° 4K output camera - $1,200 one-time charge
- Installation service - $0
- Subscription: web conferencing $50 per month/user
- Options: unlimited data recording - $5 per month/user
Users can choose any of the above options with flexibility to subscribe for 12, 24 or 60 months and ability to modify user / devices, upgrade/downgrade service options, terminate or renew the subscription at any time.
This is an API only feature with sample widget codes provided in the Integrate with Oracle Subscription Management product documentation.
Business benefits:
- Increased customer satisfaction and loyalty, resulting in long-term relationships that drive revenue growth
Steps to Enable
Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.
Tips And Considerations
Current limitations and considerations:
- This integration currently handles one-time payment and recurring charges only. Other charges, such as termination charges and the charge structure of CPQ will be handled in later phases.
- The delta price changes due to modification flows will be handled in later phases. Currently handled by terminating the subscription line and creating a new line with full price.
- Supports intangible complex service configurations with recurring prices and one-time price defined in CPQ.
- All recurring pricing must come from pricing via the CPQ configurator.
- For credit card transactions, customers using Fusion Financials should use CyberSource which is the common payment gateway shared across CX Commerce and Fusion applications. (CX Commerce supports generic payment gateway services and customers who do not use Fusion Financials can use any payment gateway that they have configured.