Home / Blog / Automating TravelPerk Approval Process using Okta Workflows
Published: May 10, 2022 / By Andrew DoeringTravelPerk 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.
So we have a few changes to make in Okta before we can pull and automate approval policies using SCIM & Okta Workflows.
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.
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.
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.
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.
At the specified time, we pull the individual employees assigned to the TravelPerk application.
Once the employee record is called we:
From there, the employee profile information should get updated and SCIM should push the information into TravelPerk.
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.
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 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.
I would really like to thank the following people for helping us and working with us to make sure this works fully:
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.