Use this link to share with your colleagues:
September 2021 Release Notes: https://help.pm.leapevent.tech/a/1450294
We're excited to bring you the September 2021 release! This update includes a range of Donation improvements, including new frequency options for recurring credit card donations, more control over frequency and level on Donation Forms, new roll-up fields, and more. You'll also find Virtual Event enhancements (including geofencing!) and more. Read on to learn all about:
- New frequency options for recurring donations
- New Donation Form options
- Donation improvements & bug fixes
- Virtual Event enhancements
- Other improvements & bug fixes
Let's jump in!
Want to watch the release webinar? Here ya go:
New Frequency Options for Recurring Donations
In addition to the Monthly and Quarterly options you've always had for recurring credit card donations, your patrons can now schedule their gifts to happen automatically Semi-Annually (i.e. every six months) and Annually.
You'll see these options when creating a recurring donation internally, and you can also add them to your V2 Hybrid and Recurring Donation Forms. And speaking of Donation Forms...
New Functionality for Donation Forms
The updates outlined here apply only to V2 Donation Forms, which have been available since the May 2020 release.
Legacy Donation Forms will be retired on January 31, 2022; if you haven't switched over to V2 Donation Forms, now is the time! Use these instructions to make the switch and deactivate your Legacy forms.
Customize frequency options on Donation Forms
V2 recurring and hybrid Donation Forms now include an option to choose which frequency options are available for patrons to select. For example, you could have a hybrid form that accepts only one-time or recurring annual donations, or a recurring form that only allows monthly or annual gifts.
Whether a form accepts single or recurring donations (or both) is an choice you'll make when creating the form, and you can't change it later (you'd create a new form instead).
If your form is set up to accept recurring donations, however, you can adjust the Frequency Options that appear on the form at any time.
Choose which Donation Levels appear based on frequency selection
Not only can you customize which recurring frequency options are visible on V2 Donation Forms; you can also decide which Donation Levels appear for each frequency selection!
This allows you to have a Donation Form that, for example, accepts gifts of a specified amount (say $120 per year), but allows patrons to split out their payments how they choose (e.g. $10/month, $60 every six months, or $120/year).
You could also have the write-in "Other" option available for each frequency selection, but provide suggested giving amounts that vary based on frequency. It's entirely up to you!
You'll make these granular adjustments by clicking the "Edit All Levels" button in the Donation Levels section of the form builder. You'll find full instructions in this article.
More Information on the Donation Forms page
Your Donation Forms tab now includes additional info to help you tell your forms apart. Quickly hide inactive forms with a checkbox, and see information about the donation types and created date in new columns.
We strongly recommend deactivating any Donation Forms you no longer use (e.g. legacy Donation Forms!) and using the "Inactive Form Message" to provide any donors who use the old form's link with a link to your current, active Donation Form.
For more information about how to smoothly switch over from legacy to V2 Donation Forms, check out this article!
Donation Improvements & Bug Fixes
From new complex roll-up fields to bug fixes, there are a range of other improvements in this release. Click to learn more about:
This field shows the amount of the Closed/Won Donation with the earliest Close Date associated with a given Account, excluding the Donation Record Types defined in the Organization Settings tab. The field values update nightly.
Note: PatronManager has always included a roll-up field for the First Donation Date, but that field does not exclude any record types. If you wish to make a new version of the First Donation Date field that excludes certain record types, you can create a standard Salesforce roll-up field for that!
You'll find the First Donation Amount field in Account reports; if you'd like to make it more visible, you can also add it to your Account page layouts.
This field shows the date of the Closed/Won Donation with the largest Amount associated with a given Account, excluding the Donation Record Types defined in the Organization Settings tab. The field values update nightly.
If an Account has multiple gifts of the same largest amount (e.g. they give $1,000 every year, in addition to occasional smaller gifts), this field shows the date of the most recent "largest" gift.
Note: if you'd like to see the Largest Donation Amount for a given Account, you can create a standard Salesforce roll-up field for that! Be sure to exclude any Donation Record Types that should not apply.
You'll find the Largest Donation Date field in Account reports; if you'd like to make it more visible, you can also add it to your Account page layouts.
Previously, picklist fields on V2 Donation Forms were narrower than expected, and long values could be cut off. Now, the field dynamically sets the width (within screen space limitations) to show the full options:
Internet Explorer is not compatible with V2 Donation Forms, and is no longer supported by Microsoft.
To avoid complications and patron confusion, patrons who open a Donation Form using Internet Explorer will see a message on the page in place of the Donation Form content that reads "This page is not compatible with Internet Explorer. Please try a different browser."
The header logo (which you can link back to your website on the Donation Form setup page) and the footer fields will remain visible to patrons.
If you are concerned about patrons using this outdated browser as their only web browser, be sure to place information about other ways to give (e.g. by phone or by mail) in the footer fields.
Previously, a user could change the Payment Type on a "Pending" recurring credit card donation installment - but this does not stop the system from attempting to process the credit card, which resulted in reconciliation problems.
Now, users who attempt to change the Payment Type in this scenario will see an error message directing them to the article about How to Edit Recurring Donations.
This article provides alternate solutions, such as suspending the recurring credit card donation (if the patron needs to pause their payments and resume later), or canceling the recurring credit card donation (if the patron wishes to, for example, set up a Pledge that they'll pay off via check or cash instead).
Previously, creating a placeholder Donation record and then using the "Process Credit Card Transaction" button (e.g. on a Pledge Payment) could delete that Donation if the credit card transaction was declined. This also sometimes affected recurring credit card donations in the case of a decline, and could delete the recurring donation record as well.
Now, the placeholder Donation record (and recurring donation if applicable) remains in the system so that a user can try the transaction again, or choose to intentionally delete the record if they prefer.
Previously, creating a recurring credit card donation and setting a Start Date in the future could cause the future installments to have two dates included in the Donation Name.
Now, recurring credit card donations with a Start Date in the future will name the installment Donation Records correctly (using the Close Date as part of the Donation Name).
When a recurring credit card donation installment is processed automatically on its Close Date, the system also updates the "Amount Paid" field on the related Recurring Donation record to reflect the new payment.
However, when resolving a payment exception and manually charging a patron's credit card for a recurring donation installment, the "Amount Paid" field was not updated. This could lead to discrepancies in that field.
Now, resolving a payment exception by charging a patron's credit card on a recurring donation installment will also update the "Amount Paid" field on the related Recurring Donation, helping maintain accuracy for reporting later on.
Virtual Event Enhancements
Many PatronManager clients have had strong success with Virtual Events during the pandemic, and plan to continue expanding their virtual audiences in future. The feature is still growing; if you're not using Virtual Events yet, learn more and get started here.
Do you need to limit access to your virtual events by location? For example, if you're premiering a new work that should only be available in a specific geographic area for a period of time? Now you can! Geofencing allows you to control which patrons can view your virtual content based on their IP address location. Be sure to clarify the rules to patrons during the purchase process to avoid disappointment.
Ready to get started? Click to learn more about geofencing your Virtual Events.
Hurrah for branding consistency! Instead of the previous generic blue button, your patrons will now click a button to view their Virtual Event that matches the buttons on your Public Ticketing Site. This applies to both Automated Communications using the "Virtual Event Access Link" merge field (as shown below), and confirmation emails.
Buttons in the player, like the "Start Watching" button on the access gating page and the "Launch Stream" button that appears for "Livestream (External)" events, normally use your PTS brand color. In some cases, though, that brand color is too dark to provide sufficient contrast with the background color of those areas.
Now, the player checks for accessibility contrast levels - it will use your brand color for buttons where possible, but if that color doesn't provide enough contrast to be legible, it defaults to a white button instead:
Previously, viewers had to exit full screen mode to access controls like the pause button or closed captions for VOD.
Now, moving the mouse or interacting with the screen brings up the player controls, which then disappear again after a couple seconds of inactivity.
Other Improvements & Bug Fixes
With each release, we tidy up bits of unexpected behavior and make incremental improvements to PatronManager.
Previously, the process that manages Automated Communications (used for pre- and post-show emails in PatronManager) checked at the top of each hour for ticket holders eligible for that particular batch of pre- or post-show emails. This timing made it difficult to predict exact delivery times and decide on the cut-off time.
For example, let's say your show happened at 7:30pm and you wanted pre-show emails to go out one hour before the show, at 6:30pm. When the process did its hourly check at 6pm, it was too early, so the emails didn't send. The process didn't check again and actually send the emails until 7pm, 30 minutes later than you wanted. And if you set the cut-off time to 45 minutes before the show, the emails wouldn't have sent at all, because when the process checked at 7pm it would have already been past the cut-off time.
Now, the Automated Communications process checks for eligible emails to send every five minutes, vastly improving the system's ability to send out pre- and post-show emails as and when you expect.
Previously, Discount Codes that used the "Single Transaction Limit" and/or "Minimum Number of Tickets" configuration options weren't compatible with subscription packages because of the way subscriptions handled quantity.
Now, both options are compatible with subscriptions! This means you can (for example) set up a Discount Code, associate it with your subscription packages, and have it only work if the patron buys two or more subscriptions.
The PatronManager barcode scanning Android app was recently updated to version 47.2. This update includes a bug fix related to the error message that appears when you scan a valid ticket for a different Event, as well as under the hood adjustments to maintain compliance with Google Play Store policies.
If you scan tickets, be sure to enable automatic updates for the app so that you don't miss anything new!
A recent bug caused you to land on the completed Ticket Order after qualifying a new buyer from the Unqualified Contacts tab, resulting in extra clicks to qualify the next patron.
Now, completing a qualification from the Unqualified Contacts tab lands you back on that tab (as in the past), so that you can continue qualifying and keep your data clean!
That's all for this release!
Want to be part of the product development process? Log in to the Client Community to suggest and vote on Product Ideas, track suggestions your organization has given us in the past, see what's planned and in progress, and much more. Read All About Product Ideas to get started!
