We are streamlining to decrease the cost of sending out donor updates so we can do more segmentation with the same cost. We’re trying to use more standard tools and standard features since they have come along.
User Story:
We have two quick fundraisers in February and a big regional fundraiser at the start of March. This would be too much to communicate to everyone so segmentation is crucial. We want to send a note and link to all past participants so they have a chance to participate again and share. We will only be making public appeals as part of the latter one because of the tight timing of all this activity. Pardot knows about opportunities and a dynamic list can filter on prospects with opportunities (which requires an opportunity contact role) and filter on properties of the opportunity. This is great. We want the user to be able to filter on the Primary Campaign Name containing (for example) Valentine, Souper Bowl or Amplify Austin.
Problem:
Custom fields are supported in Pardot Opportunity but Primary Campaign Source is not available (because it is special or a lookup field). There is no way for the Pardot user to configure the dynamic list view they want without change.
Solution:
We added a custom formula text field to our opportunities. We made it available to all profiles except our minimum profile set. Note that soon everyone will be assigned our minimum profile so access will be via permission sets. It is not visible on any page layouts.
Then we added a custom opportunity field in Pardot and linked it to the new field in Salesforce. We have a growth edition. We don’t have many custom opportunity fields in Pardot.
Then we triggered a resync of all prospects on our Salesforce/Pardot connector. This may not have been necessary.
Then we created our Dynamic lists. All ready to send emails now!
Pattern to learn:
This implementation follows a common pattern. Salesforce has some special fields that can’t be used somewhere else. The fix is to create a (hidden) text formula field that presents as a simple number or text value. Often this field can be used in the desired way since it doesn’t have any of the special Salesforce stuff in the way. (Occasionally a formula field won’t do the job and you have to create a static value that is updated by a flow.) I call these problem fields or objects “special snowflakes” and encourage Salesforce product managers to avoid them at almost all costs (including delays in feature access). They increase the Salesforce development and maintenance cost and significantly get in the way of new feature timelines. Worse yet, they increase all our costs across every org and for decades (thus costing even more in the long term). Often these are “legacy items,” which just makes the logic stronger to avoid and eliminate them.
Anti-pattern to avoid:
Try not to make special snowflakes in your own org. We considered a couple of ways to address this that weren’t this good. They would have solved the problem but only this problem. This is far better in that several fields on the opportunity are equally valuable to the Pardot user to create dynamic lists for segmentation. I learned in architecture a long time ago that there are only three acceptable numbers: 0 (none… we don’t do that), 1 (we do it only for this one thing and it can’t be changed) or infinite (we do it for all, everywhere). Architecture is not perfect but good architecture costs less. Not an architect?? Oh yes you are, if you are an admin! Read architect.Salesforce.com regularly. It’s really good stuff! No longer esoteric stuff that matters only to 1%. It’s foundational material that will really save you time, money and make your careers when you learn the patterns and anti-patterns.