Skip Navigation
Oracle Inlay Updates
Answer ID 10621   |   Last Review Date 12/22/2021


Inlay Updates


To help prepare for a successful incorporation of Inlay releases, we provide a view of what is included in the latest release as well as recent releases. 

The Oracle Inlay Toolkit (OIT) and resulting Inlays are a single-version service that is periodically updated every 2-4 weeks. Effort is put forth to be backward compatible but there are times when changes do need to be made. When this happens, the corresponding code, attribute or string is deprecated and eventually removed - typically 2 or 3 releases later.

Additional documentation can be found by accessing the Inlay Registry page at: Oracle OIT Registry.

Please see below for the current release notes as well as information about past releases:

Latest Release

Altering Inlay Width and Height

Inlay width and height can be altered by passing new data-oit-theme-vars parameters within the loader script. By passing inlayWidth and/or inlayHeight values, the inlay size will be adjusted accordingly. If specified dimensions are larger than the screen width or height, respectively, the inlay will only stretch as far as the screen edge. Note that inlayHeight only applies to the chat-embedded inlay. Only the chat-embedded inlay's transcript screen has a fixed height and is thus customizable. The default value for this screen is 475px.

B2B Service Custom Fields

Custom fields are allowed to be passed "behind the scenes" when using B2B Service combined with Mercury. All custom fields are passed within the attribute launch-form-fields as name value pairs. Custom fields are annotated by a leading "c$". Below is an example of a launch form field collecting a subject and an email as well as passing custom fields to the host application.

launch-form-fields= ["SUBJECT", "EMAIL*",
{"name": "c$age", "value": "28", "hidden": "true"},
{"name": "c$favoriteIceCream", "value": "chocolate", "hidden": "true"},
{"name": "c$SVCMCA_APPLICATION_CLASSIFICATION", "value": "ADVANCED_CUSTOMER_CARE", "hidden": "true"}]]

Initial Agent Greeting Message Mode

A new attribute, agent-greeting-mode, has been added to inform the chat-embedded inlay whether to display the initial chat greeting message. This feature is particularly useful when using a digital assistant that provides it’s own greeting to the end user. The default is ENABLED.



Click the plus sign next to the appropriate heading below to expand that section for viewing.

 Build #

In the August release of Inlays, administrators are now able to determine what happens to a matched pattern if Off The Record is enabled. With the attribute off-the-record-action, administrators can determine what action to take with the matched item. The possible values for this attribute are:

  • OTR_ONLY (default) - send the message as-is
  • OTR_WITH_FULL_MASK - fully replace the matched pattern with asterisks before sending
  • OTR_WITH_PARTIAL_MASK - partially replace the matched pattern with asterisks showing only the last 4 characters


 Build #

The inlay can check for office hours before allowing a user to attempt a chat session. Setting the attribute, office-hours-check, to ENABLED will result in performing a one-time poll to check for office hours and holiday compliance.

The agentGreeting string is used to override the default agent greeting. Include the parameter, {AGENT_NAME}, in the string to dynamically include the current agent's name.


 Build #

In the May release, much was added to the product for B2B Service as Inlays are a shared service. The only changes for B2C Service were due to addressing defects. No new features were introduced.


 Build #

Avatars are available for all participants of a chat session - agents, digital assistants, and end users. The avatars can either be defined as the user's initials or by an image defined by a fully qualified URL. The attribute avatars support a list of objects with properties - enabled, style, type, url - they are defined as follows:

  • enabled (boolean) - controls the visibility of the avatar
  • type (string) - supported types are "AGENT", "BOT", or "USER"
  • style (string) - supported styles are "IMAGE" or "INITIALS"
  • url (string) - required when specifying an image, a fully qualified public url

