Start a new topic

First time running MergeOmatic

This will be our first time running this through our database. Our database is rather large and while I know we can break it down to run by query I am wondering if we can do a complete scan.

My main question is can this run in the background, run overnight?  Or do you need to be logged into RE to have this continue to run?


Thanks, any suggestions for a newbie are appreciated.



Hi, Nicol. We've been using MergeOmatic for a few months now and here are some tips we've figured out:

You do need to leave RE open and running while scanning with MOM. In fact, you won't really be able to access regular RE functions on that workstation while it runs.

I recommend you let it run overnight or some other period of inactivity when no one will be making significant record changes. Depending on how many records you're scanning, it will take several hours.

Make sure to check your results carefully by match score. The algorithm is pretty good, but there are always some weird scenarios where it will match incorrect records or miss some dupes. We figured out a match score of the high 90s or above was pretty good to auto-merge but we combed through the rest more manually.

You might also consider creating some constituent queries to scan specific constituent groups instead of everything together. For example, if you have certain types of origin codes, you might want to scan them as a group together.

Final advice is don't be too eager to just start merging. Learn how MOM is flagging duplicates, tweak the weights as needed, and figure out a review and merge process that works for you.

Good luck!

Rob C.

Hi Nicol,


In addition to Rob's tips above, we run a query based on date (i.e. New donors last month who gave a cash gift) but i do like Robs idea of constituent query groups as well.


We generally eyeball everything, and use the "Merged Records" query to bulk update things MOM misses - such as mobile numbers on old addresses and deleting duplicate attributes (we have mailing attributes that MOM doesn't de-dupe on as they aren't exactly the same, date wise)


Also, now that MOM and IOM talk together (we just updated our version to the one that has that capability) it means hopefully we will catch more of those difficult ones. 


One important thing we did was to output all the fields in the dupe screen we needed (cons code, last gift date etc etc) that you need to identify the most  relevant records


And we also created a query to put in the Query Scoring query - that scored higher than all the posint for survivors, so our most import donors (Major Donors, members etc) always have their original record marked higher than the duplicate record (where in other records we may be happy to keep either, these important people should remain the original one)




Login or Signup to post a comment