Use your Existing Pardot Email Send to Prepare for GDPR

We are now in the final countdown to 25 May – the day marked in every marketing teams calendar, when GDPR will come into place. Businesses around the world have been preparing their marketing strategy and policy for months and some might have started running an opt-in nurture campaign in Pardot like we did at Nebula. However, if you haven’t got the time to gather your content team and prepare a nurture program ready for GDPR, but you’d like to give your prospects a chance to confirm their opt-in easily, you’re in the right place.

Continue reading…

Patterns in Apex: Dependency Injection, Strategy, and Decorator

When you start out in Salesforce development, there seems to be little need for software design patterns. Perhaps because development starts with little triggers doing this and that in a few lines of code. But, as soon as the requirements, codebase, and team-size grow, then the advantages of patterns and other software engineering practices kick in. In this article, we’re going to look at three patterns (which overlap) and help us to solve a problem that many Apex coders will be familiar with.

The Problem

Suppose you’re writing a function that receives a list of Contacts and needs to return them in reverse order of LastName. When you need to sort, you immediately reach for the sort()  method of the standard List  class. But it’s not quite that simple. sort()  works by requiring the elements in the list to implement the  Comparable interface (plus accepting some built-in types that don’t implement  Comparable but only sort in a non-configurable way).

So, the standard approach is to write a wrapper class that contains a Contact and implements  Comparable in the way you need e.g.

Which is fine, but if you want to sort a list of Contacts, then there’s a lot of marshalling to do before you get to call sort() :

Make a list of wrappers, put all the Contacts into wrappers, sort it, make a list of Contacts, copy all the contents of the wrappers into that final list. Who has time for all that?

The Solution

The alternative is to write our own sorting implementation which is not configured by properties of the elements in the list. Instead, it’s configured by an object that we pass in at the time of construction. This is dependency injection. The sorting algorithm depends on being given a method to compare elements, and we’re going to supply (inject) that dependency when we create an instance of the sorter. Get this right, and we’ll have two great benefits:

  1. No need to marshall all our sObjects into a wrapper just to sort them
  2. No need to implement Comparable in our own classes (along with possible configuration to allow sorting by different criteria) just to make them sortable. Importantly, if I wrote a class last year, and today I decide that I need to sort lists of that object, I don’t need to modify that class to make it sortable

The first piece of the puzzle is to define an interface for comparing two objects. Like Comparable , but not tied to the objects we’re comparing:

Then, we can write a sorting class which uses an instance of Comparator  to do the comparisons:

We won’t get into the details of the quicksort sorting algorithm, but we will note that in lines 29 and 31 we are using the Comparator  to compare the elements. The Quicksort  class doesn’t entirely perform a sorting algorithm, it is missing the part where it knows exactly how to compare two elements in the list. That detail is provided at runtime by passing in a instance of  Comparator. This is a use of the Strategy Pattern and, as we noted before, dependency injection.

So, let’s build a Comparator  for our earlier example:

Pretty simple, so what does the actual sort look like?

Wow, so much better!

Going Further

But, we can go further. What about classes that already implement Comparable ? Piece of cake:

What if I wanted to reverse the ordering? Do I have to write a new Comparator  for each combination of sorting criteria that I’ll ever want? Or maybe one MegaComparator  with lots of parameters and switches? No… we can keep things clean by using the Decorator Pattern. This allows us to modify the behaviour of a Comparator  by wrapping it inside another one (decorating it). For example, we can write a reversing comparator like this:

And then we can sort our Contacts in ascending order of LastName by putting the two Comparators together:

If you’re a Java programmer, you’ll be familiar (and probably a bit frustrated by) the decorator pattern due to its extensive use in the IO libraries ( Reader , BufferedReader , etc.).

If you’ve been paying very close attention, you’ll notice that ReverseComparator  is using dependency injection and the strategy pattern on its way to being part of the decorator pattern.

Final Thoughts

