Marketing 102: Application System

Harsha Srikara
acmutd
Published in
12 min readApr 23, 2022

An inside look into how I built the application platform used by the Association for Computing Machinery

Each year, the ACM Chapter at UT Dallas (the largest student organization at The University of Texas at Dallas) processes thousands of applications across all of our various programs. These applications are for students to gain opportunities by either joining a program as a member or joining the leadership team as an officer. The largest applicant base is through program applications for semester long initiatives like Projects, Research, Education Mentor Program and Technical Interview Prep. Additionally, we also process many forms for officer applications, feedback surveys and other engagement forms.

ACM Development Application. Flyer Design by Jafar Ali.

Application season at the start of each semester is one of the busiest times of year for ACM. We usually have tens of applications open up, receive hundreds of submissions every week, send thousands of emails promoting, advertising and marketing content and spend countless people-hours in the review cycle. This was an open area for investing development effort to create a long-term solution to improve the experience for both officers and members.

Application System Part 1 | The Challenges

From observing the rapidly increasing scale of operations within ACM, it became clear that the application process was experiencing several growing pains. These included the following

  • Applicants would have inconsistencies between different applications in a given semester. This included using different email addresses (personal vs university) or optionally including middle/last name or just having typos in various fields.
  • Students felt tired out by the repetitive need to enter the same information into multiple applications. This included their name, email, grade, major, university id among other fields.
  • Applicants had no way of easily knowing whether their application had been successfully received. Many often resorted to emailing the team and officers had to go through a slow process of manually checking and replying back.
  • Students that applied to different programs that are mutually exclusive needed to be asked their preference. Finding the set of students with multiple applications was tedious since not all programs followed a standard schema for questions.

While it might seem inconsequential for there to be a handful of typos or small differences in applications, remember that once you scale any small percentage of issues to a large enough sample size that the net impact can affect hundreds of students.

All of these challenges would cause both members and officers to needlessly perform manual tasks that slowed the applicant review cycle & took up valuable time. While only a small percentage of form submissions faced these issues, given the large scale at which the organization operates it consumed an extensive amount of manual effort to account for these challenges.

Application System Part 2 | The Plan

To design an ideal system, we began in Spring 2021 to craft the plan for our minimal viable product → the set of features that would improve the application workflow and solve the largest pain points in the existing process. To do this we settled on these minimum functional requirements:

  • Members should only have to enter their profile information a single time no matter how many different programs they apply to.
  • Members should be notified after they have submitted their application with a confirmation indicating what they have applied for.
  • Members should be able to check that their application was successfully received in a self-serve manner.
  • Officers should be able to easily reach out to all applicants in an easy manner.

In addition to these requirements, we needed to adhere to some important non-functional requirements. These requirements describe constraints around how the system operates.

  • Officers should not be required to learn any new complex processes.
  • Officers should still be able to use their preferred choice of tooling.
  • Members should not face additional confusion or feel that there’s a substantive change to the application process

These requirements meant that our solution had to be a system that deeply integrated with the existing tooling and infrastructure that was already in use within the organization. This includes Typeform for forms, Sendgrid for emails, and the ACM Portal for profile management. Our solution had to run behind the scenes to seamlessly sync data between these different services without any manual intervention.

Up in the next few sections we’ll cover how the system works from initialization all the way through a member submitting their application.

Application System Part 3 | Create a form

The first step in using this Application System is to create your application. For an officer, this process has no change with previous workflows. Start by going to Typeform & setting up a new application.

Creating a new form called Sample Typeform.

Once we’ve created our new Typeform, we’ll go ahead and publish it. You’ll notice that the Typeform we’ve just created only has one question in it. We don’t ask for any details about our member (like name, email, etc). This is intentional and in future steps we’ll cover how that information gets automatically synced with Typeform. Before moving on to the next step we’ll need to copy the name of our Typeform (called Sample Typeform for our example workflow).

Application System Part 4 | Linking to Portal

Prior to the development of the Application System, I had already built at ACM UTD a membership portal used by members for profile management as well as for having a system to check in to events. Given the extensive usage of the membership platform (over 1000 users), it seemed like the perfect place to source applicant profile data when submitting a form. When new students join as ACM members, they can create and manage their personal profile on the ACM Portal.

