It’s not possible to give a step-by-step detailed approach to setting up an organization. Frankly, it would be boring! My intent is to slip in a few things that will get you started faster and make everyone’s lives a bit easier.
Select the “Admin”
Creating the organization actually done before applying with Salesforce.org for non-profit status. This means that you get one shot at spinning up the environment and it is literally the first thing you must do. Whoever steps through this process is the one-and-only user until he adds other users.
Be very careful who is selected for this role. It should not be the head of the organization because she will have too many other responsibilities. This person must have some technical knowledge and have time to attend all of the planning sessions. In this case we selected a board member who I worked with in the past on other projects. I cannot emphasize enough that this person must also have enthusiasm for the project.
The Admin and the Executive are the cornerstone of your dream team. Pure and simple.
Create the Organization
Point the administrator to Salesforce.org, let them create the instance and be ready with the required documentation to apply for non-profit status. It should not take long to get a response from Salesforce and be assigned a representative.
As a consultant, it is easy to be left out of the mix. Get the sales representative’s contact information as soon as approval is received. Schedule a call with you, the admin and the representative. Be clear on your role and carefully state your experience. Make sure you understand the representative’s role and what she can provide.
Understanding the Environment
Each non-profit organization comes standard with the non-profit starter pack and both a production and sandbox environment. Of course, you will have no access to the environment until the admin creates a user account for you, and it is likely that the admin doesn’t even know how to do that.
Here is where you begin educating the admin. The better you school the admin in the basics, the less hassles you will encounter down the road.
Emails, Passwords and the Multi-Tenant Situation
As I consultant, I have many Salesforce user accounts. A user name may only be used once in the entire kingdom of Salesforce. Furthermore, Salesforce has fairly tight security and particularly in the beginning expect to be prompted to validate your logon with verification codes. An email address can be used multiple times. Since by default the Salesforce user name is in the format of an email address it is downright confusing.
Most people are not familiar with this and frankly it gets frustrating very quickly. Even with the protocols I am going to share with you, I still received many “I can’t log in” cries for help.
In the early stages nobody knows how many users there are ultimately going to be and what roles they will have. Don’t even bother spending time figuring this out. Furthermore, do not start entering “real” email addresses for your first group of users.
Gmail to the Rescue
There are two things I really like about Gmail: it’s free, and you can use “+” email addresses. If you are not familiar with this concept, let me show you a neat trick. Suppose my main email address is:
Now I need to assign a valid email to a new Salesforce user account for this project. Instead of using the above email, I type in this:
While this email does not exist, Gmail will strip out everything to the right of the plus symbol and route it to my regular account. I use this format for every one of my Salesforce user accounts. What I place to the right of the plus symbol matches the project, so I don’t forget email accounts!
The next step is to maintain control of all user accounts. I achieve this by creating a new Gmail account that is used for nothing more than receiving verification codes and resetting passwords. By taking control of this you receive all verification codes. Of course, provide the staff with access to this account as well. This gives them a central account through which all staff and volunteers can be managed.
Suppose we create this account:
Now we are ready to create users.
Start with Production
Have your admin log into production at login.salesforce.com. Point out the differences between then production and sandbox environments. Make it abundantly clear that while you love enthusiasm, this enthusiasm must never be unleashed in production, or for that matter, the sandbox. Encourage her to register for a free development environment and to take some Trailhead courses.
Help her navigate to Setup and add you as a user. Your new “+” email address should be used. Once saved, verify that you can login. Of course, please make sure the admin assigns you the System Administrator profile! Now you have control.
Create a New Profile
Right now you have used two of your 10 free licenses. While subsequent posts will delve more into licensing, at this stage we need to be protective of the remaining eight. Don’t expect the non-profit to purchase more licenses until the project is near completion. I decided to create only one more generic user account and assign it to a new profile.
I elected to clone the Standard User profile and call it Administration.
This is where the new Gmail account comes in handy. It’s better to keep things generic at this point instead of assigning the new user to a specific individual using his email address.
Use the new account for this generic admin user and assign it to the new profile. Don’t forget the “+” email:
Refresh the Sandbox
The default Sandbox was a duplicate of production until you added the users. You have a couple of options at this point. One option is to replicate the steps you just did in production, obeying the naming conventions for the sandbox users. The other is to refresh the sandbox, which in my opinion is much simpler. Salesforce provides good documentation on this.
In the figure below note that there are two sandboxes. The one named “Sandbox1” was created by default. The other we created as an extra “proof of concept” environment.
When the sandbox is refreshed it is an exact copy of production including the users.
The only difference is that the user name is appended with the name of the sandbox. Since the same user name cannot be used in two organizations, it must be unique. You can follow the same naming conventions to manually add users to both environments.
Verify you can log in to the sandbox through this URL test.salesforce.com. Remember to enter the modified user name. The password should be the same.
Now it’s time to do some clean-up.