Is there a way to put a maximum registration for a session using Marketo as the method of signing up?

[Anonymous]

We have an event we are running through Marketo to do the invite and registration. Part of the form will be to choose which sessions an attendee wants to register for. Is there a way to cap the number of people that can register for each session within a Marketo form or program? If not, do you have an alternate that you would suggest?

[SanfordWhiteman · Accepted solution]

This is an extremely frequently asked question.  I think there's another open question on the same topic from just this week.  It probably didn't get an answer because it's exhausting to explain that there's still no built-in method.

The workaround:

• use, or build, a service that can be called as a webhook to get and set the current # of registrations
• signal that registration is closed by some method, either by [a] hiding the page, form, or part of the form that refers to the session that is overlimit and [b] allowing the form to submit and putting the lead in a standby list if over limits (sending them a message accordingly)

The second component is actually the more interesting one. I like to update a program token ({{my.token}}) with the current count. This allows you to use the {{my.token}} to control display of the page.

[Anonymous]

Interestingly I have a similar requirement although for a different purpose.

I would like to be able to count the amount of registrations and if below a certain threshold alert the sales person about the lack of participation. Additionally, this information could then be use as an automated internal audit to alert the organisation.

[SanfordWhiteman]

That goal is even easier then the reverse because it doesn't require real-time (or near-real-time) updates.

The way we set this up is with a resource lead (I've written about this in a few places) that's dedicated to each event. This is a Marketo lead that gets a field like RegistrationCount, a standard score field, incremented whenever somebody is added to a corresponding event program (and decremented if somebody is removed). Run a batch every day against your resource leads to see how registrations are doing, and send alerts as necessary.

I'll get into it more on my blog at some point, but you can update the resource lead in different ways:

1. One is via a supplementary submission (from the client) to the forms /save2 endpoint.  This is extremely scalable for non-malicious hits, though not particularly secure (but if you weren't going to filter on the server side, it comes out no worse than the other options).
2. Another is calling the forms /save endpoint from a webhook. This is the easiest option, but it does have a scale issue (1 form post every 2 seconds). You might spread the hits out by routing via a CDN, which will multiply the max posts-per-second.
3. Another is an API update. This one is the least scalable and production-ready, since it has the same DoS vulnerability of any end-user-guided API consumer. I would find little justification for this approach given the alternatives.

This resource lead pattern is similar to the use of Exchange/Active Directory objects to represent copy machines or meeting rooms, if you're familiar with that world.

N.B. Expanded solutions can use an intermediate database, like FlowBoost's FBTimeSeries, and reap some cool rewards (like tracking the average number of signups per day/hour and other intersecting stats). But they aren't necessary to meet the core goal.