This all seems like fun, but do you use it every day? I don’t write the utility classes with these patterns every day, but I do use code written with these patterns every day. When you’re trying to pull out general solutions that you can re-use everywhere, and pondering how to make them configurable for scenarios that you can’t yet imagine, these patterns give you some great ways to build in all the flexibility that you need. So, if you’re a senior engineer building some of the tracks for your colleagues to run on, this gives you a great way of doing it.

For example, we have utility classes to convert sObjects to/from JSON using metadata to specify the JSON structure. How can you deal with external systems that have a million different ways of storing dates? Or when they decide to store some numbers in strings? By writing the utility classes with the strategy pattern, and allowing the developer in a specific situation to fill in those details themselves. The utility class can deal with how to fetch Contact.Account.Name through those object relations, and it can deal with building nested JSON objects. You can concentrate on whether or not there should be a ‘T’ or not between the date and the time on this particular integration.

As always, happy to hear feedback on Twitter @AidanHarding or email

Is it time to Spring Clean your Pardot Account?

Now that Spring has sprung and the sunshine is finally starting to make an appearance, there is no better time to clear out your clutter and tidy up that bulging wardrobe. And your Pardot account is no different! Whether you’ve been using Pardot for 3 months or 3 years, over time your account can become full with old templates, inactive prospects or inaccurate information.

There are many ways you can keep on top of your Pardot Account to make sure you continue to run a successful Marketing Automation system – see below for our top tips.

Continue reading…

Dynamic Lists – The secret weapon to spring clean your Pardot account

Dynamic lists are an extremely useful tool to automatically build lists of prospects who fulfil certain criteria.

There are two obvious use cases for this:

1. To ensure that a frequently used list always includes the correct prospects: For example, keeping newsletter lists which you use every month updated with prospects who meet your criteria.

2. To automate actions when prospects meet certain criteria: For example, a dynamic list for prospects which have not engaged in over six months feeding into an Engagement Studio nurturing programme.

Continue reading…

Salesforce Trigger Handlers Driven by Custom Metadata

Reef Triggerfish by Bernard Spragg

Salesforce has a number of recommendations regarding best practice when writing Apex triggers. Two of these recommendations are:

  • One Trigger per object write a single trigger which then invokes various Apex classes to do the actual work of what could otherwise be a collection of triggers. If you write multiple triggers, you cannot specify the order that they will run in. By having a single trigger, you can decide what the order of execution will be.
  • Logic-less triggers the trigger should have as little logic as possible, delegating all the real work to Apex classes. This helps to encourage other good practices – such as being able to share the logic from the trigger with other code (e.g. so that you could invoke a batch process to effectively run the trigger on historical records).

Salesforce even propose a solution to adopt these best practices, by writing trigger handler. I never particularly liked their solution because it leads to a central trigger handler class for each object which then needs to be modified every time you want to add a new “trigger” to the object.

Continue reading…

Salesforce Communities – Licence Types Explained…

If you are new to Salesforce Communities, it can be a little tricky getting your head around which type of community licence is right for your organisation.

To start with, there are fundamentally three types of Community:

Customer Community – allow your customers (B2B and B2C) engage with both your organisation and other customers via an online portal.

Partner Community – give your resellers, distributors, brokers limited access to your Salesforce to pass you leads and work on deals with your sales team.

Employee Community – give certain employees limited access to information in Salesforce. Use this licence type to build custom applications for your employees who don’t require a full Salesforce licence.

Continue reading…

Salesforce Community or Website?

Salesforce Communities offer you the chance to bring your live customer data into a website as well as the opportunity for your customers/ partners or indeed internal members of staff to add data into your Salesforce instance.

Continue reading…

How to Manage Events with Pardot

There are a number of ways you can manage your event communications through Pardot and people are often unsure about the best way of doing it. By the end of this post, you will be aware of the different options available to you and hopefully avoid any common mistakes. Continue reading…