The Spotlight
The Official Blog for Arts and Cultural Organizations

Best Practices for PE/RE integration, part III

This is the final part of my three part series on integration between Patron Edge and The Raiser's Edge. In this part, I'm going to go over one of the things that all organizations battle with, regardless of the CRM application used - duplicate records .

Once your database has been around for a while, duplicates start to become a frequent concern. There are two ways to deal with duplicates: preventing them and merging them.

Prevention - The best way to deal with dupes is to keep them from ever getting into the system. It takes more effort upfront but pays off in the long run with less ongoing data cleanup. Prevention requires a two-pronged approach using the features of the software and changes to your business rules.

  • Software-enforced rules
    1. In Raiser's Edge you can define duplicate criteria to prevent duplicate constituents. Use Last Name, First Name and five digits of the ZIP. You can add more criteria, but remember that the more criteria you add, the less likely you are to catch potential dupes when adding a record.
    2. In Patron Edge, define Duplication Conditions. Use Last Name, First Name and Email. Frequently this is all you can capture about someone on sign-up sheets or the web. Patron Edge can't do partial field matching, so don't use ZIP code here. However, Raiser's Edge can't match on email address so we take advantage of the PE feature.
    3. Patron Edge Online is a different animal altogether because there's not a live person between the system and the patron. You can prevent dupes with a couple of Company settings. If you use the feature, remember the impact on the patron. If I get a popup when buying tickets online that says I already exist, but I don't know what email I used when signing up, I can't log in to use my account and I can't finish the sale as a new person. Catch-22. I either call the box office or give up on the purchase. I'm not saying to avoid the Patron Edge Online dupe prevention feature, just think carefully before implementing it.
  • Business rules
    1. Choose a system of record, either RE or PE. Of course you can enter most data through either system, but when you're dealing with important donors/patrons, make a habit of working on those records from one side as much as possible.
    2. Restrict access to add/edit records to those who truly need access. For folks who aren't trained on a system, only allow read access.
    3. Train users to always search before creating a new record, and enforce the rule by auditing who is creating duplicate records.

Merging - Some dupes still slipped through, now what? In an integrated system, we use a special merge function that hopefully makes this easy for you. It does remove the move tab features of Raiser's Edge and forces you to only keep one record; we chose to do this in order to keep the data properly synched. The positive side of this rule though is that you can merge in batches. Set your duplication criteria in Raiser's Edge and run the merge from Administration, and you can merge lots of dupes at the same time instead of going one by one.

And that's the final installment of PE/RE best practices. If you got something out of it, leave a comment to let me know and I'll do more of these in the future.


Comments

Jessica Wright said:

question: in regards to dup conditions in PE/PEO in KB it says both codes must be used. Does this mean i have to implement both PE AND PEO dup conditions or can I just set up PE dup conditions??

thanks - JDD

# April 20, 2009 4:52 PM

Alan Miller said:

Jessica:  I just spoke with support about this, and they said it should work if you just have PE and not PEO.  You would only need to use group 1.

I'm testing this functionality now.  I'd really like to see it work where you can have multiple sets of criteria for different types of client records -- for instance, individuals might have one set of criteria, and organizations might have another.  Organizations typically do not have values in the "first name" field, for example, so they'd never be caught by the example criteria in the knowledge base solution.

I'd want to check to make sure Bob Smith at Bob.smith@ isp.com wasn't being entered a second time, but I'd also want to check to make sure Alexander Graham Bell School of 123 Main Street in Chicago wasn't being entered again as A.G. Bell School.

All in all though, this is pretty cool functionality.

# April 21, 2009 10:39 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: