We Would Like Your Feedback!

Pallavi Paranjape · June 2018

As mentioned during our last NetCommunity Roadmap Webinar in April, one of the enhancements planned for an upcoming release is revisiting how additional donations made in conjunction with an Event Registration using the Event Registration form are processed in the plugin. During discovery, you told us that the fact that these transactions result in split gifts in RE7 (Event Registration fee Donation) is not ideal. Keeping that feedback in mind, we are designing a solution that will separate the Donation and the Event Registration into two separate transactions – an Event Registration transaction and a Donation transaction. This will do away with the need to work with split gifts.

If you currently use this functionality, I would love to hear some additional feedback on how you would like to see this be enabled in BBNC –

No configuration option and new behavior is default – This means that the current functionality will change when your site is upgraded to the new version of NetCommunity and any Event Registrations with additional donations, originating from the Event Registration Form, with automatically be separated into an Event Registration Transaction and a Donation Transaction.
As a one-time configuration option that is disabled by default – This means that Event Registrations and additional donations, originating from the Event Registration form, will continue to generate one Event Registration transaction in the plugin until an admin goes in and enables the option to separate the transaction into two.
I don’t want to see this change at all. I prefer existing functionality.

Please take a moment to answer the poll and hit the comments if you any additional feedback!

Thanks for your feedback!

Pallavi Paranjape

Staff Product Manager - Blackbaud NetCommunity

Laura Furtado · June 2018

My vote is for option 1 - New behavior being the default.

Nora MacDonald · June 2018

1 - new behavior is default.

Elaine Tucker · June 2018

1. New behavior is default

Amelia Howerton · June 2018

1 - new behavior is default.

Eric Baerg · June 2018

Option 1

Michele Jenner · June 2018

option 1

Paula Trebra · June 2018

Option 1

David Larson · June 2018

As a one-time configuration option that is disabled by default. We will not use the new option.

Diane Pierce · June 2018

Option #1 - new behavior is the default.

Susie Trentham · June 2018

Do you have a link to the April Roadmap Webinar? I would like to be able to view it since I was unable to attend that Webinar.

Susie Trentham, strentham@cn.edu

Holly Salvona · June 2018

I've voted for option 2, as it being default behaviour might not suit everyone. It would also be good to be able to "correct" historical gifts that are linked to event registrations.

Pallavi Paranjape · June 2018

Here is a link to the April roadmap webinar if you wish review it again - https://community.blackbaud.com/blogs/66/4586

Rick Geyer · June 2018

My vote would be for number 2.

Barbara Folger · June 2018

Definitely option 1 - tickets aren't tax deductible, donations are. We need to treat the gifts differently. Thank you for gathering our feedback!

Graham Getty · June 2018

Option 2 - configuration option. We currently have a "fund" called "Event Registration Fees" to receive events where there is no additional donation component (and we typically don't add / allow an additional donation component due to the complexity. If the upgrade is going to split it I imagine / hope there will be two fields - one to specify the fund to receive Event Registration Fee and the other to receive the donation, right?

Kimm Bailey · June 2018

Option 1

Susan Walters · June 2018

Option 2. I'd want to be able to test the functionality, and change back if it doesn't suit our needs.

Courtney Cobb · June 2018

Option 1 with transactions automatically separating out to a Event Registration Transaction and a Donation Transaction. Not sure if this is a given, but with the ability to make sure the Event registration transaction and the donation transaction can process from two separate Merchant Service accounts.

Maya Francis · June 2018

Option 1 - being the default

Ron Steiner · June 2018

New functionality should never be forced upon existing users, even if it a desired new behavior. Any new functionality should be available by configuration and should be OFF by default, only turned on if/when the user decides to turn it on. This guiding principle allows for timely communication of the new feature, proper testing in test environments, and training for those affected.

Crystal Chouinard · June 2018

Option number 1 for sure. Just yesterday we were struggling with a split gift that came through and was locking the batch. Took us a few minutes to remember what the issue was.

Samantha Robertson · June 2018

Option 1

Ashley Webster · June 2018

Option #1.

Amber Gichard · June 2018

1. New behavior is default!

Karm K · June 2018

Option one please (No configuration option and new behaviour is default ).

Sandy Dedinas Thomas · June 2018

Option 1 please! Don't forget to actually answer the poll up in the top right.

Christopher Blitz · June 2018

I would vote for #2. The opportunity to make that change is better in my mind then being forced into something whether you like it or not. I've found that options are usually the best way to go.

Edward Hohlbein · June 2018

Option #1

Chris DeMaster · June 2018

1. new behavior is default.

Jim Fields · June 2018

Thanks for asking us, Pallavi! I believe that option 2 (one-time configuration) will be the most helpful. If I understand it correctly option 2 will allow users to take more control and use the setup that best meets their needs. If I misunderstand that someone please correct me!

We Would Like Your Feedback!

Comments

Categories