System Trigger Mapping

Feature

Description

Mapping fields for Workday system triggers

When using Workday system trigger, users can select which fields to pull from the system when creating the Trigger issue. The format for the Workday Mapping Configuration is:

key:Worker_ID=customfield_10121
map:First_Name=customfield_10122
map:Last_Name=customfield_10123
map:Start_Date=customfield_10124

The “key” prefix identifies the ID field (Worker_ID, EmployeeID, CandidateID). This is also used to run a duplicate check and ensure that a new hire workflow is not triggered for the same employee twice. Only one key should be specified.

Apart from simple fields (string, date, number), OnRamp also supports complex fields like Single Select and User Select. Add the type after the “|” delimiter. This will create the fields in the specific type when creating the Trigger issue.

map:First_Name=customfield_10159|single_select

map:Email_Address=customfield_10158|user_select

map:Business_Site_Summary_Data/Country_Region_Reference/ID[Country_Region_ID]=customfield_10123 (specify complex mapping)

Workday supports Integration Field Overrides to pull custom fields from their API. To configure field overrides, set up the below parameters:

fo_intsys:workday_intsys_id (the Integration System ID of the integration in Workday that has the field overrides)

map:Integration_Field_Override_Data[manager_name]=customfield_10122 (retrieve calculated fields in API response, where manager_name is the name of the field. Note - only string, number or date fields are supported for field override values so any single/multi-instance fields will need to first be transformed.)

To configure Field Overrides in Workday, follow these steps:

1. Create an integration system (can be of type generic) in Workday. Capture the Integration System ID.

2. Add a field override service to this integration system. Add a field for every custom field you want to capture.

3. Make sure your Integration System User has access to those calculated fields.

Max records that can be processed in each scheduled run is 100. If you need to process more than 100, please use Workday Custom Report trigger that has a limit of 500.

Mapping fields for Workday Custom Report trigger

OnRamp supports pulling data from Workday Custom Reports that are exposed as RaaS web services. To get the custom report URL in your tenant, go to View URLs Web Service action on your report, in the JSON section, right-click JSON, then Copy URL. The URL format will be something like below:

https://wd2-impl-services1.workday.com/ccx/service/customreport2/mytenant/reportuser/reportname?format=json&Last_Updated=2023-10-01&Department=Sales

Use the above highlighted information in the trigger mapping configuration field. The reportuser and reportname combination should be provided in the “report_name” property. Filter values can also be setup as shown below.

report_name:reportuser/reportname
filter:Last_Updated={last_successful_date_time}
filter:Department=Sales
key:WorkerID=customfield_10128
map:Worker=customfield_10122
map:Title=customfield_10123
map:Cost_Center[0].Reference_ID=customfield_10010

For more information see Workday Custom Report

If your mappings are different for updates and insert flows then use these two configurations: update_for_flow and disable_updates. Set update_for_flow to the name of the flow used for inserts.

Max records that can be processed in each scheduled run is 500.

Mapping fields for BambooHR

OnRamp supports pulling standard and custom fields from BambooHR. Here’s an example mapping:

key:id=customfield_10117
map:firstName=customfield_10065
map:lastName=customfield_10066
map:employeeNumber=customfield_10079
map:hireDate=customfield_10053
map:email=customfield_10104
map:customPreferredName=customfield_10118

Any field available in BambooHR (list available here) can be used in this mapping.

Using BambooHR Other trigger allows you to pull data from other data sources in BambooHR. For example, to pull time off data use the below trigger mapping. The special “timeoff_key” is set to employee ID + start date. This is to ensure that multiple pulls of the same leave data does not create duplicate Jira issues. By default all leaves in the past and future 30 days from run date will be pulled.

key:timeoff_key=customfield_10117
map:id=customfield_10064
map:name=customfield_10065
map:employeeId=customfield_10079
map:start=customfield_10053
map:end=customfield_10054
map:type=customfield_10055
config:data_type=time_off

Mapping fields for Greenhouse system triggers

OnRamp pulls all recent applications that are in a status of Hired. It then pulls the candidates associated with those hired applicants. You can specify fields from the Candidate object to be mapped. Here is the example mapping configuration for Greenhouse.

key:id=customfield_10121
map:first_name=customfield_10122
map:last_name=customfield_10123
map:title=customfield_10133
map:company=customfield_10132
map:email_address=customfield_10085
map:phone_number=customfield_10086
map:job_name=customfield_10134 (job_name pulls the name of the job on the application with status=hired)

Other Greenhouse API fields (candidate, application, job, offer) can be pulled too. Here are a few examples:

