We’ve recently launched our integration with Mailchimp, allowing you to synchronise your contacts with Mailchimp, send campaigns through Mailchimp, and have them appear back in Lamplight, linked to the recipients.  You get the email templates, deliverability, and reporting functionality of Mailchimp, integrated with the ‘overall picture’ view you get in Lamplight.  It’s being used by a number of our customers already.

There’s a downside.  You’re trusting Mailchimp with the names and email addresses of your contacts.  That’s a judgement you need to make; for many of our customers that’s fine; for others it may not be.  Of course it’s the same judgement you make with us.

We occasionally get asked about other integrations – can we do reports on Google Maps?  Can we publish work records to Facebook events?

This is obviously attractive.  Why build a geographic reporting system from scratch when Google have done it so well?  Why not save me some double typing and let Lamplight post things to Facebook?

 

Trust

There are different kinds of integration.  Essentially these can be divided between server-to-server integrations and client-side integrations.  With Mailchimp, our servers talk directly to Mailchimp’s servers.  We can control what we tell Mailchimp, and what messages we accept from them.

But client-side integrations are different.  Something like a Facebook ‘like’ button, or a Google Map within Lamplight, effectively give access permission to Facebook or Google or whoever to Lamplight as if they were you.  Those maps or buttons contain javascript programs that ‘like’ or ‘map’ – but in principle they could also scrape all your data, send it back to base, and then delete it.  And we could have no control over that, because as far as Lamplight’s concerned, it’d be you doing it.

We don’t actually think those companies would do that.  But in principle they could.  And that’s a good enough reason for us not to.

Visibility

A related issue is knowing where your data is.  With Mailchimp, it’s very explicit that you’re sending names and email address to them.  You have to opt-in and set it all up, and it’s obvious that’s what’s happening.

But there may be more subtle data sharing going on with client-side integrations.  A geographic reporting feature using Google Maps would require that you share the data you’re reporting (client addresses and self-confidence ratings?) with Google – and that may not be obvious to you.

Even more subtle are new features within web browsers.  One really neat one that’s arrived relatively recently is voice recognition – you’ll see the little microphone in Google’s search bar that lets you say your search terms.  When this came out we thought it’d be awesome to be able to dictate your work records instead of all that typing.  But it turns out that the voice recognition happens remotely – the audio is sent to Google servers where it’s converted into text and sent back.  So adding this to Lamplight would have meant that any data you spoke into Lamplight would also be being shared with Google.  Again, we don’t actually think they would misuse it, but we don’t trust them with your data to be adding it to Lamplight, however neat it would be.

To conclude

We think the best approach to security issues is excessive paranoia.  Server-to-server integrations allow us complete control over what is shared with external services.  And that sharing is explicit, and opted-in to by you: if you don’t turn it on and set it up, nothing happens.

But we are completely powerless over client-side integrations: in principle it’s equivalent to sending your username and password to that external service.  And the data sharing that necessarily happens with client-side integrations may be subtle.

 

When you add new profiles to Lamplight a duplicate check is carried out to make sure you’re not trying to create a profile that already exists. This is done by Lamplight checking either that the name sounds similar (so the spelling might be different) or name matches.

If you’ve imported data from a spreadsheet or another system then the possibility of bringing duplicate profiles into Lamplight can increase.

To make sure you’re using Lamplight as effectively as possible you should de-duplicate your profiles as soon as possible.

Within the system administration section there is now a link that allows your admin to de-duplicate records.

It will first ask you to select what criteria you want to use to search for duplicates:

Search for duplicates

Once the system has searched for duplicates it will bring up a possible list (on the left of the image below):

Match profiles

Once you’ve selected a profile from the drop down list, the possible matches will appear in the list on the right.

You will see the profiles side by side and you will have the option of merging or overwriting each section, as per the instructions below.

Merge sections

Once you’ve finished you can delete the source profile.

One of the things that Lamplight users have asked us is the ability to use information in one type of profile as criteria for creating auto groups of another set of profiles.

As an example, parent profiles contain information about their employment status. You want to create an auto group of all children whose parents are unemployed. As long as the parents are connected to the children with a relationship you can now do this in Lamplight.

  1. Create an auto groups of all people/ users who have employment status as unemployed.
  2. Create a new auto group of all children who have the relationship family and related to the group ‘unemployed people’.
  3. The profiles in the auto group will be all profiles that are linked to another profile with the relationship family to someone who is unemployed.

Lamplight relationship auto groups

You can watch us talking about the new functionality in this video:

(From 4:05 – You can watch from the start to see some of the other recent changes to groups)