In the process of converting over from Raiser’s Edge to Common Ground, we’re having to make certain configuration decisions that will allow the new system to match our processes and reporting requirements. Periodically, I’ll share some of those decisions and some of the background behind them, plus any interesting concepts they may expose.
Multi-year grants and donations are key weapons in the battle for renewable and reliable revenue for a non-profit. They provide stability to future budget projections, show commitment by funders to the ongoing future operations of the organization and are generally a good thing. As with all major gifts or grants, however, these opportunities require a cultivation cycle and development teams want to be able to track the activities and progress of a proposal over time.
When we record multi-year opportunities, we want to associate the cashflows with the annual campaign in which we expect to receive the revenue, and a significant part of our revenue reporting is based around this. So if I have a $3 million grant which will be paid out over 3 successive years, I need to be able to record the revenue across 3 different campaigns. Additionally, prior to the grant being won, we discount the amount of the proposal based on the stage that it’s in (we use a subset of the default Stage values), and report off of the Expected Amount field. As the proposal moves through the cultivation cycle, we change the stage and expect the revenue reporting to reflect the updated stage. Additionally, we want to associate each cashflow with the appropriate gift designations and solicitors in order to credit them properly.
All of this seems straightforward enough, but as we started to configure Salesforce and Common Ground, we ran into a bit of a road-block: Common Ground (or Salesforce itself for that matter) doesn’t readily support multiyear opportunities in a fashion which would allow us to update the proposal record as a single entity, yet report on our cashflows in the fiscal year (campaigns) in which we need to. I should note that Raiser’s Edge doesn’t do a particularly good job of dealing with this issue, but we had a solution in place that worked for reporting and used the native RE proposal functionality for managing the actual data.
We looked at a couple of options before settling on our current plan, with an ideal solution being simple for end-users to understand and with a minimum of customization:
- Record all multi-year donations as Pledges and use the native Common Ground Pledge and Pledge Installment functionality to create our child opportunities. Common Ground has a pretty cool add-in (build in Flash/Flex) to set up future pledge payments, and this would satisfy our requirement to manage dates and commentary on one record (the Pledge) and report on revenue on multiple records (the Pledge Installments, which are Opportunity records). Unfortunately, there would still be no way to record changes on the Pledge record and have those propagate to the Installments, meaning that staff would need to update both the Pledge and Installment records, and would have to know when to use the Pledge tab vs the Opportunity tab when entering data. Additionally, it would add to user confusion with real pledges.
- Create a new custom object (Proposal) which would capture the summary type information and commentary. This would eliminate some of the confusion about where to record proposals, but would lose the functionality of automatically creating the future cashflows (users would need to create the Opportunity records manually) and would still have the issue of requiring multiple updates to different records (which is almost guaranteed to result in some records being missed). Additionally, extra fields would need to be created to support the grants management process (which already exist on the Opportunity record with the installation of Common Ground).
- Use the native Opportunity creation process to create each individual cashflow record and update their data as necessary. Although this option would use the most native functionality and would have the least customization, it was probably the least palatable option, as we’d lose much of the proposal management benefit that we’re looking to achieve with our migration.
There were certainly other alternatives available, most being variations on the options outlined above. As we looked at the options, we had to weigh making procedures simple for our end-users against minimizing custom functionality and, based on our internal capabilities, have agreed that we’re willing to take on some additional customization in the hope of improving user adoption of the system when we go live.
In assessing our choices, we kept coming back to the need to manage the proposal as a single entity, yet have the cashflow opportunities related in some fashion to the proposal (and ideally have changes in the parent reflected on the child(ren). In Salesforce.com terms, this would be reflected as a lookup relationship between the parent and child.
This relationship already exists between the Pledge object and the Opportunity, and would be easy to implement between the Opportunity and another custom object (such as a Proposal object) , so could easily be accomodated for options 1 and 2 above. Option 3 would seem to be somewhat more complicated, as it requires a lookup to another opportunity (called a recursive relationship in data modeling terms). In traditional database development, working with recursive relationships can be somewhat painful, but in Salesforce.com, they are no different than any other lookup. You simply define the field type, pick the object you’re looking up, define the relationship name and how it appears as related lists, and you’re done. Creating these relationships is an important first step, as it allows an easy way for an end-user to gain access to the child records from the parent or to the parent from one of the children.
Given that we can easily create the recursive relationship between Opportunities, option 3 moved to the front of the queue when it came to evaluating ease of use for our users. They would be able to always go to the Donations tab (the Opportunities tab is renamed to Donations by Common Ground) for any proposal or donation with the exception of Pledges (which is as intended by Convio). They would still have to create each of the cashflow Opportunities and assign them to the correct Campaigns, but through the magic of the Salesforce Clone option, they can easily create the year 1 option and then clone it for each subsequent year and maintain the donor contact relationships and designations through the cloning process. The only value that needs to be changed between the first and any subsequent records is the Campaign, which simplifies the process significantly.
Finally, we want to be able to to update certain fields on the the child opportunity records when the parent is updated (particularly stage name and probability). Doing this required some simple code, but given that we already have the relationship between the parent and child records in place, doing an update is very easy. This update could easily be written as a trigger, but we’ve decided to implement it initially as Apex code that will be called by the end user from a button on the Opportunity record. If we find that we’ve got issues down the line with users not doing the update, we could either change the code to a trigger, or set up a scheduled batch to do the update on a regular basis. Additionally, we can also look into a process to create the child cashflow opportunities in a more automated fashion (a simple VisualForce page would accomplish the job), but as mentioned above, we’re trying to find the balance between simplicity/maintainability and ease of use.
Some key points to be drawn from this?
- Flexibility of the Salesforce model allows us to adapt the system to our needs using one of a number of approaches.
- We can adjust our solutions over time to respond to usage patterns or changing requirements
- Maintain the balance between over-automating and ease of use, particularly when launching something new – too much automation puts you and your technical team as a bottleneck in the event that things change, whereas users will tell you where their pain points are.
How are your organizations handling multi-year opportunities? I’d love to hear what you’ve come up with.