From time to time, our consultants put together posts about technology issues, how-tos or best practices. This post comes from Patrick, our Senior Database and Online Services Consultant, he spends much of his day working with clients to help customize, implement and learn Salesforce databases. In this post, Patrick discusses common issues that can arise for organizations seeking further customization.

So You Want to Install a New Salesforce App?

Salesforce has become a popular database solution in the nonprofit community, in part because of the ability to extend the platform with add-on apps. While these apps come with the promise of a quick and often-times free way to improve your organization’s database, installation does not always come without consequence. Here we discuss the background of this problem and include some steps to ensuring a safe app installation.

Background

Salesforce has been a popular platform for nonprofit database and Constituent Relationship Management (CRM) use for several years running now - and for good reason. In addition to the power and accessibility offered by this cloud-based product, the platform allows for almost limitless customization and extension to suit the individual needs of the organizations that use it. This is one of the biggest factors contributing to the success of Salesforce - designed and primarily as a sales database - in the world of nonprofit management of constituents, donor relationships, and programs.

Extending the base capability of Salesforce comes in two basic forms - customizations applied directly to an individual instance (the installation of Salesforce used by a specific org), and apps available from the Salesforce app exchange, where over 1,000 apps are available for free or license. A life-cycle for apps has developed - a set of customizations for a single purpose emerges through a handful of individual custom installs before being packaged as an app and made available on the app exchange. Templates such as the nonprofit starter pack are a special variation of app, in that it is actually a collection of five related apps.

The Problem

The first step to installing a new app into your Salesforce instance is careful research to ensure the app fills the stated needs of your organization. However, problems with app installation mostly occur when previous customizations in your database duplicate the functionality of the app or template you wish to install. In other words, research about a new app needs to extend beyond the details of the app itself, and include the customizations or apps already installed on your Salesforce instance.

Let’s examine the case where an organization is interested in installing the Contacts and Organizations portion of the fantastic nonprofit starter pack, available (for free!) from the Salesforce Foundation. This app package, among other improvements specific to nonprofit usage, includes custom objects, fields, and triggers to support payments alongside opportunities.

Difficulties in this installation arise when an organization already has older and very separate customizations to support payments. These customizations may include a definition of a custom payment object that is distinct from (though similar to) the payment the template will attempt to provide. This could then cause duplicated triggers, which can lead to inaccurate reports. For example a new report would point to the new payment object, but old reports will ignore the new payments and include only information from previous payments.  Depending on the exact set of circumstances, a report might show no payment existing after the install of the new package - or else hide payment information before the date of package install. An even worse case scenario occurs when different users or process create a mix of old and new payments with neither providing a complete picture of the information, requiring a difficult and thorny migration to fix.

This scenario details just one small subset of the chaos that can be unleashed when installing an app or package on top of extant customization.

Solutions

First I should mention what is NOT a solution, which is to live in fear of the above scenario to the point of never following through with an add-on package or app. Apps and customizations are excellent opportunities to dramatically improve the efficiency and reach of your database and infrastructure. However, installing a new app or package should be approached with a degree of caution ESPECIALLY when you think the addition might duplicate a degree of functionality that already exists within your database. That said, there are several things you or your Salesforce administrator can do to help ensure that things will progress smoothly with your new app friend.

1. Consult with an expert

This can be someone on your staff, or if you have the resources, an outside consultant. Ideally this person needs to be familiar with your Salesforce instance and the background of your project. Additionally, if you have one of these packages installed currently and are looking to move to the Nonprofit Starter Pack it is very important to do a thorough examination because these packages contain similar apps to what eventually became the nonprofit starter pack.

• The “NPower template” or “The NPower DOT” if you worked with NPower Seattle / NPower Northwest
• “Groundwire Base” or “GW Base” or “The Groundwire Template” from Groundwire or ONE/Northwest
• Unmanaged versions of the nonprofit starter pack.

2. Installed Packages: What packages are installed already?

If you visit the “setup” section of your instance (the “setup” option available from the dropdown menu under your user name in the upper-right of your screen), there is an option under “App Setup” in the menu on the left of the screen called “Installed Packages”.

This will display a lot of very valuable information about what is installed in your Salesforce instance, who published it, and when it was installed. In this case (this is my personal developer instance), we see all the nonprofit starter packages (everything published by the Salesforce Foundation), the Eventbrite Sync product from Groundwire, and an unmanaged version of Action Plans from the Force.com labs that I can honestly admit I don’t remember installing (it happens to the best of us).

This should give you at least some information about what’s happening in the database, and also give you some leads on who to contact about possible negative interactions with the additional package you are considering.

3. Unmanaged Customizations

While this admittedly begins peeking into the darker warrens of Salesforce customization, it is an important place to check since any customizations outside of an installed app or managed package don’t show up on the “Installed Packages” list. Customizations can be Apex Pages, Apex Classes, and Custom Objects, but the latter are probably the most straightforward to predict possible conflicts with installed apps.

To view the custom objects in your instance, got to Setup -> Create -> Objects

This view gives us a little more insight into what’s going on in this instance, both with managed packages and unmanaged customizations. In this case we can see the affiliations, households, payments, reoccurring donations, and relationships that come along with the starter pack, plus some other miscellany.

Based off of the list of above we can see some possible conflicts between this current instance and a new app:

• a new app that included some language about payments, or households, in its documentation and feature list
• a new app that added objects and/or fields relating to these types (we need to think of how these might interact with the current objects)

If the new app or package duplicates objects already present in the database, you may need to develop a strategy about how to avoid difficulty moving forward, perhaps even migrating data from old objects to the ones provided by the new system, and cleaning up the old fields. This will likely take a careful approach and some time.

4. Fields on Standard or Custom Objects

Installed apps can add fields to standard objects, or in some cases custom objects that are part of a template. As with the previous item, we should be careful that these fields don’t duplicate fields already added to your system, as this could result in inconsistent reports, data jumbled between multiple fields, and could lead to a difficult migration or data cleanup situation.

To view current custom fields on a standard object like Contact, go to Setup -> Customize -> Contacts->Fields.

Custom fields appear in the second field list, below the standard fields that show at the top of this view. Scan the list of fields for names that might conflict with functionality that will be duplicated with the new application. For instance, Groundwire’s volunteer management app adds objects and fields to track volunteer hours on the Contact, but if your organization has already been tracking volunteers in Salesforce similar fields will likely already exist. Duplicate fields are likely to cause problems.

NOTE: Scanning the layout for visible fields is not as thorough as viewing the list in the setup area, as fields can be removed from layouts and different record types can have different fields visible.

5. Install the new package in a sandbox first

Salesforce provides “sandboxes” as quarantined test environments for just this purpose. Creating a sandbox (Setup->Data Management->Sandbox) gives you a separate playground with all the customizations from your main instance. This is a great way to pre-test packages, but since negative consequences of installing new packages don’t always show up until they have been put through the paces for quite some time, it’s still important to test thoroughly and carefully.

Conclusion or TL: DR* version

Going through these steps will help prevent a mess when installing an extension to your Salesforce instance:

1. Consult with an expert (either in-house or consultant)
2. View the list of currently installed packages
3. View the list of custom objects already present in your instance
4. View custom fields on the most important standard objects
5. Install the app in a sandbox first and test heavily

Remember, the process of installing new apps on your Saleforce instance is not something to fear, but to approach strategically and carefully. As always feel free to contact us at 501 Commons if you have any questions about customizing your Salesforce database or would like to learn more about our services. Or check out our Technology Knowledge Center for more information about choosing a database.

- Patrick Tewson

*Too Long, Didn't Read