Smart Reference ID Normalization- Data Conversion Best Practices

Customer-specific data is not only essential to a Workday deployment, but a foundational component for all Workday functionality. Without an accurate and reliable data conversion, projects will face significant challenges. In previous blog posts, I have explained the importance of using smart reference IDs in Workday data conversions and the process to create and maintain smart reference IDs. Building upon these topics, normalization seeks to reduce project rework and risk by applying the smart ID usage to the multiple tenant builds typical of a Workday implementation.

Project Rework and Risk

As explained, Workday will auto-assign reference IDs when they are not explicitly provided in the data conversion workbook from which the data is loaded.  These reference IDs are commonly used in business processes, security, eligibility rules, calculated fields, and integrations by defining object relationships to their specific values. Unfortunately, when the reference IDs are auto-assigned, the specific values will change in each subsequent tenant build.  Object relationships that were tested and functioning properly in previous tenants are no longer reliable, requiring update and regression testing to ensure the system functionality is unchanged.  Given a customer can expect to build up to four or five tenants during a typical Workday implementation[1], this adds significant re-work and project risk to all teams relying on these conversion objects.

Smart Reference ID Normalization

Smart reference ID normalization is a rule that governs the data conversion process.  It states, the same name of an object’s reference ID is used each time a tenant is built.  When a Workday object is created, a smart reference ID should also be created.   This named value is then used as the unique identifier that references the same object value from tenant to tenant.  Actively managing the same smart reference IDs for each build results in consistent values where object relationships won’t break.  Since the object relationships are the same, there is no need for re-work and significant regression testing (smoke testing still required), thereby reducing the project risk associated with reference IDs in data conversion activities.

An Integration Example

[1] Workday Tenants by Implementation Phase

Tenant Name

Tenant

Phase

Purpose

P0

Initial Prototype

Plan

Built prior to kick off with a subset of customer data.  Required to start the Architect phase.  Used by consultants during Architect phase.

P1

Configuration Prototype

Prototype & Configure

Built after the Architect phase in accordance to the design decisions.

P2

Final Configuration Prototype

Prototype & Configure

Built at the end of the prototype and configure stage.  This is tenant is used during the test phase

P3

Test Tenant

Test

Built after system testing for the purpose of parallel testing

Gold

Pre-Production Tenant

Deploy

Final configuration tenant.  This tenant is promoted to the production tenant.

The issue is highlighted when building a bi-directional candidate assessment request integration for a Workday implementation.  The provider is expecting information on the candidate along with the assessment test the candidate is required to take.  The provider must be able to match the assessment request sent from Workday (in this example a sales associate assessment) to the assessment managed within their system.  Once completed, the provider will provide confirmation of the test status.  The integration is therefore designed and configured to provide mappings of all Workday assessments to the vendor’s assessments.  Reference IDs are used since they uniquely identify the specific instances of the Assessment business object within Workday and can be mapped to unique instances in the receiving system.  If they do not match, the integration exchange will fail. 

Assessment Test Configuration

The smart reference ID set up in the functional configuration, e.g. SALESASSOC, is associated to the Sales Associate Assessment.

Normalization1.png

 

Data Exchange

When the assessment request for the sales associate candidate is sent to the provider, the applicable smart reference ID is sent in the outbound record in the appropriate field.  In this example, the record is XML and the field is partnerPositionPositionTypeCode.

Outbound XML

<AssessmentOrder>

  <partnerCode>1234567890</partnerCode>

  <partnerCompanyCode>CLIENTXYZ1</partnerCompanyCode>

  <partnerPositionPositionTypeCode>SALESASSOC</partnerPositionPositionTypeCode>

  <partnerLocationCode>134</partnerLocationCode>

  <partnerLocationDescription>US-TX-Dallas</partnerLocationDescription>

  <partnerCandidateCode>7482</partnerCandidateCode>

  <languageCode>en</languageCode>

  <orderIdentifier>AP01064854</orderIdentifier>

  <orderRequisitionId>RQ0000022</orderRequisitionId>

  <candidateFirstName>Billy</candidateFirstName>

  <candidateMiddleName>H</candidateMiddleName>

  <candidateLastName>Blaze</candidateLastName>

  <candidateEmail>BBlaze@gmail.com</candidateEmail>

  <candidateGender>M</candidateGender>

  <candidateSourceId>89223</candidateSourceId>

  <candidateSouceName>Dallas Morning News Website</candidateSouceName>

  <assessmentRequester>b.robertson@xyz.com</assessmentRequester>

  <userName>partner123-user</userName>

  <password>test-password</password>

  <handbackURL>https:atsvendor.comxyzjobsmyprofile.asp?candidateid=7482</handbackURL>