map:addresses[0].value=customfield_10063
map:phone_numbers[0].value=customfield_10064
map:email_addresses[0].value=customfield_10065
map:applications[0].prospective_department=customfield_10066
map:applications[0].jobs[0].custom_fields.employment_type=customfield_10070
map:applications[0].jobs[0].keyed_custom_fields.job_type.value=customfield_10071
map:current_offer.starts_at=customfield_11848
map:current_offer.custom_fields.address=customfield_11845

Since OnRamp pulls only hired candidates, it expects only one application and one job tied to the hired candidate. See Greenhouse API docs for the full list of fields they return.

OnRamp by default filters all applications that are in “hired” status. But an additional filter can be configured e.g. start_at date that’s part of the offer. Here’s the line to add to filter hires that have a start date older than 7 days:

filter:starts_at=-7

Max records that can be processed in each scheduled run is 250.

Mapping fields for Personio system triggers

See this link for connecting to Personio. OnRamp supports both hires and terminations triggers from Personio. Choose the appropriate trigger when configuring your flow.

Here is the example mapping configuration for Personio.

Mapping configuration:

key:id=customfield_10121
map:first_name=customfield_10122
map:last_name=customfield_10123
map:email=customfield_10085
map:position=customfield_10134

Mapping fields for ADP WorkforceNow system trigger

Here’s sample mapping for ADP WorkforceNow:

key:workerId=customfield_10051
map:firstName=customfield_10065
map:familyName=customfield_10066
map:originalHireDate=customfield_10064
map:actualStartDate=customfield_10053
map:hireDate=customfield_10054
map:jobTitle=customfield_10055
map:positionID=customfield_10056
map:terminationDate=customfield_10057
map:terminationReason=customfield_10058
map:workerStatus=customfield_10059
map:email=customfield_10104
config:event=worker.hire

Mapping fields for Dayforce system trigger

Here’s sample mapping for ADP WorkforceNow:

key:EmployeeNumber=customfield_10051
map:FirstName=customfield_10065
map:LastName=customfield_10066
map:HireDate=customfield_10064
map:StartDate=customfield_10053
map:LoginId=customfield_10054
map:HomePhone=customfield_10055
map:OriginalHireDate=customfield_10056
map:SocialSecurityNumber=customfield_10057
map:TaxpayerId=customfield_10058
map:HomeOrganization.Department.XRefCode=customfield_10059
map:HomeOrganization.ContactEmail=customfield_10104

Here’s an exhaustive list of supported fields which can also be found in Dayforce API docs:

BadgeNumber string
BirthDate string($date-time)
BirthCountry string
BirthState string
BirthCity string
ClockSupervisor boolean
EligibleForRehire string
EmployeePin string
EntitlementOverrideDate string($date-time)
EstimatedReturnDate string($date-time)
ExportDate string($date-time)
FederatedId string
Gender string
HireDate string($date-time)
HomePhone string
IsAboriginal string
IsVisibleMinority string
EligibleForOnDemandPay boolean
EligibleForDFWalletPayCard boolean
Nationality string
NewHireApproved boolean
NewHireApprovedBy string
OriginalHireDate string($date-time)
PPACAOverrideDate string($date-time)
RegisteredDisabled string
SeniorityDate string($date-time)
SocialSecurityNumber string
SSNCountryCode string
SSNExpiryDate string($date-time)
StartDate string($date-time)
TaxExempt boolean
TaxpayerId string
TerminationDate string($date-time)
VeteranSeparationDate string($date-time)

Mapping fields for SAP SuccessFactors system triggers

Here’s a sample mapping:

key:userId=customfield_10051
map:userNav_firstName=customfield_10052
map:userNav_lastName=customfield_10053
map:userNav_email=customfield_10054
map:startDate=customfield_10056
map:positionNav_jobTitle=customfield_10057
map:departmentNav_name=customfield_10058

This maps fields like userID from the API response to a custom field. Here are sections that can be expanded: positionNav, departmentNav. Use the format <expandedSectionName>_<fieldName>=customfield e.g map:positionNav_jobTitle=customfield_10057

To validate the data returned by your OData API endpoint, use a tool like Postman to invoke the query. Here’s a sample URL:

{{successfactors url}}/odata/v2/User?$expand=userNav,positionNav,departmentNav&$select=userId,firstName,lastName,email,phone,hireDate,positionNav/jobTitle,departmentNav/name

Here are the full list of fields available: https://onwardb.atlassian.net/wiki/spaces/ONLINK/pages/94633986/SAP+SuccessFactors+to+JSM+Assets#Here%E2%80%99s-the-full-list-of-fields-available-for-mapping.

Fields in EmpJob can be referenced as-is e.g. map:startDate=customfield_10056

Fields in others should be referenced with a prefix e.g. map:departmentNav_name=customfield_10058