Does anyone have experience segementing between two distinct sets of data in RE? 1. I currently have our 450 clergy and committee members in our database which are being closely tracked for the constant mailings we send them and directory listings we produce. 2. We're just now launching our captial campaign and about to import 20000+ records into this RE system for fund raising purposes. These records have only been minimally maintained, duplicates exist, incorrect spellings of names, etc. *. Any ideas on how best to segment these two distinct sets of records for reporting and management purposes? Thanks, Loren Johnson Episcopal Diocese of Pennsylvania

Whoa, that is a tough one, but let me weigh in.

1. The existing group of clergy: are the in RE already? If so just make sure that you tag a particular attribute to them so that you can identify them in the future.

If not, when you import them -- import them separately and create a special attribute.
2. 200,000+ import: that is a bear. I import often, but never that number of records. The only thing that I can suggest is that when you import make sure that you search for duplicates. But before you search for duplicates make sure that you have your duplicate criteria set up to be sensitive. I have found that 5 letters of the last name and 3 of the first name along with the State usually yeilds a good list. Be warned: it won't get everyone. You most likely will have be diligent in finding the dupes yourself.

The benefit of having particular attributes or constituency codes is: that when you create 2 queries and segment the mail run in RE Mail you will be able to eliminate dupes that are in both queries.

THis may not be exactly what you are trying to do -- We have in our database over 2,000 United Methodist Churches that support our children's home. All the ID numbers for the churches begin with 'C' while the rest of the constituents in our database have just numbers for their ID. We use that in conjunction with Constituency Code of 'CH' We can easily query on the Churches by asking for ID's that begin with 'C'. I can then export based on that query. The churches are in 46 districts contained in 7 conferences. Again, the ID is used to segment the churches into the correct district and conference. Again, I don't know if this will help. If you have any questions that you think I can help with feel free to email me off list or call. Patricia Franklin Develoopment Database Supervisor Methodist Children's Home 1111 Herring Avenue Waco, TX 76708 [Email Removed] 800-853-1272

Before you import all those records, you might want to move them into an Access table or Excel spreadsheet and do some sorting for duplicates, check for obvious misspellings, etc. A little extra work at the beginning will save a bunch of time later. Having half the info for a constituent on one record and half on the other is not good. And you can cut down on mailing costs at the outset if you can weed out those duplicates before you import. :-) My 2 cents. laura Laura A. Caswell Information Technology Worcester State College Worcester, MA 01602 [Email Removed] (508) 929-8867

Thank you all for your feedback! I'm thrilled Black Baud has put up these forums and that you all have responded so quickly. I'll be writing in a lot more. I will be using the solution Patricia has described. Controlling the first few characters of the ID as a low level indicator. Now I just have to figure out the most efficient way of tracking the Clergy statuses without overloading the custom attributes screen, which I find cumbersome. Thanks again everyone! Loren

Hi! I would code the 450 with an attribute and import the other 20,000. I would do a query of the 450 that you coded and print out their names and look one by one in the system to see if any of them have duplicates. 450 is a small list to check. Later will be harder to check. I hope this helps.

Just want to add that I favor generating an Access db of both the records to be imported and all existing RE constituents and Individual relationships. You can quickly identify alot of dups within your import data and between it and RE data - comparing names, addresses, city/states, etc. Because the dups are often not exact matches, when looking for dups within RE I temporarily lower the criteria down to 1 character for the first name ... often there are dups with someone's initial. And within Access, I'll try matching on just last names. Helps tremendously. Beverly

I would like to point out that Patricia's solution also works in conjunction with Constituent Codes. I would recommend that you use Constituent codes to identify your Clergy and board members. Although the first letter of an ID is a good solution, there would be many advantages of using a constituent code instead:
-A cons code has more control. It would be easy to accidently not add a letter to the constituent ID, however you can add business rules to make sure that everyone has a constituent code.
-It is generally a good idea to seperate different information. An ID and the fact that the constituent is a clergy is two different things.
-Constituent codes are there for exactly this purpose.
-You will be able to add a constituent who is both a clergy and a board member (if that makes sense).
-As mentionned earlier, you will be able to filter easilly on constituent codes in your reports (not on the begining of the ID).
-Constituent codes are also used in gifts to identify that the gift was given as a clergy, a board member, a volunteer....

If you add constituent codes to all your existing constituents, you no longer really have to duplicate the information in the constituent ID. Duplicating information can be dangerous. Some constituents might end up with the letter in the ID but not in the constiteunt code. Then, if you run reports or exports based on your constituent codes, you will be missing constituents.

If you wish to quickly be able to identify a constituent's code without going to the Bio2 page, you can set up in your user options to include Constituent Codes on the bio1 tab.

As for the 20 000 that you will be importing, as mentionned, do the clean up BEFORE. Check for duplicates within that list, but also check for new rcords that might match with your constituents in RE. To do so, run an export of all your constituents and pop that in Access along with your 20 000 constituents. You should be able to purge a bunch of constituents with queries.

A tip for your clean up. Keep the original data of your 20 000 ner records intact. Add new columns for your corrected address, name, formated phone number... Never delete a record, intstead add "flag" columns to your table identifying the records as an RE match or a duplicate. Then use a query to export the text file that you will import into RE.

You might want to standardise your addresses before import. Make sure your cities are all spelled uniformely (don't have the same city spelled 4 different ways).

To identify duplicates, do several passes. Start verry precise. For example, match first name, last name and address (or phone is even better if you have it). You can practically flag all those as duplicates without looking at them manually. Then, enlarge your criteria (you will probably have to manually confirm matches at this point). You might want to check first letter of first name with the complete last name. Purchassed lists often are derived from phone book listings and do not include the complete first name.

Lastly, you might want to identify a source for your 20 000 that you import. The use you will make of this information will determine where you will place the information. If you plan to use this information, youo could place it in a constituent attribute. If you do not plan on using the information, but you think that you might need it one day, you could use a code in the begining of the constituent's import ID. I know I am sort of contradiction myself here. The reason I might use the import ID is that when you add a constituent, you got the information from one source only (usally). Also, the source of a constiutuent will never change. In the cases where I have used this method, the source was not needed for reporting purposes. I had used the code in the ImportID to purge records, an administrative task (you are not supposed to keep rented list). William da Silva
President, eSimpleIT
Technology and organisation simplified
[Email Removed]