Introduction
TravelPerk is something that we recently introduced at Epidemic Sound, however, we ran into a bit of an issue, primarily, because TravelPerk requires the use of the TravelPerk ID of the manager value to be pushed through SCIM. My personal opinion is that this is a bad idea, and it should have been either the internal HR System/Identity Provider’s information. However with that opinion aside, this is something that can be accomplished via Okta using the TravelPerk Application and Okta Workflows.
While a simple method of approaching this is more feasible, if multiple approvers is required, you could alternatively use JSON based off their included Python code that they have in the documentation and run this solely in Workflows, using JSON and PATCH methods to the API.
Processes
So we have a few changes to make in Okta before we can pull and automate approval policies using SCIM & Okta Workflows.
Okta User Profile Modification
We need to go to: https://yourdomain.okta.com/admin/universaldirectory and go to the Okta User (Default) Profile and create a new Attribute.
Above is the configuration that we will use to map the Manager’s TravelPerk ID using Okta Workflows. This attribute in Okta will eventually map in an Okta > TravelPerk configuration within the TravelPerk Profile Editor/Application.
Okta TravelPerk Profile Modification
We need to go to: https://yourdomain.okta.com/admin/universaldirectory and go to the TravelPerk User and create a new Attribute.
Above is the configuration that we will have in the TravelPerk Profile Editor, this will be the mapping we push the user.travelperkManagerID to.
Profile Attribute Mapping
Once the above are complete, you will need to map the Okta Attribute into TravelPerk.
Once this is complete, we are ready to go with using the Workflow.
Okta Workflow
The full Okta Workflow can be found here.
This is a fairly basic Okta Workflow, it definitely has some room for improvement (in terms of error handling, branching, and other sections - however, I will leave that up to those that download it on how they want to manage the adjustments) on how you use it within your own environment, but it should ultimately do the job.
Scheduled Flow
At the specified time, we pull the individual employees assigned to the TravelPerk application.
Helper Flow
Once the employee record is called we:
- Read the Manager value from the Employee
- Validate if the Manager Value is blank or not (if blank, stop the flow)
- Read the Manager’s information regarding their assignment in TravelPerk
- Put the Manager External ID value into the Employee Profile via the Attribute we created earlier
From there, the employee profile information should get updated and SCIM should push the information into TravelPerk.
Alternatives
Rather than host any of this in Okta, we could also natively do this directly through the API to lookup the manager’s value of the assigned user in Okta and push the manager value every time. However, this could potentially be too abusive against the API.
Changes that needed to be made
When going through this, we found modifications needed to be modified in the SCIM Schema (most of which has been completed by the TravelPerk Team - thanks Marko!) and also from a feature perspective (at least in the Sandbox to validate the Production process).
The schemas that have changed/been modified are:
- The Automate Approval Flow feature
- manager.condition
The Automate Approval Flow feature was generally missing from the Sandbox environment, and when validating that, TravelPerk very quickly fixed the issue.
The manager.condition value was unexpected by TravelPerk, however, after confirming that we were not sending the manager.condition in any aspect of our SCIM details (thanks to Warren from Okta for also validating this!), TravelPerk made a change to the sandbox that allowed us to natively set this up and validate that this indeed worked with Okta.
Acknowledgement
I would really like to thank the following people for helping us and working with us to make sure this works fully:
- Marko from TravelPerk
- Warren from Okta
They both spent a lot of time validating with us potential issues, backend problems, and making potential changes when necessary to get this process working from the Okta side.
Once this was configured, this will allow for managers to be pushed, and updated based on the details coming from Okta. Feel free to leave any comments or questions below.