Cornerstone Integration - Eating your own dog food - Part 2

As a result, I’ve been tasked with preparing and understanding the possibilities of interfaces to and from CSOD to different solutions. After the initial discussion of how and when we need to utilise different approaches, I wanted to briefly explain what the possibilities are from our own example.

First we need to understand the typical Integration project classifications. There are three types of technical integration:

• Certified – fixed scope, fixed cost, fixed level of effort, standard SOW (e.g. Single-sign on)
• Standard – Slight nuances of the certified project, no fixed costs (e.g. volume of records for data loads, SSO and with additional user provisioning)
• Custom – custom projects come with long timelines and must be scoped first, for feasibility and level of effort (e.g. custom data loads, custom backend scripts)

And they can be divided into specific project types:

Edge

• EdgePackaged (e.g. Skype for Business or HireVue integration) usually self service approach
• EdgeService (e.g. consultancy support for Reporting API or Cornerstone API)

Portal Access

• Custom Login Page (e.g. creating a custom login page for branding experience)
• Single Sign-on (e.g. using corporate credentials, launching cornerstone without re-authentication)

Data Loads/export

• Data Loads – Inbound Data Feeds, Master Data Loads, Historical Data Loads
• Data Exports – Outbound data Feeds, One-time data export, API, Data Exporter, Replicated Data-warehouse

Custom projects

• Bespoke solutions, custom data loads and feeds, custom backend scripts

Edge Transform (LMS Data Loads)

I will not explain the ownership of each project type because this might take a while, but please do get in touch with us if you would like more info regarding this.

As we are a Cornerstone OnDemand partner, and we needed to migrate existing data, we decided on a Standard type project and technical methodology that will utilise Data Loads. Differences between methodologies and types of data can easily be distinguished, as seen in the diagram below:

Each of the methodologies responds to one of the modules you are currently implementing:

NB – in diagram above - “Project duration” Some classification is probably needed for Boomi and GTS. A Boomi-certified integration consultant is basically a person who has passed a special type of CSOD certification program that will allow them to validate and transform any of the client data with an Integration consultant. GTS is a team in Cornerstone that will load your data with the help of a partner implementation consultant.

One of the rollout issues we faced was how to migrate the data, and for our implementation we used a 'Glass is Empty' approach. This can be best explained as an illustration:

In the future, we expect to use Cornerstone API and Reporting API to accommodate our requirements to interface with existing systems. This will be part of one of the following blogposts in this series.

Finally, I would like you to be able to get a feel of the Reporting overview strategies and how to approach to them. Please note that this is just for information purposes and based on some previous experiences.

NB – diag. above:

• Repository column 1/3/4 – Transactional database
• Pros column 3 – Outbound Data Feeds query the transactional database
• Cons column 1 – No automatic scheduling / delivery
• Column 3 – any additional change requires...
• Column 4 – Clients needs to have...

Part 1 is available here.