Extending a collection object in the constituent update batch

Ray Porter

Hi,

I've been asked to add a do-not-email reason code to the constituent update batch. Email addresses in the batch are a collection field and, ideally, we'd like to have the new field appear in the collection and function just like the corresponding field in the address collection field. Is there anyway to extend a batch collection field?


Ray Porter

Steven Finnell

Hello Mr. Porter,


Unfortunately I don't believe there's a way to extend a collection. Even if you could, the biggest issue you'd run into is that when the batch executes it winds up calling a function to parse the collection information (which is nothing more than xml) out into SQL again (this function references specific columns in the collection). What that means is that even if you had it extended you wouldn't necessarily get the value parsed through the batch and processed, you'd have to create a new batch entirely due to that one function call.


Mind you I'm not at all an expert when it comes to CRM so someone else might know of a work around or way to do what you're looking for.


Best of luck

Ray Porter

Thanks. That’s largely the conclusion I’ve reached. There’s quite a bit of CLR code linked to this particular batch too and that presents the same problem you’re describing. I could add the do not reason code as an extended field in a batch extension but then linking the reason code to the correct email address would be a challenge. I don’t think you can create a UI model for a batch?


Ray Porter

Steven Finnell

I've not played around with extending Batches yet so I can't really help in that department too much.


Sorry

Willem Vandenberg

Blackbaud actually gives an example of how to extend a collection in their SDK documentation, under the header: Batch Extension Example: Extend a Collection

The way they go about the issue you are raising is by simply having you, the developer, re-create the collection you are extending. You must make sure that in any new Batch instance you create, you replace the OOB collection with your new extended one.

This is over all not a big deal. I have done it for multiple collections – existing and new -- in the Constituent Batch.

CUB is a bit of a different beast. I have managed to add a Do Not Email Reason Code to the system and link that up with CUB, but it requires a lot of replication of CUB's existing handling of the Email Addresses field, which at times can seem pretty convoluted – especially because CUB shares a lot of its code with the Enhanced Revenue Batch.

But it is definitely doable.

Cheers!

-Willem