Nonprofits love when volunteers sign up and engage with the organization. When using Volunteers for Salesforce this is accomplished through the sign up form that allows sign ups to flow from the online form directly into Salesforce. It is therefore important to protect the quality of the incoming data and make sure it is humans signing up and not bots.
This article will show how to enhance the Volunteers for Salesforce Signup page with CAPTCHA using very little customization.
Please keep in mind that the Volunteers for Salesforce Sign Up page is part of the managed package Volunteers for Salesforce so in order to add the CAPTCHA some coding will be needed.
Most organizations start out with 1GB of storage for Salesforce CRM. This can be a challenge especially for nonprofits who would like to collect a lot of data needed to report to their funders, collect program data or consolidate multiple aspects of their business data into Salesforce. Over time the data fills up the allotted storage and puts organizations into a bind to either purge data or purchase more storage.
Over the years we have explored different solutions that can be used as preventive measures and limit the storage used. The traditional approach is to either export and archive or aggregate and purge older records. The drawback with these solutions is that you can no longer see the details of the historical data in Salesforce.
Below we describe a different preventive approach inspired from document-oriented databases that allows organizations to keep their data and not run the risk of running out of storage.
Use Case: Volunteers for Salesforce
Some Salesforce managed packages provide developers in the community the opportunity to contribute with code and features. Packages such as the Non Profit Starter Pack or Volunteers for Salesforce are open source software, which means developers can contribute to the code on GitHub (https://github.com/) resulting into new features or improvements to the software. These features are then packaged into the managed version being upgraded.
University of New Hampshire engaged Daizy Logik to develop several enhancements to Volunteers for Salesforce that were then incorporated back into the package. Based on this work we developed this step-by-step technical guide on how to successfully contribute to an open source Salesforce managed package. The process described here uses Volunteers for Salesforce as an example but could be more generally applied to any open source managed package.
Development Environment Setup
To facilitate the setup of your development environment we recommend using these freely available utilities that should be available on both Mac and PC.
Creating a Patch for a Managed Package and Doing a Push Upgrade
Posted by Nineta Martinov
Recently I had to create a Patch for one of my clients’ managed package in order to make a minor change and push it out to all the client organizations using the package. For the most part the Salesforce documentation is fairly accurate in guiding one through the process. However, I could not find any help with screenshots documenting the end-to-end process so I put this together.
Remember that a Patch should only be created if no new components are being added to the managed package. For example, if you want to change the wording in a Visualforce page you would want to use a Patch.
Step1. Log into the main development org. This is where you developed the managed package. Go to Create -> Packages and click on the Managed package name.
If you have asked yourself this question recently here are some tips that can help you decide which path you should take. Imagine you have to implement the following scenario:
Use Case: Users are signing up online and filling out a form. They have to provide contact information for 4 additional Contacts at their organizations. For each additional Contact they will enter a First Name, Last Name, Email, Phone and Role. All this information will be automatically fed to Salesforce in the form of an online subscription record.
For each additional Contact you are required to first determine if it exists in Salesforce and if not then create it. If you find the contact in Salesforce (based on Last Name and Email) then you have to update the Phone, set the mailing address and create an Affiliation to the Account/Organization with the specified role.
(Please note that this use case uses Affiliations which are a custom object specific to the SF Non Profit Starter Pack. An Affiliation is a junction object between a Contact and an Account.)
The PROCESS BUILDER AND FLOW ROUTE
It is possible to go the process builder route for this one.
In many instances, the data to be migrated in Salesforce is simple enough that it can be imported with a tool like Jitterbit or the Salesforce Data Import Wizard.
There are some situations though, when the migration might be difficult or cumbersome to implement with one of these tools. It’s likely that in these cases developing an application will be more cost-effective than the standard approach.
Here are a few cases when a Salesforce developer should create an application to process the data import by using Visualforce and Apex:
Some non-profits want to rollup pledges (donations with StageName=’Pledged’). NPSP provides user-defined rollups for ‘Posted’ donations.
Daizylogik has built an unmanaged package for Pledge Rollups on Accounts and Contacts for the current and previous calendar and fiscal years. It also, rolls up the Payments for pledges.
You can install it from here:
The source code is available here: https://github.com/daizylogik/DZ_DEV.git
Post Installation Instructions:
1. add the following fields to the Account and Contact page layout:
2. Edit the Search Layout for the Opportunities, and the add the Calculate Pledge Totals button, so you can run the rollups on demand.
3. If you would like to schedule the rollup job, use the PledgeRollupBatch class.
by Vladimir Martinov