Design and Build a Sustainable Solution as a Pro Bono Volunteer
Learning Objectives
After completing this unit, you’ll be able to:
- Apply good solution design principles.
- Build a solution your organization can sustain.
It’s All About Sustainability
By now, you’re probably feeling pretty good about how to use your Salesforce powers for good. But, if there’s one weakness that many pro bono superheroes have in common, it’s this: they build solutions that aren’t sustainable by their organization.
It’s your responsibility to recommend solutions that meet the specific needs and use cases of your organization and are sustainable by the organization in the long run. Even simple automations can be unsustainable if the organization doesn’t understand what's happening behind the scenes or can't make adjustments if something breaks. Remember, your nonprofit customer will need to be able to maintain your solution once your project is complete.
Start With Good Design
A good first step toward building a sustainable solution is documenting your recommendations and reviewing them with your organization before you begin to build. Make sure they understand what you’re recommending and why, and agree on a plan for enabling the organization to maintain the solution once you’re gone.
Keep the following in mind when you’re putting together your recommendation:
- Emphasize the customer’s role in sustaining the solution after you’re gone.
- Recommend out-of-the-box objects and features whenever possible.
- Think twice about custom development and complex workflow automation.
- Teach your organization what you’re doing as you build.
Apply Builder Best Practices
Once your organization approves your recommendations, you can start building the solution. As you construct it, remember these best practices:
Always make changes in a sandbox
We know it’s tempting to build solutions directly in a production environment, especially when you need to test with the customer’s existing data, and the customer doesn’t have a full sandbox available. However, mistakes can disrupt business and potentially make changes that cannot be undone.
By building your solution in a sandbox, you ensure that you don’t leave your nonprofit in a worse place than when you began. Remember to request a new sandbox or a refresh to an existing sandbox before you begin.
Enterprise Edition Salesforce includes a partial sandbox; this should be used for testing in cases where using the customer’s existing data is necessary. You may need to assist your nonprofit customer in creating a sandbox template to select which data to copy.
Keep it simple, superhero (KISS)
Jimmy Hua, Lead Software Engineer, Salesforce: “We have so much cool technology. But if the organization’s not ready for a product like Einstein, don't spend time on something they can't use.”
As you build, always keep in mind that simpler is better. Your goal is to create a sustainable solution that your organization understands and can maintain. Ideally, you’ll build your solution using declarative programming (click, not code!), so that a Salesforce administrator can easily make updates if requirements change down the line.
Be ready for changes
You may find while building that you need clarification on requirements, which ultimately requires a change to what you’ve designed. Checking in with the customer regularly will help you identify these changes quickly and efficiently. Your job is to be flexible, within limits, and to identify when requirements become out of scope so you can adjust the priorities or timeline.
Build with your organization
When appropriate, show the customer what you’re doing in their org and then have them do some of the work themselves! This will enable the customer to maintain what you’ve done after the project. With extra hands, you might be able to get more done than you thought! Just be sure to check the customer’s work and coach the customer through any mistakes they make.
Document as you go
Write down what you build from both a technical and functional standpoint, so that anyone can understand and keep building upon the solution you put in place. Documenting as you go saves you time in the long run, and also ensures that you have something to hand off at the end of the project. Remember to update the documentation after testing is complete.
Test, test, test!
Everything you build should be tested by both you and your organization in a sandbox before deployment. Be sure to test the requirements that you defined for each user story. If you see failures, adjust and re-test.
For example, let’s say that you used your Salesforce superpowers to set up an automated email to acknowledge a donor anytime an opportunity record is created for a donation that was received. You’ll want to confirm that the automation is functioning properly by creating an opportunity record for a test donation and confirming that it was delivered and formatted properly. Simply use your email address for the test!
Depending on the complexity of what you implement, consider using a test script that both you and the customer can refer to. Check out our Resource Guide for Pro Bono Volunteers for a sample script.
In most cases, you will want to walk the customer through the solution you built before handing it over for them to test. You should be prepared to demo, train, and answer any questions before you ask the customer to test your work.