EventSprout is an event management and Ecommerce solutions that event organizers use to sell tickets.
In a typical sale, a single user goes to buy a single ticket and the checkout is very simple.
But what if a group wants to buy tickets? Or an organization comprising of dozens or even hundreds of participants? A single checkout process would take hours and with so much information added to one server request, it could break the process altogether.
The solution? Adding mass import functionality for customer support to use at their discretion for these large sales.
In short, the organization would send over an excel file filled out with member information. Everything from name and age to shirt size and address could be filled out before hand and uploaded to EventSprout for mass order creation.
First, I needed to validate that the file was a CSV. Excel files, PDFs, and other images types don’t produce clean data for use in segmenting multiple users and their data.
After validating a proper file had been uploaded, the user would select the event these customers were attending and select whether or not the system should email users after successfully adding them. Easy enough.
Status: It’s Complicated
Though fields like first name, last name, and email are required for every single event on the platform, each event can have unlimited additional questions for participants to fill out such as age, address, gender, shirt size, etc – each requiring their own custom validation rules.
I needed a way to preview a few of the uploaded columns and allow the user to select which column was for each event question. This included the ability to ignore an unnecessary column and ensuring no duplicate columns were selected by accident.
Additionally, there was no simple way to choose which ticket these customers wanted. EventSprout doesn’t know that GA stands for General Admission, so I had to build out a “ticket translator” for the user. For any event, it would generate the proper value of the ticket name, including the groups it was nested under. If this proper name was not added to the ticket column, it would throw an error.
Speaking of Errors
Now, what if a row had an error? Should we invalidate the entire import?
I decided to allow successful orders through and create a new CSV of failed rows – including their error message – so that the user could correct the data and re-upload with ease.
If that all sounds easy enough, let’s remember that this had to work within the existing platform and a ton of core code needed to be modified in order to pass through orders in this way. Code that was in use on an existing Ecommerce platform that handles hundreds of thousands of dollars of transactions for their clients, not in a pre-launch development bubble.
So, in that light, I created unit tests to run against every new commit that tested both the success and failure of mass imported CSVs.
In the end, the packaged product solved the problem nicely to the delight of customer service reps who had to enter all these customers manually before.