Start a new topic

Blanking out a non-blank field during import

Greetings, folks:

We're new to IOM, and I'm finding many cases where it would helpful if I could configure an IOM profile to respect an incoming blank value as the new value to put in the import candidate's RE7 record.

A good example is our 'Parent' constituent code Date_to value. It may be that someone ceases to be a parent for one term because her child was unable to attend, so her Parent code gets an appropriate (non-blank) Date_to during that import. If the child re-enrolls at a later term, that import file will contain a Parent constituent code with a blank Date_to.  However, during import IOM ignores the blank and retains the non-blank Date_to, preventing us from establishing that the person is, in fact, a parent again, unless we edit the RE7 record manually.

I realize that in that specific example, I could feed IOM a "delete constituent code" (minus sign) record before adding the new one, but that only works if the constituent code being deleted is not the sole existing constituent code for the import candidate. Otherwise IOM throws a 'missing Constituent Code' exception and skips deleting the constituent code, leaving the unwanted Date_to intact.

Does anyone have a suggestion for how to have IOM respect blank values during import, replacing non-blank values in RE7?

Many thanks,

I recently started to import from our offline system to our online system (vs manually entering changes) and this happens for me with middle name. For some reason the previous data entry person did things like for the name Mary Ann they put in Mary as FN and Ann as MN. When I go to import Mary Ann as FN I can change the first name but can not get IOM to remove the "Ann" from MN and I could wind up with Mary Ann Ann. I have my own workaround where I put in a ^ to the field and then later query for middle names with that so I can clean it up.
I think that is quite a broad statement.

I tend to use the biograpical info screen where you can monitor changes. it could be easy enough to do in there. I also think that the address change screen should act the same way as the bio info monitoring screen - the current format does not allow me to take some of the data from the input and not others.

Do you ever use Convio? In Convio when I am bringing in data from RE into Convio and I check that I want to bring in data it has a column which shows me what the final result will be. I can even delete data in that field and it will ignore both options and take the final edited information. I see absolutely NO reason why IOM could not perform in this way in areas like I mentioned above.

Time to think outside of the boxes you have already created...
Hi Melissa,

Yes, it is a broad statement. That is because we have over 1000 IOM users, so our support lines would light up like a Christmas Tree if IOM started deleting data just because a mapped field happened to be empty in an import data file. Can you imagine how many middle names or titles (or any of the other hundreds of fields IOM can map) would go blank if we started deleting them in this way? Just think about how happy most of those callers would be, and most likely thanking us for this new feature!  :)  We have to think broadly to protect the vast majority of our users who, by far and large, do not want existing values to be deleted by an import of other data.

That said, I can see in some cases where it would be nice to have the option to intentionally delete a field when importing (like if your previous DBA put separated the first name "Mary Ann" into a FN and MN). We do actually have a similar functionality for solicit and constituency codes, that you can specify the code with a minus sign ("-") in front of it to delete it. So I would suggest creating a UserVoice suggestion for adding a removal character for deleting existing values. I know Blackbaud uses the caret ("^") symbol for this function, but I prefer the registered trademark symbol ("®") because it's harder to mistakenly add that to a file and it's easy to remember ("®" for "Remove"!). Just in case anyone thinks submitting ideas to UserVoice is a waste of time, please note that we marked about 15 ideas as "Started" today, and they're set to be included in our July release.

Thanks, as always, for everyone's feedback!

I appreciate the explanation and glad Omatic is open to considering some kind of a way to do this. The earlier response made it sound like you would not even be open to a suggestion. Obviously none of us would want data to be indescriminately deleted but there are times when we need it.
Also - I am hoping that you're drawing ideas for suggestions from this forum as well as the Ideas section and not always leaving it up to users to have the time to file an idea. I got tons of emails today from the ideas board about suggestions going through and I think it is great but I hope it is not your only source of new ideas. Especially since last time i looked I could not find a link to the ideas page anywhere on the O-matic website so remembering the website is an issue as well as having the time to file suggestions.

For any ideas make it to a final release can the original poster get a "talk nerdy to me" T-shirt?
Thank you all for your feedback. I'll consider adding the idea as a UserVoice suggestion.

Regarding Allison and Jeff's comments: My thought was to have a config option in the profile that allows the user to map a given value (like the string 'NULL' or a sigil like the ones suggested in this thread) to a blank that will be respected during import, overwriting the existing value. That is, I understand the chaos that would ensue if *all* blanks were suddenly, and by default, overwriting data during import. But if an IOM user has taken steps to enable a (hypothetical) feature in a given profile, then has specified a value to use for this purpose in the same profile, then has included the same value in his import file, he can hardly complain to O-matic Software support when the feature that he has taken pains to enable works as intended. Well, he can complain, I guess, but not with fairness.

Cheers to all,
@Kirk - Good call on the configurability! Why should we dictate which character is the "delete" character? Let the user do it - brilliant! I would definitely recommend you 
This idea has just been added to our IOM UserVoice site by another user. If you wish to vote for it, the idea can be found here:
Login or Signup to post a comment