KeyPay will be the point of entry for resource records and will pass these to Skedulo at point of creation, all future updates should be made within KeyPay and passed to Skedulo.
There will be three key integration points:
When the employee is created as "Active" in KeyPay—which creates a new resource record in Skedulo.
When the employee is updated in KeyPay—which updates the corresponding resource record in Skedulo.
When the employee is terminated in KeyPay it will deactivate the corresponding resource in Skedulo.
The resource record ID will be used to identify the corresponding KeyPay employee record.
Table 14. Skedulo resource to KeyPay employee field mapping.
Skedulo Resource Field |
KeyPay Employee Field |
Mapping/Translations |
|---|---|---|
sked__Email__c |
emailaddress |
|
skedhealthcare__Employment_Type__c |
employmentType |
Picklist values limited to:
IF value in Skedulo is equal to null then it will be mapped through to KeyPay = Unknown. |
endDate |
Timestamped when sked__Is_Active__c is updated to FALSE. |
|
Employee ID |
externalId |
|
Region.External_ID__c |
locations |
The field external id on resource's region record. We need to populate that id to "locations" when exporting a resource to KeyPay. |
sked__Mobile_Phone__c |
mobilePhone |
|
sked__Is_Active__c |
status |
KeyPay translation: TRUE = Active. FALSE = Terminated. |
Sked_Resourcename__c |
surname |
|
Sked_Resourcename__c |
firstname |
The point of entry for Tags is within Skedulo and will pass these to Keypay as a Qualification.
There will be three key integration points:
When the tag is created in Skedulo which creates a new qualification record in KeyPay.
When the tag is updated in Skedulo which updates the corresponding qualification record in KeyPay.
When the tag is deleted in KeyPay it deletes the corresponding qualification in KeyPay.
The external ID will be used to identify the corresponding KeyPay qualification record.
Table 15. Skedulo tag to KeyPay qualification field mapping.
Skedulo Field |
KeyPay Field |
Mappings/Translations |
|---|---|---|
External_ID__c |
id |
|
Name |
name |
This is the point of entry for resource tags is within Skedulo. Skedulo will pass these to KeyPay as employee qualifications.
There will be three key integration points:
When the resource tag is created in Skedulo a new employee qualification record is created in KeyPay. If the employee or qualification does not exist in KeyPay, the record will not be created.
When the resource tag is updated in Skedulo (i.e., the tag's expiry date) it will update the corresponding employee qualification record in KeyPay.
When the resource tag is deleted in Skedulo it deletes the corresponding employee qualification record in KeyPay.
Table 16. Skedulo resource tags to KeyPay employee qualification field mappings.
Skedulo Field |
KeyPay Field |
Mappings/Translations |
|---|---|---|
sked__Expiry_Date__c |
expiryDate |
|
Name |
name |
|
sked__Tag__r.External_ID__c |
qualificationId |
Pulled from the tag related to the resource tag. |
External_ID__c *NEW* |
referenceNumber |
This is the point of entry for regions is within Skedulo. Skedulo will pass these to KeyPay as a location.
There will be two key integration points:
When the region is created in Skedulo it creates a new location record in KeyPay.
When the region is updated in Skedulo it will update the corresponding location record in KeyPay.
The external ID will be used to identify the corresponding KeyPay qualification record.
Table 17. Skedulo region to KeyPay location field mappings.
Skedulo Field |
KeyPay Field |
Mappings/Translations |
|---|---|---|
External_ID__c |
id |
|
Name |
name |
To support leave integration, Skedulo will cache "Leave Category Types" and their IDs within a Skedulo custom setting. The name of the leave category entry will also be inserted as a value into the type picklist field on the "Availability" object.
The point of entry for leave within Skedulo is an unavailability record. Skedulo will pass these to KeyPay as a "Leave Request." When a KeyPay leave request is made, Skedulo refers to the KeyPay integration custom settings field "KeyPay Leave Sync" to identify if the records are to be synchronized once created, or only on approval.
Updates to the leave records are to be performed within Skedulo. The amendments will be synced to KeyPay. Skedulo will be the "Master" of all leave requests.
Table 18. Availability/Leave integration field mappings.
Skedulo Field |
KeyPay Field |
Mappings/Translations |
|---|---|---|
sked__Status__c |
automaticallyApprove |
On create within Skedulo, if the status is equal to "Approved," pass value as true to KeyPay. |
Resource_Ext_ID__c |
employeeId |
|
sked__Start__c |
fromDate |
|
Duration__c *NEW* Create to capture Unavailability duration in hours |
hours |
|
External_ID__c *New* |
id |
|
leaveCategoryId |
Pulled through from the leave category ID. Cached in the custom setting for matching leave category type value. |
|
sked__Notes__c |
notes |
|
requireNotesForLeaveRequests |
||
sked__Finish__c |
toDate |
The point of entry for Holidays is within Skedulo and will pass these to Keypay as a Public Holiday.
There will be three key integration points:
When a holiday is created in Skedulo, it is pushed to KeyPay and created as a public holiday. If holiday records are created as "Global" in Skedulo, then Skedulo holiday region records are created for all existing region records in Skedulo.
When a holiday is updated in Skedulo, its equivalent public holiday in KeyPay is updated.
When a holiday is deleted in Skedulo, its equivalent public holiday record in KeyPay is updated.
Table 19. Skedulo holiday to KeyPay public holiday field mappings.
Skedulo Fields |
KeyPay Fields |
Description |
|---|---|---|
sked__Start_Date__c |
date |
|
Name |
description |
|
External_ID__c *NEW* |
id |
|
Region__r.External_ID__c |
locationIds |
Pass external ID value for all regions related via junction holiday region records. |
notAPublicHoliday |
||
note |
||
states |
Comments
0 comments
Article is closed for comments.