DISH: Many organizations use external forms to acquire new constituents, program prospects, donors and the like. NPSP uses affiliations to store contact to account relationships but auto-creating new accounts and affiliations could create more duplicate accounts than anyone is ready to manage.

WHY THIS MATTERS: Knowing external org affiliations is powerful and generally your users know which connections are important and which are not. A system that users cannot trust is not going to be well adopted.

Enter “Calculated text value for primary affiliation. External integrations will update the PAff_txt field , when an actual primary affiliation is added it will replace the name in the calculation” on Description

Enter “This is a text representation of either an external web form entered by the actual contact or the account name of the primary affiliation.” on Help Text

Now map your integrated form to the Hidden Text Org Affiliation field where you’re asking for an employer/university etc.

SERVE: Test your solution with your integrated form. You may also want to adjust the visibility on the Hidden Text Org Affiliation field so users can see it in reports to manage overall data quality.

Scenario 1: If the Hidden Text Org Affiliation field is filled out but no Primary Affiliation exists the value of Hidden Text Org Affiliation appears with “-Unverified” in the Primary Affiliation (Text) field.

Scenario 2: If the Hidden Text Org Affiliation field is blank and no Primary Affiliation exists the value of Hidden Text Org Affiliation appears as “Unknown-Unverified” in the Primary Affiliation (Text) field.

Scenario 3: If the Primary Affiliation exists Hidden Text Org Affiliation field is ignored and no the value of Primary Affiliation appears in the Primary Affiliation (Text) field.

RISK LEVEL: Medium, if form data is constantly conflicting with affiliation data you may need to take additional steps (Post Coming Soon) to determine which is more recent and more relevant. For example if a new form was filled out with a newer Hidden Text Org Affiliation value you may want to put things in place to prompt a user to view and update the affiliation history. This can be combined with general Affiliation Verification methods (Post Coming Soon)

DISH: NPSP has an affiliation status field, but it demands that you update it along with the end date. Assuming you do not have an interim status like “On Extended Leave” you may as well automate that field with a workflow.

WHY THIS MATTERS: It is unnecessary to force users to enter 2 fields when they only need to enter one. Data quality will suffer if we see that users have an end date but are also current affiliations.

SOLUTION: When the end date is entered a workflow will update the status field as “Former” and uncheck the primary indicator, if the end date is erased the status field will return the status field to “Current.”

You want to be careful with using affiliations to record everything that relates a contact and an organization. While having structured relational data has powerful potential, it can create complexity you don’t need. In some cases, relationships would be better handled by a field update or even a note.

Examples where affiliations may be overdoing it:

You only participate in grassroots fundraising and the employers of your funders is unimportant or too much data to be worth managing

Your program is not centered around individuals, where they work or a need to leverage those extra accounts

There are a very limited number of possibilities for account relationships

A picklist of 4 possible unions is quicker and easier to manage

You only care about the level of degree achieved not the actual volume of graduates from a particular school

Managing account data, especially duplicate accounts is too risky at this time

You want to be very careful about how much data storage you are using, you may already use the org to contact model rather than the household model for this reason

Assuming you’ve thought about all that and you feel it’s important to record at least some of the information using affiliations, decide on a design for customizing the affiliation record. Salesforce and NPSP offer a lot of power and customization, but always make sure your focused on what’s critical to your outcomes vs what looks like a cool design or covers every odd scenario.

It’s always best to diagram your model out and share it with your business teams. Be sure you and each business team are challenging each other to capture critical information in a structured (report-able) way while balancing the capacity for data entry and system training.

Here are some suggestions:

Type: If you’re categorizing affiliations broadly, employment, education, volunteering, decide if a type field would suffice or a record type.

Type – a required field that simply splits out the object into broad categories.

Record Type – a required field that forces you to manage a whole new set of permissions, page layouts. It also changes the available picklist values. It’s strongly recommended you start with a simple type and move to a record type only when you absolutely need it. Read moreRecord Type Steps

Role – NPSP comes with this text field. Decide if this text field is useful at all, it’s quite up to you how to use it.

Title: If you plan on recording a job title, you can use the Role field, but be mindful you should hide the Title field on the contact or use a solution to populate or calculate (LINK) it.

Other custom affiliation fields that could be useful.

If you’re training people on the job, you may want to relate your training (custom solution) to the job (affiliation)

The manager, program director or some other contact that influences this affiliation

A reason the affiliation ended

Examples of validations to ensure important data is entered

Type and starting grade level are required when linking to school accounts only

