Registration limits with waitlists using Self-Service Flow Steps

Josh
Level 4 - Champion Level 4 - Champion
Level 4 - Champion

How can I set registration limits for a program in Marketo??

I’ve been asked this more times than I can count, and you will find it regularly asked here on Marketing Nation. That’s because when running events with limited capacity, managing registration limits becomes vital. Keeping everything under control ensures the event fits within its allocated space and resources, which helps everything go smoothly and keeps attendees happy. But, manually tracking these limits can be tedious and prone to errors. Automating this task with Self-Service Flow Steps in Marketo not only streamlines the process but also enhances the experience for everyone involved. This blog post will guide you through a solution that makes managing event capacities easier and more accurate.

First of all we started with a custom self-service flow step (SSFS) - For more information on Self-Service Flow steps check out the official documentation.

Josh_5-1716116755401.png

 

Flow Step Fields

We need 3 fields on our flow step.

  • Registration limit ( an integer field) that sets the limit
  • Registered Status - text field (string) - This is what the person’s status should be set as if the registration limit has not yet been met
  • Waitlist Status - text field (string) - This is what the person’s status should be set as if the registration limit has been hit.
     

Admin (Global) Fields

Unfortunately, we cannot set program status with a SSFS callback, so we need to use the Marketo REST API. For this we need API credentials, we could build this into our backend, but since we want to use this across multiple internal and client instances, we built this the flow step as admin fields.

  • Marketo Client ID
  • Marketo Client Secret
    Josh_8-1716116938490.png

If you are unfamiliar with how to set up a custom REST API service you can follow the official guide.


Data Flow

Josh_9-1716116984323.png

 

When the flow step is called it passes the following to our service


Subscription context

We take the munchkin ID from this to get the base url for the API which will be: https://{munchkinId}.mktorest.com

"subscription": {
	"munchkinId" : "123-ABC-456",
	"prefix": "mymarketoname",
	"crmSyncStatus": "enabled_inactive"
}

 

Admin Context

This is where we stored our API credentials

"admin": {
	"marketo_client_id" : "12abcd3e-4fg5-678h-9i01-234jklmn5opq",
	"marketo_client_secret" : "1Ab2C~D3E45FgHiJKlm_No67P89qrstUvwx0yZa"
}


Program Context

Here we get the information about the program where the flow step was triggered. We will use the program ID from here to identify which program to change the user’s status in.

⚠️ Note: this only works when the flow step is used by a smart campaign inside a program

"program": {
  "id": 1961,
  "name": "202405 - My Exclusive Event",
  "description": "",
  "type": "default",
  "status": "",
  "workspaceName": "Global",
  "channelName": "52",
  "createdAt": "2023-08-18T07:07:26.000-05:00",
  "updatedAt": "2023-08-18T07:07:27.000-05:00"
},

 

Flow Context

These are the fields on the flow step itself. We get the following data for each person.

  • Marketo person ID
  • Registration limit
  • Registration status and waitlist status
  • User’s current status in the program
{
  "objectType": "lead",
  "objectContext": {
    "id": 180876
  },
  "flowStepContext": {
    "registration_limit": 40,
    "registration_status" : "Registered",
    "waitlist_status" : "Waitlisted"
  },
  "programMemberContext": {
    "status": "Invited",
    "id": 42784,
    "membershipDate": "2022-08-18T11:27:17.000-05:00",
    "reachedSuccess": false,
  }
}
  • Since we receive the person’s current program status, if they are already registered we just skip the API update.

  • Using the REST API (Get Program Members endpoint) we first check the number of people currently in the given registration status in the Program. In the past we have used an external counter for registration limits. However, this can have errors. For example if membership is every changed manually it can lead to the counter being out of sync with the true registration number.

  • Next we use the Sync Program Member Status API endpoint we update the program status of the person.

     /rest/v1/programs/{programId}/members/status.json
    • IF the # of registered people less than the registration limit sent we use the REST API to change the person’s status to the “Registered” status
    • IF the # or registered people is greater or equal to the registration limit we use the REST API to change the person’s status to the “Waitlist” status

 