</AssessmentOrder>

 

Once completed, the provider returns the status of the assessment test to Workday using the same assessment test smart reference ID.

Inbound XML

        <wd:Assess_Candidate_Request wd_version=”v26.0″>

            <wd:Assess_Candidate_Data>

                <wd:Event_Reference>

                    <wd:ID wd_type=”WID”>70043044e89510b64ad72452a8142050</wd:ID>

                </wd:Event_Reference>

                <wd:Candidate_Assessment_Data>

                    <wd:Assessed_By_Reference>

                        <wd:ID wd_type=”Employee_ID”>710102</wd:ID>

                    </wd:Assessed_By_Reference>

                    <wd:Assessed_On_Date>2016-05-25</wd:Assessed_On_Date>

                    <wd:Assessment_Status_Reference>

                        <wd:ID wd_type=”Assessment_Status_ID”

                            >RECRUITING_ASSESSMENT_STATUS_COMPLETE</wd:ID>

                    </wd:Assessment_Status_Reference>

                    <wd:Overall_Assessment_Comment>Results received</wd:Overall_Assessment_Comment>

                    <wd:Assess_Candidate_Test_Result_Data>

                        <wd:Assessment_Test_Reference>

                            <wd:ID wd_type=”Reference_ID”>SALESASSOC</wd:ID>

                        </wd:Assessment_Test_Reference>

                        <wd:Assessment_Test_Score>90</wd:Assessment_Test_Score>

                        <wd:Assessment_Test_Status_Reference>

                            <wd:ID wd_type=”Assessment_Status_ID”

                                >RECRUITING_ASSESS_STATUS_RECOMMENDED</wd:ID>

                        </wd:Assessment_Test_Status_Reference>

                        <wd:Assessment_Test_Date>2016-05-25</wd:Assessment_Test_Date>

                        <wd:Comment>Candidate completed assessment. Results URL:

                    </wd:Assess_Candidate_Test_Result_Data>

                </wd:Candidate_Assessment_Data>

            </wd:Assess_Candidate_Data>

        </wd:Assess_Candidate_Request>

    </env:Body>

</env:Envelope>

 

Reference ID Work/Risk Matrix

The use of normalized smart reference IDs across the tenant builds creates a consistent and reliable value with low work/risk as per:

Tenant

Value

Reference ID

Work

Risk

P0

Sales Associate

SALESASSOC

Set up & test

Low

P1

Sales Associate

SALESASSOC

Smoke test

Low

P2

Sales Associate

SALESASSOC

Smoke test

Low

P3

Sales Associate

SALESASSOC

Smoke test

Low

Gold

Sales Associate

SALESASSOC

Smoke test

Low

 If the implementation tenants are built without normalized smart reference ID’s opting to use auto- assigned reference ID, the integration would break at each build and require updating the mapping to the receiving system. 

 

Reference ID Risk Matrix

Tenant

Value

Reference ID

Work

Risk

P0

Sales Associate

AssessmentTest-2542A

Set up & test

Low

P1

Sales Associate

AssessmentTest-2313A

Set up & test

Medium

P2

Sales Associate

AssessmentTest-2013A

Set up & test

High

P3

Sales Associate

AssessmentTest-2013A

Set up & test

High

Gold

Sales Associate

AssessmentTest-0013A

Set up & test

High

 

Summary

Data conversion specialists are the brick-masons of the Workday implementation.  It is their responsibility to ensure the data conversion is successful. By working with their customers, they ensure objects are created with smart reference IDs and that those IDs are used during each tenant build.  When tenants are populated with reliable and consistent data, there is little chance that object relationships that are used by all other teams will change, thereby eliminating rework and this known project risk.