To get started, officers would navigate to https://portal.acmutd.co/form. This page links to an internal tool (another form) that helps connect the Typeform we created in Step 3 to the profile system on the portal.

Portal Typeform Linker. An internal tool developed to support connecting Typeform to the profile management system which exists as part of the ACM Portal.

You’ll notice that this Typeform already is aware of my email address and name. This is done through Cloudflare Access & more information about how securing internal tooling at ACM is done can be read in our article about the Vanity Link Generator. Once we get started with the Portal Typeform Linker, we’ll need to fill out a few basic questions.

Enter name of Typeform created in Step 3.

The first question is the name of the Typeform that we would like to link with the portal (Sample Typeform in our example). Next, we’ll be prompted to provide a general description of what the form is for, links for any additional resources & finally an url slug.

Enter Description that describes the form being linked to the portal.

Once submitted, the answers to this Portal Typeform Linker form are passed on to the ACM Core API service via a webhook call. Here, the name of the Typeform is used to query for its unique uuid. This ID can be seen when navigating directly to a typeform → https://acmutd.typeform.com/to/<ID>. Along with this id, the description for the form, the url slug and metadata information about the person submitting the request are persisted to a document entry in Cloud Firestore.

Enter url slug used to generate a new page.

The portal endpoint question is used to determine how members will access the linked form on the portal. This url slug is used to determine the wildcard path that will be used to render the newly created Typeform as an embed. It’s possible for multiple forms to share the same slug so long as only one form at any one point in time is active. This allows for slug re-use for popular recurring events or applications. For our example, once the request is processed, the linked Typeform will be available at /forms/sample-typeform.

Enter links for additional resources to be linked alongisde the form.

Sometimes, an application may have additional resources that are relevant for members to review before submitting a response. For instance this could include a list of projects and research initiatives (for our semester long programs) or a document with a more detailed overview about an officer position. A link to these resources can be added here & will be presented alongside the linked application form to members.

Application System Part 5 | Confirmation & Verification

Shortly after submitting the request, the officer will receive a confirmation email that verifies all the information that they have entered and provides a contact in the event that anything needs to be changed. In the long term, these emails also serve as an easily accessible way to view all the forms that have been linked to the portal.

Confirmation email after submitting the Typeform Portal Linker request.

In addition to receiving an email, the ACM Core API also will post a message in a public slack channel with the same details. This helps other officers be aware of open applications and what links to use when sharing information with fellow members. This also serves as an effective way to know who the point of contact is for any external facing links, applications, or forms.

Slack confirmation message.

Application System Part 6 | Wildcard Endpoints

There are two primary goals to be accomplished with linking a form to the portal.

  • To use a portal branded link for sharing forms → https://portal.acmutd.co/forms/<name>. This branded links improves marketing and ensures that people are aware that the destination resource is a form. (Learn more about branded links at ACM here)
  • To pass along profile fields like name, email, major, etc that are managed by the ACM Portal along to typeform automatically upon a form submission.

These are accomplished by using Wildcard routes on the portal. When a user navigates to any route that ends in /forms/<something> then the portal will fetch from Cloud Firestore the list of all open applications. Then it will filter that list to check if any application object has the endpoint field set to the same string as the current path. If a match is found then that typeform will be shown as an embed to the end user.

Code snippet for determining which typeform to render on given url.

Embedding the typeform as a full page component hides the fact that instead of the member going to typeform.com/to/<something> they are instead on the ACM Portal. This ensures that they have an identical experience in their interactions with ACM and there no confusion in adapting to the new system.

Application System Part 7 | Connecting to Sendgrid

A crucial part of designing any application system is to design a robust notification service that lets members know that we’ve successfully received their submission & for members to have a confirmation that they’ve applied to the correct role. Within ACM, we use Sendgrid as our email provider since it offers a good balance of marketing features for our media team and API access for our development teams at a reasonable price.

A unique feature that Sendgrid provides is known as dynamic templates. These are essentially email templates where variables can be injected into the body or title when needing to be sent. These variables can be passed along via an API call which makes it very easy to integrate with other services. To provide email confirmations to our members we use this feature to create a template that allows the person’s name & the name of the form they filled out to be passed in as variables when being sent over an API call.

Confirmation message that a member receives after completing a form linked to the portal.

