More flexibility when setting up Donations forms in regards to donors

@Julie Witte:

Hi there,

Is it possible to set up more rules within donation forms to allocate different constituent codes to new donors eg. If you have a donor that donates over $5k you apply the constituency code Major Donor or Coporate for and organisation. Also currently you can only seem to default everything to one constituent code so if another donor comes through and is does not have that constituency code that is the defaulted one it applies the defaulted one which is very annoying and frustrating especially if you receive a lot of online donations that day.

There is no conditional logic to this unfortunately. I do want to respond to the use of constituent codes that are related to giving, however.

In my experience, whenever a constituent code is correlated to giving, it is wrong. For example, someone is coded as a major donor but hasn't given in 5+ years. Would you still consider them a major donor? I've seen the same thing with “sustainer” or “recurring” giving. Someone has a constituent code for one of those options, and no longer is actively giving. In each of those cases, I have also found people who are currently giving at a major donor level, or currently have an active recurring donation and do not have the constituent code in place.

Some organizations are REALLY good at keeping both pieces of data updated, but that is creating extra work to manage the codes. Is anyone really wanting to do extra work right now?? Probably not. You can always query to see who is giving at a major donor level, or who has an active recurring gift, and your query will be correct. No worries about missing people because you are querying only on a constituent code.

Karen

@Julie Witte First I want to tell you that what you asking for is very unlikely to be done by Blackbaud, you can try Idea bank, but there are a LOT more business rule that's individual client specific that creating this functionality will be difficult. However, as it is “YOUR” org's business logic, you can (IF you want or IF your org has someone with the expertise) create this logic using SKY API and Power Automate (or any other work flow automation tool out there). You can automate a nightly update that takes the current gift details on the constituent and assign/update/remove code as needed.

@Karen Diener
I am neither for or against specific to keeping “code” (or custom field) for purpose of giving related tagging. It has its pro and con.

Running a report (likely more possible on database view, depending on how “complex” the tagging is) is the most “updated” way to know who is in what giving group. Without the need to keep a “field” (constituent code or custom field) up to date to the ever changing gift details.

However, the opposite side of the coin is, fundraiser does not want to (nor is it Blackbaud's suggestion to) go into database view. More fundraiser will be using webview rather than both. Then there's the “report” on webview, which is still lacklustered. Even when Blackbaud “perfect” the reporting, then there is still the “need to run report” first before you know if a certain donor is what “kind/category” of donor. We have business requirements that want fundraiser to “simply go fundraise”. They look at a donor page on webview and be able to know everything about the donor without needing to “calucate” (looking at gift history tile and summing up giving info and remember what the giving total equates to in category, etc), or run a report, and search for the donor in the report (or download into excel and filter to find). This kind of requirement will need the information right in front of the fundraiser face when they open the constituent record.

Blackbaud will unlikely allow customization of “tag”. So having org-specific tag means storing that tag somewhere else (constituent code or custom field) which needs to be updated.. manually… or through workflow automation.

To do this “nightly” isn't a particularly hard thing to do, even manually. Setup constituent query that looks at “individual” gift or summary of gift, and use that query to do global change. Will need 1 query and global change setup for each code type though.

The better way but need either need someone in your team or the expertise or resource from Blackbaud partner ($$$ cost) is to setup a work flow automation that runs nightly. (hmm sounds like a good Power Automate flow I can create and share on community, another on the list to post…)

@Karen Diener
I don't disagree with you, size of org and how many constituent record will affect business needs. As well as leadership and fundraiser's capability within the system. Also depends on the database admin appetite and potential existing experience that helps move things forward.

My replies on this (or any other replies that you have seen before) is merely giving the option and to let people know there are options exist, unlike the old RE legacy database view. An option that will greatly improve usability and remove constaints of the platform. However, the option is not for every one/org, and I try to states that too.