Callback

Josh_10-1716117116999.png

 

Once we update the program status, we make a callback to Marketo. With this we pass back the following data:

  • Status (Registered / Waitlisted)
  • Current registration number for the program
  • Current registration as % of limit 


We added these data points based on feedback from @Zoe_Forman.  With this we can set a trigger and send ourselves an alert when registration reaches a specific percentage.  Adding the "Status = Registered" allows us to get these notifications up until people reach the limit, but not afterwards.  We could also use a specific number if we want to be 
Josh_11-1716118339412.png

 We can also trigger on a specific number:

Josh_13-1716118798234.png

 

Usage

  1. We add the flow step to you smart campaign
  2. Set the Registration limit, Registration Status and Waitlist Status.
  3. Trigger when the user fills out our event registration form. 

Josh_5-1716116755401.png


Pros, Cons, Considerations

 

Status must be exact 

The default (registered) and waitlist statuses are open text fields but when setting them they must match exactly the status in the program you are trying to set. 



No Batch Usage  

While technically this flow step can be run in batch, it doesn't make much sense for it's intention. We've intentionally made it return an error when running in batch. 

 

Race condition 

Because this works asynchronously, in theory if 2 people registered at the exact same time, and there was only a single spot left hitting the registration limit,  we could end up with a registration count 1 more than the limit.  This mostly comes down to the API call to check the number of registrations being a separate call from the "Change Status" call.  Meaning if multiple records are going through the flow at the same time, it could retrieve 49 of 50 registered for both, and consequently register both. However, while this is theoretically possible, we have not seen this in real world use.

 

API Usage 

This process does consume 2 API calls per registration which is a consideration but not a big impact for our use cases. 


Could this be done with a webhook?

Yes, in fact this is how we solved this in the past, but webhooks do not offer the customization we have with flow steps, like being able to set the registration limit and statuses right on the flow step.  I have previously written a blog post about Self-Service Flow Steps solve 5 major limitations of webhooks


Infrastructure

Where do I host this? You can of course host this on a server or virtual machine in the cloud. However for speed and simplicity I would recommend using a serverless option (Adobe IO, Microsoft Azure Functions, AWS Lambda, Google Cloud Functions, etc.). For even more simplicity you could use a no-code solution. Currently Workato is the only solution with a built in Marketo Self-Service Flow Step option.


Conclusion

Leveraging Self-Service Flow Steps in Marketo, you can effectively manage event registration limits and automate waitlist processes, and ensure a smooth and error-free experience. Yes, the initial setup is involved, but this method eliminates the tedious and error-prone task of manual tracking, providing a seamless solution that scales with your needs. Integrating this approach with the Marketo REST API allows for dynamic status updates and improved registration management.

I hope this has been helpful in setting up registration limits using Self-Service Flow Steps but I would love to hear from you! Do you have any questions or ideas for improving this flow? Are there other challenges you think self-service flow steps could be used to solve? Please share your thoughts and experiences in the comments below!

2038
2
2 Comments
Zoe_Forman
Level 9 - Community Advisor + Adobe Champion

Thanks @Josh for the shoutout, looking forward to implementing Registration Limits SSFS and being able to show when nearing capacity, having an alert at 90% for example.

SanfordWhiteman
Level 10 - Community Moderator

Race condition 

Because this works asynchronously, in theory if 2 people registered at the exact same time, and there was only a single spot left hitting the registration limit,  we could end up with a registration count 1 more than the limit.  This mostly comes down to the API call to check the number of registrations being a separate call from the "Change Status" call.  Meaning if multiple records are going through the flow at the same time, it could retrieve 49 of 50 registered for both, and consequently register both. However, while this is theoretically possible, we have not seen this in real world use.


FTR, we see real-world race conditions like this for busy events, and our (webhook-based) solution was deliberately redesigned to prevent them.

 

A registration counter needs to be strictly monotonically increasing (not simply non-decreasing) with every registration. This covers people uploading lists of registrants, too.