By using dynamic substitution of field names we’re able to personalize emails instead of sending a generic confirmation to members. This ensures that members are fully aware that their application to a specific program was received.

Additionally, members are also able to check at their convenience whether a successful submission happened by reviewing their ACM Portal applications page. Once a form is processed successfully, an entry of its name & the date of submission are saved to the user’s profile document in Cloud Firestore.

List of previously submitted applications via the ACM Portal. The names of all past submissions along with the date are displayed for review at any time. Allows for easy and convenient self-serve status checking.

Another powerful feature that sendgrid supports is to have custom mailing lists. These mailing lists let us create subsets of emails for users that share similar properties. For our application system, when the Portal Typeform Linker request is submitted, a new mailing list with the same name as a the form is created. Each new submission to that form then also results in that email address getting added to that mailing list. Thus, once application season is complete, should officers have the need to mass email all the respondents to a form, it can be done super easily since their information is already synced to a Sendgrid mailing list. This allowed for easily doing some of the following actions.

  • Send out reminders to all applicants for next steps. This was particularly helpful for some divisions where in addition to a form, members were also required to complete coding assignments / submit additional information.
  • Send out an email to all applicants about an update to the role or application status.
  • Curate a separately weekly newsletter and send it to all participants within a program (like the mentor program).
  • Keep track within Sendgrid about the participation and engagement of members to personalize marketing content

Previously officers would need to export all responses from Typeform, extract the email field, copy the submissions over and use either a 3rd party email plugin to send an email and/or manually import them into a service like mailchimp/sendgrid. This was extremely tedious and time consuming to repeat for each application each semester.

Application System Part 8 | Rich Profiling

Since we are using embedded forms on the ACM Portal, we are able to pass in additional metadata to Typeform via a feature known as hidden fields. This appends known attributes about an user to the Typeform URL and ensures that the applicant doesn’t need to manually enter those fields.

Code snippet that fetches attributes about a user and appends them to the Typeform URL to be consumed as hidden fields.

In the above code snippet we have a powerful component that can dynamically be configured to call different cloud functions to fetch different sets of properties and inject them as hidden fields into the embedded Typeform (ex. when linking the portal to Typeform, that embedded form calls an endpoint which returns a verified officer’s name & email address). This system is also designed to be highly secure because the backend cloud function responsible for fetching the user’s metadata information has 2 important properties

  • It validates the signature of the Authorization JWT passed in as a header to ensure that all requests originate from the ACM Portal.
  • It automatically will fetch the profile of the user whose ID is present in the JWT (provided it is valid) instead of requiring their id/email as a separate parameter. This means that it is impossible for anyone (including officers) to impersonate an account.

Once a member submits the Typeform, officers are able to view the results along with the embedded hidden fields.

Viewing results in Typeform for a sample form submission. Note the hidden fields which contain all the user’s metadata that was collected automatically.

When exporting these results to csv or excel spreadsheet, these hidden fields appear as regular columns much like any other question in the Typeform. Thus, officers can continue to use their existing workflows once they export information out of Typeform.

Application System Part 9 | The Impact

Since its implementation in Spring 2021, this system has help process upwards of several thousand forms from hundreds of users. In the last semester (Spring 2022) alone, over 800 applications to programs like ACM Projects, ACM Research, Technical Interview Prep and the Mentor Program were received.

Doing a small experiment of asking a few members to manually type of their profile information (name, email, major, etc) showed that the average student takes between 45 seconds to 1 minute to enter those 6 fields correctly. Extrapolating to 800 submissions that’s over a dozen hours saved by just our members in this semester. When accounting for efficiencies gained by officers, it saves much more time for everyone involved in the process.

As one of the more complex systems that I’ve designed during my tenure in the Association for Computing Machinery, I’m proud of the impact that this service has made and will continue to make. This project helped define new standards in what it means for not just designing software that is computationally efficient but also for designing software that leads to efficient customer experiences. Identifying pain points in our members’ interactions and working to deliver an environment that prioritizes their convenience can lead to increased engagement and positive experiences for members and officers alike. At large scale, the smallest gains in efficiency lead to huge overall results.

If you’re looking to try out the system for yourself, head over to the ACM Portal & fill out our member experience survey!

--

--