What data can be mapped between a policy model in Policy Automation and the Oracle Service Cloud / CX data model?
Oracle Policy Automation (18A release)
Oracle Service Cloud (RightNow CX)
Oracle Policy Automation (OPA) interviews can load and save Oracle Service Cloud data. To do this, OPA entities and attributes are mapped to corresponding Oracle Service Cloud objects and fields.
The following limitations apply to data mapping for Oracle Service Cloud objects and fields. These restrictions are all enforced by OPA at project build time:
- Interviews designed for anonymous users can only create data, not load or update data. This is because data can only be loaded for an authenticated user (Contact/Agent). For more information, see Decide who the interview is for.
- At the global level, the list of available objects is limited:
- for Contact interviews for input mapping, to objects which have a relationship to Contact. For more information, see Decide where to pre-seed interview data from: For Customer Portal users. (On output, any object can be selected regardless of having a relationship to Contact.)
- for Agent interviews, to objects which have CX workspaces where it is possible to embed the Policy Automation control. For more information, see Decide where to pre-seed interview data from: For contact center staff.
- Child entities can be mapped to Service Cloud objects that have relationships to a mapped parent object. For more information, see Bind an entity to a Service Cloud object.
- A number of Service Cloud lists are supported by OPA.
- Supported lists and menus will have value lists generated for them in Policy Modeling. When mapping OPA attributes to these list fields, they can only be mapped to OPA text attributes, and the list values are not editable by the interview designer.
- Unsupported lists and menus (including all custom menus) can still be mapped for input and output, however, value lists aren’t generated for them, so the designer has to ensure that the values submitted are valid by using their own value list or rule table to constrain the possible input values from the user, and to display items as helpful text rather than menu item IDs.
- After making changes to supported lists in Service Cloud, ensure there is visibility for the updated items for the interface used, and refresh the data model in Policy Modeling to pull in changes to the associated value lists.
- For interviews that are set up to create Service Cloud objects, all required fields must be output-mapped to OPA attributes. Fields that are required by Oracle Service Cloud are indicated in the Output Mapping view in Policy Modeling by a red asterisk.
- OPA attributes can only be mapped to compatible Service Cloud fields.
- Generally, whether an object or field can be input-mapped, output-mapped or both is determined by the Service Cloud object model. Note: For more detailed information on the Service Cloud object model, see the section Object Model Introduction (opens in new window) in the Service Cloud documentation. There are some further limitations imposed by OPA:
- Inferred entities can only be mapped for interviews that are set up to create Service Cloud objects, and none of the fields can be input-mapped.
- OPA attributes with temporal values cannot be output-mapped.
- There is no support for to-one relationships (for example, Organization of a Contact)
- While usage of Connect Web Services for SOAP is unlimited, there are practical limits which are enforced by the server. For more information, see API Limits(opens in new window).
Would you like help collecting this information?Yes, let's chat!