Administrators can define what types of files the end user can upload. The attribute file-upload-valid-types is a string of allowed MIME types (e.g., image/png, image/*) or file extensions (e.g. .png) that can be uploaded. If not specified, any file can be uploaded. The attribute default is ".bmp, .doc, .docx, .gif, .jpeg, .jpg, .pdf, .png, .xls, .xlsx".


 Build #

The February 2021 release of Inlays, allows for the Page Peek feature to work with inlays. Additionally, with the proper configuration of the chat agent workspace, files can be uploaded from an agent into the chat transcript to be downloaded on to the end user’s machine. All shared files are automatically added to the incident at the conclusion of the chat session.


 Prior Builds

In this release, inlays were integrated with co-browse to bring a seamless interaction for co-browsing between chat agents and end users. Adding “cobrowse-enabled=true” in the configuration of the Chat Embedded Inlay along with configuring the Agent Browser User Interface (BUI) workspace, the chat agent can now send an invitation to participate in a co-browsing session. This feature does require that the co-browse scripts be added to the host page. 

This release has additional updates to the launch-form-fields. Administrators are now able to set default value and visibility for fields within the launch form. This capability will allow administrators to pre-populate fields such as first and last name as well as email. Also, they will be able to set and hide that field from the launch form and still be able to send that data to the chat server. Below is an example of pre-populating the launch form within customer portal.


<rn:condition logged_in="true">
                    launch-form-fields='[{"name": "FIRST_NAME","value": "<?= get_instance()->session->getProfileData('firstName'); ?>"}, {"name": "LAST_NAME","value": "<?= get_instance()->session->getProfileData('lastName'); ?>"}, {"name": "EMAIL","value": "<?= get_instance()->session->getProfileData('email'); ?>"}]'></inlay-oracle-chat-embedded>  

                    launch-form-fields='[{"name": "FIRST_NAME"}, {"name": "LAST_NAME"}, {"name": "EMAIL"}]'></inlay-oracle-chat-embedded>  


Products and/or categories are now available on the launch form by adding them to the launch-form-fields attribute. The array values are PRODUCT and CATEGORY. These selectors can be pre-populated by specifying a product or category id in within the inlay attributes. An optional asterisk (*) indicates that the field is required.

The Embedded Chat Inlay now supports Oracle Digital Assistant (ODA). If a chat server is configured to have an ODA as a chat agent, then interactions with that chatbot are supported in the inlay. These interactions can include images, horizontal and vertical cards, and attachments. For more information about ODA, see Build Digital Assistants for Your Enterprise Applications.

Included in this release is the ability to specify a queue id for polling purposes. Prior to this release only the default queue was being polled. In addition to polling a specific queue, a new attribute specifying the maximum queue size was added to limit the total number of end users waiting in queue.

A new theme variable was introduced, fontSize. This variable allows administrators to specify the font size for inlays on a page.

Also added in this release is the ability for the auto off-the-record feature to recognize Social Security Numbers. When identified, those messages from the end user are sent to the chat server as off-the-record to prevent any personal identifiable data to be stored within the chat transcript.

The Chat Embedded inlay is now able to display chat custom fields on the launch form page by adding them to the launch-form-fields attribute. This attribute is an array of fields that the end user can fill in before starting a chat session. This capability supports all custom field types, allows for required or optional selection, and along with the standard fields, can be placed in any order on the form. The field is referenced by using a "c$" as a preface to the custom field's database column name. For example, if the column name was "age", then the array of fields would include "c$age". Supported in "osvc 20A+" only.

Also included in this release is the capability to support the Sneak Preview feature in chat. When the Oracle B2C Service configuration setting SNEAK_PREVIEW_ENABLED is set to true, the inlay will periodically send a snapshot of the message box to the chat agent. Supported in "osvc 20A+" only.

Introduced a brand-new inlay, Top Answers. This knowledge inlay can be deployed onto any web page and will display up to ten answers. Initial answers displayed may match host page metadata or specific search terms and offers the capability to search the knowledge base. This inlay only supports Knowledge Foundation implementations.  The ability to delay loading and poll for available chat agent sessions has been added to the Embedded Chat Inlay. The delay-seconds attribute will pause the inlay before performing any action, such as polling or appearing on the page. Using attributes polling-enabled and polling-threshold will cause the inlay to poll the chat server for the minimum number of available agent sessions identified by the threshold. Polling will begin after an optional delay specified by delay-seconds. Note that polling is only supported when the inlay is initially hidden with inlay-hidden.

Added the ability to customize the brand color as well as the font family for any inlays on a page. This is accomplished by manipulating the data-oit-theme-vars attribute within the OIT Loader Script. The brandColor can be altered by providing a six-digit hex color value (e.g. #cccccc) and the fontFamily can be specified as a comma-separated font stack (e.g. Courier, monospace). Here is an example below:

  "loader": {
    "common": {
      "attributes": {
        "data-oit-theme-vars": {
          "brandColor": "#666666",
          “fontFamily”: “Courier New”

This variable should be defined as a normal JSON object within the OIT configuration file.

Introduced in this release is the ability to have an off the record patterns attribute. Setting this attribute – currently there is only one value, CREDIT_CARD – will cause any message typed by the end user whose contents match a credit card pattern to be sent off the record. This is particularly useful for when end users send sensitive information in a chat that organizations do not want recorded in the official database transcripts.

Also added in this release is the ability to view all languages of all strings for each inlay. By accessing the inlay in the registry page and viewing the strings tab, administrators can change the language and view all strings for that inlay in that language.

This release introduces the launch-form-fields attribute which allows administrators to easily configure the fields on the launch form page. This configuration sets the visibility, order and requirement for each field. An example of this is as follows:


Which will show subject, first name and email on the launch form page in that order and make the first name and email as required fields. Note that removing last name from the list hides that field.

With the introduction of this all-encompassing attribute, there are 8 launch form attributes that are deprecated and will be removed. This capability will pave the way for future growth on the launch form page.

Another launch form feature was added in this release – the ability to define header and footer text. These custom messages support plain text as well as links in a markdown format (e.g. [label](url)). Below is a simple example of a privacy policy that can be placed in the footer of the launch form page:

Click to view our [Privacy Policy] (

To utilize this functionality, administrators would override the launchFormHeaderText or launchFormFooterText strings.

A postChatClosingMessage string was introduced to allow administrators to customize the closing message to the end user when a chat was terminated. This message can be used to thank the user for chatting today as well as directing them to a defined URL for filling out a post chat survey. Much like the launchFormHeaderText and launchFormFooter, this attribute also supports links in a markdown format. The introduction of this string creates a deprecation and eventual removal of previous post chat attributes and strings. See the release notes for more details.

Lastly a new attribute, chat-bubble-name-enabled, was added which when false, hides the agent name from agent chat bubble.

All end user names are removed from the chat bubbles within the printed transcript.

New languages were added to inlays. When inlays are loaded on a page the lang tag in the html entity is evaluated in order to load the proper strings. 

The embedded-chat inlay gained a new attribute, inlay-mode, which allows the administrator to change the default location of the minimized inlay. Possible values for this attribute are BOTTOM_RIGHT (default) and BOTTOM_LEFT.

Attribute post-chat-transcript-enabled was added to control if the end user is to receive a system message about sending the transcript to the printer.

Support for right-to-left language support was added. If the page that is being loaded has the dir=”rtl” in the html entity, then that information will be passed into all inlays on that page to display the contents right to left.

Strings attribute was added to the configuration file to allow customization of all inlay strings.

Product, category and queue id attributes were added to allow internal passing of fields from the inlay to the chat server.

Changed the theme attribute to allow a simple string such as “Dijon” as opposed to a URL pointing to the theme file.

Added the OIT Registry for online information and documentation.

Added channelContentServer setting for scalability purposes. This allows for better security and faster load times due to automatic caching techniques.

Notify Me
The page will refresh upon submission. Any pending input will be lost.