DISH: NPSP has the Role field on the affiliation record, Salesforce has the standard Title field on the contact record. To ensure both values are aligned, you must manually enter and update duplicate information.

WHY THIS MATTERS: Users are confused by having duplicate fields in different places and will lose faith in their data and the amount of effort it takes to maintain.

SOLUTION: When the Role field is updated on a primary affiliation auto-populate the role value to the Title field on the related contact.

Data currently stored in the Affiliation|Role fields and Contact|Title Fields. Export to csv files so you can move it to the correct field when the new model is complete

Custom Title field on affiliation object

TOOLS REQUIRED:

DLRS or Rollup Helper

STEPS:

Create a Title field on the affiliation object.

Navigate to the role field in custom object setup (Setup|Create|Objects|Affiliation)

Select New

Select Text

Select Title as a field label and Name 128 as a field length (To match the contact field’s length) Enter a description and help text to your liking.

Make visible to all users and allow users to edit

Save to page layout and save

Arrange in page layout by opening the layout editor and selecting edit

Drag and drop to remove role and replace with the new title field

Do the same for the related list from the contact page layout

Do the same for the related list from the account page layout

Disable the NPSP Role field. (You can use the Role field as the Title but you cannot change the name of either so educating users on the difference may not be worth the effort. I suggest you just disable the Role field for now. If it’s been used as a job title value you may want to move that data over to the new field.)

