Capacity Management

With the Capacity Management v1 release, we added logic to include the pending registrations when calculating the Remaining Capacity. Now, the Remaining Capacity is calculated by subtracting the completed and pending registrations from the Event’s Total Capacity, which the Events Organizer sets in Salesforce.

Capacity is checked at multiple points during the registration process. If the Remaining Capacity reaches zero, the user will see a message and cannot continue until they remove the sold-out item from their cart. In addition, we enhanced batch processing to reconcile capacity counts by including new pending registration counts once every minute.

While this is not a complete solution that addresses all use cases, it does address many of the most common situations that cause over-enrollment.

Note: This does not include waitlist capacities.

Important Prerequisites

For Capacity Management to work correctly, you must perform the following.

• Upgrade your org to Salesforce Events version 4.23 or later.
• Review all custom flows, as they may interfere with functionality.
• Click the Schedule Batch Event Registration Submission Job button to turn on batching. If the Batch Event Registration Submission scheduled job is already running, click the Disable Batch Event Registration Submission Job button and then click Schedule Batch Event Registration Submission Job again to ensure that all jobs are rescheduled correctly.
  

High-Level Diagrams

Single-Screen Experience

Multi-Screen Experience

Post-Enhancement (May 2024) State

What’s New?

Salesforce

• Capacity calculations have been modified. The pending count value is now included in the Remaining Capacity field calculation, ensuring that queued pending registrations will be removed from the available capacity. This change allows us to determine the Remaining Capacity more accurately.
• We have expanded the integration between the webapp and Salesforce so that the following will occur.
  • Potential Attendees will see a more detailed error message when Remaining Capacity is unavailable.
  • Event’s will now track pending registrations so they can be used in capacity calculations.
• A batch job will reconcile pending and completed registration counts as the registrations are completed.

Webapp

The webapp will continue to make the same number of calls to Salesforce. Each time the webapp makes a call to Salesforce, the Remaining Capacity will be checked for availability.

• If a call returns no available capacity, the potential Attendee will see a message and cannot continue with their registration.
• Single-Page layout: Two calls are made.
  1. Start Checkout Call occurs when the potential Attendee clicks the Payment or Place Your Order button.
  2. Final Checkout Call rechecks the capacity if the Start Checkout Call is successful. It then changes the Event Registration Submission (ERS) record Status to “Processing” if capacity is available.
• Multi-Page layout: Three calls are made.
  1. Draft Call occurs when the potential Attendee clicks the Checkout / Continue button after entering their information.
  2. Start Checkout Call occurs after the potential Attendee clicks the Payment or Place Your Order button.
  3. Final Checkout Call rechecks the capacity if the Start Checkout Call is successful. It then changes the ERS record Status to “Processing” if capacity is available.

Updated Equations

• Event Object

  • The Capacity Threshold Limit now includes Attendees with an Event Registration Submission (ERS) Status = “Draft,” ensuring the number of remaining Tickets (Remaining Capacity) is correct.
  • The Remaining Capacity formula now includes the new Pending Capacity (conference360__Pending_Capacity__c) field in its calculation.
  • Remaining Capacity = Total Capacity - Attendee Limit Buffer - Registered - Pending Capacity

• Session Object

  • Attendees will now see an accurate number of remaining Session spots when registering for an Event.
  • The Quantity Remaining formula now includes the new Pending Capacity (conference360__Pending_Capacity__c) field in its calculation.
  • Quantity Remaining = Quantity Available - (Registered + Pending Capacity)

• Event Item Object

  • Attendees will now see an accurate number of remaining Event Items when registering for an Event.
  • The Event Item's Quantity Remaining formula now includes the new Pending Capacity (conference360__Pending_Capacity__c) field in its calculation to improve the accuracy of the Event Item’s available capacity.
  • Quantity Remaining = Quantity Available - (Registered + Pending Capacity).

Detailed Breakdown of the Registration Journey

1. The Draft Call to Salesforce includes a capacity validation and prevents a registration if the Event is sold out. (Multi-Page layout only)
   1. WEBAPP The potential Attendee browses the Event’ webpage, goes to the registration page, and enters their registration information. (This step is before they submit their payment information.)
   2. WEBAPP A Draft Call is made to Salesforce. In the Draft Call, the registration request is not submitted. This allows the following to occur: 1) Create a draft ERS record in Salesforce, and 2) check capacity.
   3. SALESFORCE
      • Salesforce creates an ERS record with Status = “Draft.”
      • NEW The validation includes Attendees with Registration Status = “Processing“ (i.e., registrations currently pending in the queue while they are being processed) in the Remaining Capacity field calculation. If no capacity is left, Salesforce returns a Failure status with a message to the webapp.
   4. WEBAPP
      • NEW If the call to Salesforce returns a Failure status (i.e., the Event’ is sold out), the potential Attendee will see an error message and be prevented from proceeding.
2. Checkout Process Start
   • For the Single-Page layout, the potential Attendee enters their information.
   • If the Event’ is a paid Event’, the potential Attendee enters a payment method and associated payment information.
3. Checkout Process Completion (The user clicks the Payment or Place Your Order button.)
   1. WEBAPP A Start Checkout Call is made to Salesforce to check capacity.
      • If this is a Single-Page layout, it also creates a draft ERS record in Salesforce since this is the first time Salesforce has been called.
   2. SALESFORCE
      • NEW Capacity validation occurs.
        • The new capacity calculation logic, which includes Attendees with Registration Status = “Pending,” is used.
        • If no capacity is left, Salesforce returns a Failure status with a message to the webapp.
      • If this is a Single-Page layout (i.e., the first call to the webapp), Salesforce creates an ERS record with Status = “Draft.”
   3. WEBAPP
      • NEW If the call to Salesforce returns a Failure status (i.e., the Event’ is sold out), Salesforce displays an error message, and the webapp prevents the potential Attendee from proceeding.
   4. WEBAPP If the Start Checkout Call is successful because capacity is available, the webapp will make a Final Checkout Call to Salesforce. In this call, the webapp submits the registration request, which causes several registration-related things to happen in Salesforce.
   5. SALESFORCE Processes the call from the webapp.
      • NEW The capacity is validated.
        • The new capacity calculation logic, which includes Attendees with Registration Status = “Pending,” is used.
        • If no capacity is left, Salesforce returns a Failure status with a message to the webapp.
      • If the Event’ has Remaining Capacity, Salesforce will update the draft ERS record from the previous step to Status = “To Process.”
      • NEW The pending count value will include the registrations that are in the queue to be processed.
   6. WEBAPP ENHANCED If the call to Salesforce returns an error, the potential Attendee will see an error message about no availability.
4. The batch process, which runs once every minute and is processed on a first-in-first-out basis, will process the registrations and reconcile the pending count field.
   1. Invoices and Line Items will be created.
   2. Attendee records will be created.
   3. The ERS record will be updated to Status = “Complete.”
   4. NEW The pending count will be updated to remove the processed registrations.
   5. All other processing actions, including capturing financial transaction information and roll-up calculations, will be completed.
   6. A cache invalidation request will be sent.