Import vs Batch Processing for new constituent records

Vincent Meade:

Import should always be the better choice but with an incomplete listing of data variables I do feel forced to manually type in records via the batch. With +100 rows and +40 columns, what a pain!


Opinions aside, if anyone knows what I am talking about and can prove to me I'm wrong (essentailly that the entire data structure that defines a constituent can be imported) then I'd be overjoyed. I'm noticing that the more fringe-y data variables are ignored? Not cool Blackbaud!


Thanks.

Vincent Meade:

 

Melissa Graves:

I am not 100% sure what you are asking but you CAN import constituents - and depending on what data you are imporing it should be able to be imported in a single import. There are some things that are not possible though so can you share what you are having trouble with. I typically use batch for 20 or fewer but definitely import if more than 50. Between 20-50 I decide depening on the complexity of the data and the time I have allotted.

How do you deal with an unique user-defined attribute?

 

Vincent Meade:

Jen Claudy:

You can add Attributes to your Constituent Import, it just takes several fields (and it's listed as [Constituent Information Attribute]).  CAttrCat (the Attribute Category), CAttrDesc, CAttrDate, CAttrCom.  If you need a second Constituent Attribute, put the same fields in again, then in the Import screen, make sure the extensions are set properly...two digit number on the far-right which is defaulted to [00].  The extensions for all fields of the second attribute should be [01], etc.


Use the field names that RE needs (i.e. [ConsID], [CAttrCat]) so you don't have to do any matching, which would need to be done anytime you change anything in your file or you'll get a lot of exceptions.  Pick one record and use it to test until you get everything importing as you want it to be, then save at least one backup copy of your field names so that you don't have to reinvent the wheel.


Also, when I'm importing a lot of Constituent Records, I often assign an Import ID of my own rather than let RE do it.  This way, I can very easily grab a list of records (i.e. alumni2017-001, alumni2017-002, etc.) or know where these records came from via the Properties window.  Not necessary, but I've found it helpful on occasion.

Thanks, I'm seeing this all now and it's making sense. While it will take awhile to set up and then test, this process will be less error prone and save time. Not to mention each year when I input students it can be done with no test and very fast.


Also, I like the ImportID idea. I might do that if it is possible for us ( we might be using a # from another datasystem)


So that's how databasing is meant to be done, thank blackbaud. (sorry about before! you're still cool! )


Also thanks for everyone's experience and answers, it's nice there is a lively forum here.

 

Kristin White:

Melissa Graves:

Um - I import the relationships.

I do too


As a result of this discusison, I have been experimenting with importing relationships.  Is it possible to do the following:

import from excel a new student record, including a parent and their address AND assign that parent a constituent id number?

I have done the first part, e.g. student name, id, address, student ID number, constituent code, etc.  I doubt that the import can create a new constituent ID number for the parent. 

 

Karen Stuhlfeier:

I think that it depends. I set up batch templates for our new students each fall and after I set up the defaults I have very little data entry. We receive their information as they are enrolled and can just keep adding to the batch and commit it when we know that we have most of them entered.