Navigate to the role field in custom object setup (Setup|Create|Objects|Affiliation

Select Set Field-Level Security

Deselect all user profiles and select save.

Open DLRS by selecting the plus sign and selecting Manage Lookup Rollup Summaries (Note you can do this with Rollup Helper but the field values and process will be slightly different)

You will be creating a new Rollup so you just need to input data into the available fields

Lookup Rollup Summary Name = Contact_Primary_Title

Lookup Rollup Summary Unique Name = Contact_Primary_Title

Parent Object= Contact

Child Object = npe5__Affiliation__c

Relationship Field = npe5__Contact__c

Relationship Criteria =npe5__Primary__c=True

Relationship Criteria Fields = npe5__Primary__c

Field to Aggregate = Title__c

Aggregate Operation = Concatenate Distinct

Aggregate Result Field = Title

Calculation Mode = Realtime

Calculation Sharing Mode = System

Active = False

Select Save

Select Manage Child Trigger

Select Deploy and wait until Deployment Complete message appears

Select Cancel

Select Active

Select Save

Select Calculate (Please note if you have more than 5000 or so affiliations you want to select Schedule Calculate

Select Run Calculate Job Please NOTE: Before you calculate the job you will want to move any values currently stored into the Title field on contacts into the new Title field on primary affiliations, calculating this job will remove all Contact Title values from any contacts that have a primary affiliation and replace it with the value on the affiliation even if that value is blank.

Navigate to the contact field security Setup|Customize|Contacts|Fields|Title|SetFieldLevel Security

Set all to read only. This will ensure that users only add the title field by using the primary affiliation moving forward.

SERVE: Test your solution and update your user training guides.

Enter your title into an affiliation and be sure “Primary” is checked

Title automatically gets populated on the contact record

Consistent data when looking at org affiliations and contact titles.

RISK LEVEL: Low

TIME: 10 minutes (may take more time if contact title values need to be migrated to primary affiliations)

Challenge: We started using NPSP affiliations without customization or clear purpose.

Affiliation is a great feature of the Non-Profit Success Pack. Many non-profits have people at the center of their work and being able to track current and historical relationships with organizations can be key.

Applications for Affiliation:

Employment and employment history of donors and external contacts (replaces the contact and account Salesforce model when the household model is used)

Measure participants employment gains as related to your effort

Maintain history of contact’s educational history and degrees

Volunteer status between contacts and other organizations

Board membership

Overview:

Native Salesforce contains a feature called contact roles where multiple contacts are related to an account with the role that person plays. In a business-to-business landscape, this is probably sufficient as the sales function only cares about who’s at the company and what their purpose is when making a sale. It’s not very customize-able, for example, you can’t indicate when they started or ended the role, designate if they’re a volunteer or board member etc.

Affiliations are an improvement over contact roles and come with a couple of cool features:

You can use the Primary Affiliation field on a contact to designate the main account related to the contact.

If you add or change the reference in the Primary Affiliation field on a contact, it auto-generates an affiliation record.

If you check the Primary checkbox on an affiliation record it will change the Primary Affiliation reference on the contact and uncheck all of the other affiliation’s Primary fields

This leaves us with some challenges:

Job titles can get mixed up especially if it’s important to have the title appear on the contact record

You can quickly add the primary affiliation reference on a contact when someone changes roles, but you’ll still have to manually go back and manage start dates and end dates

The status field on affiliations is not automated upon entering an end date.

If you have a web form that creates or updates contacts, a “Company” text field could also create confusion of where to record employment.

If tracking employment is critical to your mission, you don’t have a way to verify employment is up to date

A question I hear a lot from organizations not yet using Salesforce, and unfortunately ones that already are involves the difference between NPSP and other packages that support non-profits specifically. The difference is very important as in most cases it goes down to an organization making a decision that they want to choose a tool that’s built on the Salesforce platform vs a tool that simply adds in a few specific general tools to Salesforce that non-profits may or may not want to use.

When we think of Salesforce many users are sold on the limitless customization possible with minimal expensive custom development. NPSP embraces this notion by not offering a full blown solution but instead some basic common features that you will need to customize on your own. With this power comes great responsibility. Other solutions are focused on you getting the most out of their enhancements usually at the cost of the overall flexibility benefits out of box Salesforce provides.

Let’s start with features that exist across all Salesforce-based solutions with exceptions for very specific needs.

You will not have to install or maintain specialized hardware.

You will not have to invest in extra security hardware/software.

You will be able to access the system from any internet connection.

You will be able to access the system from any modern internet browser and device.

You will be able to know more about your constituents from a single place.

You will have more automated processes than before

You will have more and more powerful options for communicating with constituents.

You will have better collaboration tools for your staff to focus on external relations.

System downtime will be minimal.

The platform will be enhanced 3x per year.

When choosing an All-In-One Solution:

You cannot assume any feature not listed in the solution providers website will be possible.

Many packaged solutions heavily customize the standard objects in Salesforce, and it becomes hard to add more customization on top of the installed product. You could also violate agreements with the provider and the support package they offer if you try

Integrating multiple systems is usually far more costly than maintaining a single system

A feature may initially meet your needs, but it’s not guaranteed to work when your expectations change.

An all-in-one solution will come with supported upgrades that look more like traditional software roll-outs

Many providers offer customization paths at extra fees

The dollars spent on support of the system could be more fixed and manageable especially if what it’s use has limited scope.

For example, some of the solutions are geared towards very specific fundraising scenarios that do not change often. Overall value is realized by paying for external implementation and support of a stable product in this case.

Overall if what is sold closely matches your need it could reduce labor costs and system problems in the long run. For example, if you decided on NGOConnect or FoundationConnect to manage events and online giving or grant management at a traditional org, resources that would have been otherwise used for system maintenance could be directed towards better solutions and staff to manage data reporting and analysis. Something Salesforce will never be best at with any level of customization.

When choosing a more open and customizable solution like NPSP:

You will need to decide on how you implement the initial solution and what resources you will commit to maintaining and enhancing the system year over year.

A single wrong decision on #1 could have very high costs:

Experienced Salesforce administrators are hard to come by if you plan on making significant additions to functionality year over year

An implementation too highly customized will require expensive developer time year over year just to keep the system maintained

It is rarely in the interest of an outside consultant to implement and never return for more service fees

Admin security and data governance can quickly go awry if staff roles and responsibilities are unclear

User experience can easily suffer under an administrator who is not capable or not dedicated to that function

Outside support may come from many different places with contradictory advice and non-overlapping fees

You have true ownership over your system and the data in it.

Many packaged solutions will make it challenging and expensive to uninstall and switch to a different solution.

You will be responsible for maintaining system updates for anything you’ve rolled out.

Likely problem if you’ve customized using code. That said, platform features come and go so you would need to be prepared to keep the lights on if a security patch or add-on needs reconfiguration or replacement.

If your needs are small or you don’t know what they are overall, you may find more success in hiring staff dedicated to administering the system or just living with a very minimal setup for now that measures and manages basic needs.

In either case, it’s a tough decision, and you should first ask if Salesforce or any CRM is right for you at all. If you currently operate on four spreadsheets with two staff members Salesforce can quickly become more of a burden than a tool. Donated does not equal free. $30,000 worth of technology is worthless if it does nothing but take up your precious time.

NPSP is community driven, and there is no set profitability assigned to the product other than making the world a better place. Hopefully, some of the content on this site will also help those using large packages, just want to make sure no one is counting on that.

Scenario: You need to open 12 records from a report as new tabs. (1 click , 1 drag)

See above! GTD!

Note: I’ve noticed LinkClump sometimes interferes with web apps specifically ones that allow you to right-click to export using a custom embedded web-app menu. All Chrome Apps come with a couple of gotchas here and there.