One of the most common requests I hear from my clients is that they want to be able to easily import outside data into the database. They might have things like lists of attendees from meetings not managed in the primary database; or membership leads gathered from a trade show staff recently attended; or names of people who showed up and registered on-site for a recent event.
Whatever the reason, at some point, every one of my clients has had a list of names and/or companies that they wanted to import into their AMS. The challenge is that it’s never as simple as it sounds.
There are several reasons why imports can be tricky (not impossible, mind you, but tricky):
- Managing duplicates. The number one concern of any list import is that the list may contain names and/or company records that you already have in your database. You don’t want to create duplicate records, so you need some way to compare the existing database to the list being imported. If both lists have unique identifiers (e.g., member or customer number), you’re all set. But that rarely happens. So now you have to find some other way to identify potential duplicates. There are a variety of ways to do this, but none of them are foolproof. So once you’ve determined how you’re going to identify dupes, you’ll still have to review the import to ensure you’re not merging data that shouldn’t be merged.
- Determining where the data goes in the database. This is easy if you’re importing a list of names and/or companies only. But what if you’re importing event attendance, or CME points, or membership data. Now the import has become much trickier. Not only do you need to manage duplicates, as noted above, but you’ve got to be certain the other data is being mapped to the right fields. And if those fields don’t exist in your current database, they have to be created before the import can be executed.
- Finance data is even trickier. Every now and then a client of mine will say “We have a third party event registration system for our annual meeting. All registrations, including fees, go through that system. Why can’t we just import all the data, including the financial transactions, into our AMS?” On the surface, this seems pretty straightforward. But in reality, there are certain parts of an AMS where data isn’t just captured in the system, the data fields themselves have triggers and processes behind them, that many users aren’t aware of. For example, it wouldn’t be unusual for an AMS to have a trigger behind the payment field for membership. The trigger is designed to set another field to “active” once the full payment of the membership is entered. Importing data into fields with triggers can cause all kinds of unintended consequences.
The good news is that many AMS packages have made it increasingly easy for trained staff to do certain types of imports (especially those that have no data beyond name and company contact info). The bad news is, for many types of imports, you’ll need intervention from your vendor to execute them the first time, because of all the details involved, as mentioned above.
If you’ve got outside data that you want to import into your system, talk to your vendor and see what is involved. It may be easier than you think (or not).
Did you like this article? If you’d like to receive notice of articles like these as they are posted in the future, click here.