Salesforce licensing is complex and confusing. From my experience the majority of clients are using the platform for – well, sales. It wouldn’t make much sense to deny your sales representatives all of the phenomenal sales force automation features, and access to these features requires the full Salesforce license.
Non-profits get an incredible discount – instead of $125 per month per license, the price tag is about $30 per month. While I could easily justify this cost, it simply doesn’t go over well with small non-profits, or for that matter small businesses in general.
The initial negative reaction I received is understandable. This is supposedly a “free” offering, and during the honeymoon phase 10 user licenses sound like plenty. Furthermore, it is not uncommon for organizations to share user names and have everyone log in with the same accounts.
According to the Salesforce Master Subscription Agreement the sharing of passwords is forbidden. Section 4.2 states:
Unless otherwise specified, (a) a quantity in an Order Form refers to Users, and the Service or Content may not be accessed by more than that number of Users, (b) a User’s password may not be shared with any other individual, and (c) except as set forth in an Order Form, a User identification may only be reassigned to a new individual replacing one who will no longer use the Service or Content.
If the organization is not convinced that individual licenses are necessary due to contractual obligations, look at the other benefits discussed here. In my search for clarity on these licensing issues, I discovered an excellent chart that determines the appropriate license for each user.
Here’s the challenge with non-profits: volunteers. Unlike a typical business with a fairly fixed number of employees and relatively low turnover, non-profits are completely dependent on a large group of people willing to donate small amounts of time. Even the Salesforce representatives have told me directly that it is not uncommon for volunteers sharing a role to use the same user name.
While this is far from ideal, it is impractical for a small food bank with hundreds of volunteers to maintain a license for each volunteer. Cost aside, the management of these accounts would be a nightmare.
Recall that a full license comes out to $360 per year. If 100 volunteers had licenses, we are looking at a $36,000 per year price tag for a struggling food bank!
Fortunately, there is no need to get the full license. Two other licenses are much more cost effective and allow the organization to get much closer to full license coverage.
Chatter Plus: regularly $15/month, the non-profit price is $3/month or $36/year.
Force.com Enterprise App: regularly $25/month, the non-profit price is $5/month or $60/year.
Both allow access accounts and contacts, and up to 10 custom objects. The Chatter Plus license does not allow the user to edit accounts or contacts.
Let’s assume that the organization purchases 100 Chatter Plus licenses. The annual cost is now $3,600, which I believe is not only extremely reasonable, but the productivity gained will very likely translate into lower operating costs and higher donations.
How it Impacts the Design
Although I am writing this more for the consultant, let me explain objects for everyone else. An object stores particular data. Accounts store information on households and businesses. Contacts store information about the people associated with those households and businesses. Donations represent information on something that was donated. Each of these translates into an object.
Salesforce provides standard objects such as accounts and contacts. The non-profit starter pack adds others. A custom object is one that is created just for your organization. These limited licenses do not prohibit you from creating lots of custom objects – it simply forces you to limit a particular user’s access to no more than ten.
This limited licensing fits the typical non-profit very well. Most volunteers have specific roles. One may work in client intake, and another may receive donations. It is unlikely with a well-designed implementation for any volunteer to require access to even five or six custom objects.
As this blog series unfolds, you will discover that these limitations governed the very essence of my design and led me to propose some novel solutions that I hope will be applicable to other situations.