Achieving Digital Transformation with Oracle's Siebel CRM

Siebel CRM 19.3 Update

John Bedford
Director, Product Strategy

Details of the latest Siebel CRM Update release under the Continuous Delivery Model, the Siebel CRM 19.3 Update. This Update was GA on 21st March, 2019.

The features included in this release is as follows:

Workspaces - Enable Seed Data Modification in the Runtime Repository (RR)

The ability to enable List of Values (LOVs) and Workspace-enabled seed data in general to be modified in the Runtime Repository environment.

The Migration utility is also enhanced to support conflict detection/resolution between updates in Source and Target environments based on a system preference that identifies Source v/s Target resolution priority.

Workspace Inspect for REST and SOAP requests

Updated Workspaces infrastructure to allow for REST and SOAP invocations by using metadata defined under Workspace integration and developer branches. Workspace branch versioning is available without the need for explicit invalidation of session stores in the Application Interface.

Online Help Update

Search capability has been added to the end user online help. Content related to new 2018 product features has also been added. The online help is available in all supported languages.

For more information on Siebel CRM Updates, please refer to the Siebel CRM Updates portal.

Join the discussion

Comments ( 2 )
  • Ronny Schoonenberg Tuesday, March 26, 2019

    Good to know! Enable LOV modification is perfect. Depreciation of the Design Repository Data Service is not.

  • John Wednesday, March 27, 2019
    Hi Ronny,

    Design Repository Data Service is a service used to migrate a “Design Repository” to another “Design Repository”. We reviewed this process with some of our customers, in all cases the necessity to move changes between Workspaces in such environments is against the best practices of Workspaces. It would require constant full migration across environments, rather than an incremental migration approach. So to avoid developers falling down this wrong path we decided to deprecate the feature.

    A classic example is to imagine having one Dev environment for large project work and another Dev environment for Production hot fixes. It might be the case that configuration needs to migrate from one Dev environment to the other.

    But the correct approach for development and migration is to use Integration Branches for each release and migrate to QA for testing as many times as necessary.

    You only deliver it to MAIN just before running Incremental Migration from MAIN to Prod. In the meantime, for the above example, you could always create a Dev branch against MAIN for emergency hotfixes and you can use Incremental Migration for Production at all times.

    Hopefully this helps to answer your concern, again it all comes down to the correct and appropriate use of Workspaces and Migration.

    HTH, John
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha