BCCINT4003: Custom Integration Data Transformation Scripts


The first two modules in the series discussed creating custom actions and ensuring your authorization is correct, both of which are incredibly important to connecting applications into BetterCloud and performing automated actions via workflows. Now let's explore what goes on in the background, when a call is made out to the third-party application from BetterCloud. How is BetterCloud able to take something like an email and transform it to userID 198376281? 

Understanding Data Transformation Scripts

The answer to this is data transformation scripts, which essentially act as the middleman between BetterCloud's workflows and the third-party provider's API. These scripts update the payload for the webhook to be executed, and can be used to handle complex authentication types to add to actions and things like that. In the video below, JB Lovell, BetterCloud's Integrations Practice Manager, reviews how to create a data transformation script to get a user's ID in order to perform an action.

After viewing this video, you'll be able to:

  • Define data transformation scripts and why you would use them
  • Explain Input and Callback within the module.exports function
  • Create variables and assign them values
  • Call functions as defined by the third-party provider
  • Transform a user's email to their userID as needed by the third-party provider
  • Create a Callback that returns a function back to a webhook so an API call can be made
  • Explain what a promise is so that events can be chained and the getUserID function will be successful

Why does data need to be transformed?

When running Workflows in BetterCloud, such as offboarding, you'll want to ensure a user can be identified by their email address. In short, a user's unique email across multiple SaaS apps can be used in actions to change passwords, reset sessions, delete mobile devices, transfer files, and remove the user from their applications, groups, calendars, and permission sets. However, some third-party applications will require you to use an employee's User ID , not their email, to take action on the user via an API call.

Through BetterCloud's UI, user's are passing in the employee's email address into the offboarding Workflow, adding it to the email field for all actions being performed. However, in the background, the userID may be what is required; so BetterCloud will transform joe.smith@company.io into Joe's userID (ex. 1886872981), which is what the third-party application is expecting. This transformation ensures the email can be used by front-end users, making offboarding simple and streamlining actions without needing to define how to get the user's ID. Meanwhile, on the back-end system, the payload is built properly by BetterCloud so no errors occur.

What's Next?

For now, this was the last module in our Developer series. Please feel free to check back here for future articles on custom integrations, actions, and more.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request