The Basics of Salesforce.com Reporting [Tech Tips]

 

If your organization is new to its Salesforce.com-based fundraising App, your staff members may find themselves initially frustrated when trying to extract reports — and then overwhelm your system administrator with requests for reports instead of extracting them on their own.

To help staff members become more comfortable running reports, it’s a good idea to provide them with a basic education of the Salesforce.com data model. This post covers some of the basics of Salesforce.com design and report creation to get you started.

Salesforce Structure

Once you understand the structure of your data in Salesforce, you’ll really start to understand what is possible in the system.

For example:

Objects

The first idea to understand is the basic nature of objects. Objects are the tables in which data is stored. Essentially, an object is a collection of records of a particular type, such as:

  • Accounts
  • Contacts
  • Opportunities
  • Campaigns
  • Activities
  • Contact Roles Etc., including custom objects, which may be part of your App or may be created by your organization for your own purposes

Relationships

Objects in Salesforce can be related by using two types of fields: Lookup and Master Detail. These two field types support the various types of relationships that objects can have with each other: One-to-one (one object can have a relationship with only one of the other objects)

  • One-to-many
  • Many-to-one
  • and many-to-many relationships.

 

The diagram below shows how some standard Objects are related to each other. The “n:1” or “1:n” notations describe whether the relationship is many-to-one or one-to-many, respectively.

One of the most common ways for an Object to be related to one or more other objects is via a Lookup field, which creates a Related List on each object. Related Lists are a good clue as to how Objects are interrelated.

A Master-Detail relationship between objects means that the Master object controls some behaviors of the “child” or “detail” object.

These relationships between Objects influence both what you see on page layouts and what you can report on.

Report Types

Every report in Salesforce.com is based on a certain Report Type. This Report Type dictates what kind of data is included. For example, the Report Type “Accounts and Contacts” can only display Accounts and Contacts. (Note: This is oversimplified slightly for the purposes of this article.)

There are two basic boundaries for reporting in Salesforce.com:

  • All Objects included in a Report Type must be linked either directly or indirectly.
  • You cannot include more than four Objects in a Report Type.

Salesforce.com comes with many Report Types already set up. If there is not a standard report available that meets your needs, you can create a Custom Report Type by going to Setup > App Setup > Create > Report Types.

Put It All Together

Objects must be linked in a very specific way to be included in the same Report Type.

Imagine that Objects are linked together like a chain. The Primary Object is the first link in the chain. The Secondary Object must be linked directly to the Primary Object, and so on if there is a third and fourth Object (remember, the maximum number of Objects that can be included in a report is four).

In the screen shot below of the custom report creation process, you can see that only Objects that have a direct relationship to Opportunities can be selected as the third object in this report type.

Conclusion

Until you understand the design of your organization’s Salesforce.com-based system and how to make smart use of Report Types, your system administrator is likely to be overwhelmed with requests for reports, and users could become frustrated. Not only will this lead to a bottleneck, but it could also lead to an undesirable dependence on system administrators.

We recommend that if you are considering a transition to a Salesforce.com-based App that you address reporting sooner rather than later:

  • Actively learn about the Salesforce.com data model.
  • Participate in the design of your donor management system to make sure that the necessary Object relationships are in place.
  • Learn how to use workarounds such as cross-object formulas to help fill the gaps.

Do you have insight to add?  Please contribute to this article in the comments section below.

Read more Tech Tips>

About the Coauthor:

Anita Sakhuja is a consultant at Heller Consulting with four years of experience in information technology and services. Anita has worked with both for-profits and nonprofits on successful implementations of Salesforce.com. After migrating to the U.S., Anita volunteered at a nonprofit organization, implementing Salesforce.com to manage their donations and volunteers. Working on the Heller Consulting team now provides Anita with opportunities to continue to make a difference in our community by using her technical expertise. Her work includes developing information flow management between multiple systems; supporting the deployment and configuration of Common Ground, Salesforce, and other systems; and creating and documenting processes for clients. Anita holds a bachelor’s degree in Electronics Engineering and a master of business administration degree in HR-IT. Anita is a Salesforce.com Certified Administrator and a Certified Developer.

About

The Connected Cause is a place for experts in the nonprofit online space to share perspective, offer guidance and promote best practices for using today’s technology effectively. Our goal is to provide a comprehensive source of collaborative thought leadership for the nonprofit industry.

One comment

  1. Lauren

    Brilliant! Thank you so much for this post. I am new to SF and have been trying to wrap my head around the data model (coming from Raiser’s Edge).

Leave a Reply

Your email address will not be published. Required fields are marked *