Using Transposit to automate our alpha user onboarding

At Transposit, we just invited our first group of alpha users to play around and provide feedback on our product. The process to add new alpha users to our whitelist was manual, involving a lot of repetitive tedium with many opportunities for error (which of course happened for more than one user). In this blog post, I’ll show how we automated Transposit itself to save time and reduce the complexity of onboarding alpha users, without having to build any new functionality into our core product.

The manual invitation process#

For our alpha program, we wanted to give early access to Transposit to hand-picked testers. We also didn’t want to block this early launch on building a complete signup flow, so we decided instead to ask each user for a preferred username and a GSuite email address they’d like to associate with the account as part of our invitation email. Once we received those details, we manually added them to a whitelist.

In a pre-Transposit world, we had only one option for maintaining our alpha user whitelist: adding each alpha user to the product via a code change. Here’s where we ran into our first issue: Because of our two-tier release cycle, any code change to our production application required 48 hours before going live.

To us, this was an unacceptable time to ask a new user to wait before accessing the product. It also meant that there was no way for non-engineers on our team to add to and manage the whitelist themselves. Finally, we didn’t want to get into the practice of hard-coding anything in the product that wasn’t involved in core functionality.

Automating whitelist additions with Airtable and Transposit#

To solve for the delay and requiring an engineer for any updates to the whitelist, we decided to leverage Transposit’s SDK to create a whitelist outside of the main app, with a minimal imprint on our code base. As we learned, automating these kinds of workflows is one of the areas Transposit really shines.

We decided to manage our alpha user whitelist by hand in Airtable, allowing anyone with access to the table to add a new user on their own. We then built a quick Airtable integration with Transposit that fetched the whitelist from Airtable and returned the results as an endpoint. Next, we simply pushed one small code change to our core product that hits our new Transposit endpoint every minute to check for changes to the whitelist. Almost as soon as a new user is added to that table, they’re able able to sign in to.

public void fetchWhitelist() {
  String whitelistEndpoint = “https://api.transposit.com/app/transposit/tt_whitelist/api/v1/execute/get_whitelist?api_key=XXX";
  HttpPost httpPost = new HttpPost(whitelistEndpoint);
  httpPost.setEntity(
    new StringEntity(“{\”parameters\”:{\”stage\”:\”” 
      + stageName + “\”}}}”, ContentType.APPLICATION_JSON));
  HttpResponse response = httpClient.execute(httpPost);
  HttpEntity entity = response.getEntity();
  whitelistMap = parseWhitelistMap(entity);
}

An unexpected silver lining#

Separating the whitelist management from our core functionality was appealing from the beginning, but we ran into another instance where this proved to be helpful.

Managing the whitelist in Airtable was still fairly manual (if less cumbersome), and allowed us to introduce human errors into the workflow. We ran into this after one of our users wasn’t able to log in with the username they’d requested. After some digging around, I discovered that I had accidentally copy-pasted an extraneous blank space in front of their username into Airtable, triggering a validation error for an un-permitted character.

To prevent this from happening again, all we needed was to change the code in our Transposit operation to strip away any whitespace before or after usernames added to the Airtable. Because this was simply a change to the integration code, we benefited both from not having to wait on a full release cycle as well as not adding additional complexity to our main product for this temporary feature.

More control over custom workflows#

In the end, building this integration was simple and saved us a lot of time. Not having logic specific to alpha onboarding in our codebase was more elegant and secure, since we didn’t want to have to give this temporary efficiency the same consideration we were giving more critical product functionality. It also allowed us to quickly tweak the way this process worked without requiring a release cycle.

It was so easy and helpful, in fact, that we almost immediately identified another part of our onboarding process that was starting to take up too much resources: sending those invitation emails themselves. Stay tuned for that story next week!