Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
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:
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.
Workday supports Integration Field Overrides to pull custom fields from their API. To configure field overrides, set up the below parameters:
To configure Field Overrides in Workday, follow these steps:
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.
For more information see Workday Custom Report If your mappings are different for updates and insert flows then use these two configurations: 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:
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.
| ||
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.
Other Greenhouse API fields (candidate, application, job, offer) can be pulled too. Here are a few examples:
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:
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:
| ||
Mapping fields for ADP WorkforceNow system trigger | Here’s sample mapping for ADP WorkforceNow:
Other values for config.event are worker.terminate or worker.update | ||
Mapping fields for Dayforce system trigger | Here’s sample mapping for Dayforce. We use this web service:
Other complex mapping examples are: Pay class: map:EmploymentStatuses.Items.0.PayClass.ShortName=customfield_00000 Region org: map:OrgUnitDetail.ShortName_where_OrgUnitDetail.OrgLevel.XRefCode_eq_Region=customfield_00000 Manager: map:EmployeeWorkAssignmentManagers.Items.0.ManagerName=customfield_00000|user_select Email: map:ElectronicAddress_where_ContactInformationType.ContactInformationTypeGroup.XRefCode_eq_ElectronicAddress=customfield_00000 I believe you have the below working already: Department: map:WorkAssignments.Items.0.Position.Department.ShortName=customfield_00000 Employee is virtual: map:WorkAssignments.Items.0.IsVirtual=customfield_00000 Job name: map:WorkAssignments.Items.0.Position.Job.ShortName=customfield_00000 Here’s an exhaustive list of supported fields which can also be found in Dayforce API docs: BadgeNumber string | ||
Mapping fields for SAP SuccessFactors system triggers | Here’s a sample mapping:
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 To validate the data returned by your OData API endpoint, use a tool like Postman to invoke the query. Here’s a sample URL:
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. Fields in others should be referenced with a prefix e.g. |
Table of Contents | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|