Managing Blackbaud CRM™ Requests: A Step-By-Step Decision-Making Guide

By Bethany Avery, Director and Amanda Cose, Principal Consultant

When working with multiple stakeholders and varying expectations, it can be overwhelming to approach the various requests to modify your Blackbaud CRM™ environment. In general, it is helpful to organize these Blackbaud CRM™ user interface and user experience requests into three categories:

• Training

• Configuration

• Customization

Of these three, the easiest to address is training. What makes something a good candidate for training? Consider the following:

• Is there a feasible, available solution (or work-around solution) to accomplish the request?

If you answer yes to this question, it is likely a training issue. Consider supplemental support if the answer is yes, but the team is not widely versed in how to use the solutions. Materials, time, repetition, and contextual explanations can all deepen understanding and increase end users’ assessment of feasibility. 

If you answer no, the next thing to consider is if the request/issue can be accommodated with configuration. Configuration generally means that the desired functionality can either be created from the front end (and therefore does not require custom development), or, is already available in Blackbaud CRM™ but not yet used. 

If training and configuration have been ruled out as options using the guidelines above, the next option is customization. A customization is a feature, extension or modification of Blackbaud CRM™ that requires custom coding. Customization is powerful, but also requires more effort, expertise and risk since each customization introduces some level of technical debt. Below are best practices to keep in mind when planning for and determining if a particular customization is recommended.

1. In general, avoid altering standard functionality (or core product code) where possible

• Altering code product code would be things such as altering business processes, changing system-defined dropdown values, etc.

• Altered core product code is not typically upgrade compatible, meaning new enhancements to that area will not be available, and can also make the area unsupported by Blackbaud Support

• Replaced forms, while upgrade safe, may still need to be revisited if Blackbaud makes a core change to the artifacts that were replaced

1. Instead of altering core product code, opt to extend or replace

• Extension is the safest approach; it is simple to maintain and easy to upgrade

• For example, adding new query fields and sub-nodes is a common extension request

• Replacing is better than altering, but more time consuming than extending since developers need to extract the core code since we do not own it. 

• For example, replacing a specific add form with a custom add form would be a replacement request

1. The following are things that should be considered and planned for with any customization:

• Regression testing - what other processes does this change touch that will need to be retested?

• Technical debt - will changes now make supporting any part of the application more difficult in the future?

• Upgrade compatibility - is the change upgrade safe when the organization is ready to apply the next Service Pack or version?

• Deployment planning - how will this change be rolled out to users from an application perspective?

• Performance - how will the overall performance of the application be impacted? 

• Mission critical functionality (batch, GL, etc.) - does the customization introduce change to mission critical processes such as revenue processing; is reward worth risk if so?

• Volume of dependencies - is the customization in an area with many interrelated pieces of functionality? If so, a change in one may necessitate a change to many.