Builder
— 5 min read
Building apps for multiple Salesforce campaigns
As a builder in Airkit, I’m often shocked by how many features or technical requests I’m asked to build into applications that would have taken weeks or months to properly build and scope for, and in Airkit I can have these built and incorporated into a tool by the end of the day.
Take, for example, a recent ask I received from our events and marketing team. Airkit will soon be throwing several Top Gun: Maverick themed dinners and events around the country for our customers, interested parties, and their families. For our “CX Mavericks Roadshow,” it was important to the marketing team to have an Airkit application for attendees to use to check into the various events; however, the challenges was keeping track of all of these events happening at different times and different places around the country, and making sure we knew who was checking in where and when in our CRM tool.
A Quick Front End
In terms of building the application itself, the overall flow was extremely simple, and a use case we see Airkit builders using all the time: a digital form.
For the quickest and most seamless check in experience for the attendees of the events, I knew I wanted to build a one page form collecting the information our marketing team asked for, and a quick thank you page to get started. For certain events, I built out a very simple SMS notification to send out to the attendees who check into the event. But all in all, most of this process was a very simple task to take on.
This differed, however, in the back end of this application. The question was: How do I build this application so that after someone checks into the event using the app, the app knows which record to update in Salesforce?
Easy Integrations
One of the most useful parts of building applications in the Airkit platform is how easy it is to bring integrations into applications. Truly with just a few clicks I was able to integrate with our Salesforce account so that I could start to interact with attendee information there.
Airkit even comes with out of the box data operations that pull options directly from the connected Salesforce license, so with minimal work I can do things like query records for campaign member information and update them accordingly.
In the application, I had built out the data operations to a point where I could find a specific attendee based on their email address, and I could hard code in the campaign ID that was associated with the specific event, I could update that information in the event on Salesforce. The only issue with this was by hard coding in that campaign ID, I had created the need for there to be an application deployed for each of the events happening, since I could query salesforce using the attendee information.
These individuals checking in could be connected to multiple campaigns, so I couldn’t just look them up and change their attendance status. I also couldn’t expect users to sign in using the campaign ID we had privately associated with this event, that would be insane. How could I pass this information in dynamically so that I would have to deploy 9-12 different versions of the same application?
Enter the URL Parameter
Luckily, an answer had been sitting in front of me the entire time. Airkit applications have a few features readily accessible to them in the “session” namespace once they have been deployed, including URL query parameters. I realized that I could pass in the campaign ID as a query parameter for the application, and access that parameter when I pass data to the salesforce operations.
Using this property, I could now just deploy a single application, and send the marketing team various URLs with the appropriate query parameters at the end of them. Each event was going to have a QR code used to direct attendees to the application, so in the end we just needed to create a QR code per event and its associated URL.
Overwhelming Potential
What keeps me amazed at the Airkit studio is that I keep running into situations where I assumed I had reached the end of what Airkit could do, and it proves me wrong. There have been plenty of moments where I assumed I would have to rely on more traditional application development to get something done.
I was wrong again and look forward to when I’m wrong another time.
