Hey all,
So far, we've been pretty strict with the way we've designed our constituency codes and interests. Our interests are basically only genres, and all relate to TKWs applied to programming. Our constituency codes are basically a limited set of "evergreen" classes of relationship with our institution, and I think it makes sense to be on the conservative side when it comes to adding new codes.
We have a business need for managing "lists" of constituents, in that membership in the list needs to be editable, a start and end date is not required (this is too granular for constituency codes anyway), and pulling a customer's membership for all classes of "list" should be easy to add to custom reports and output sets. Just creating a simple static list is not an acceptable solution since static lists cannot be edited by users who did not create them, and this would not be editable from the constituent record.
Something I've done in the past when doing large constituent imports has been to create an attribute with multiple dropdown values, and assign a value (referencing the dataset) upon import. This seems to work out okay for one-off imports since the user doesn't do any assigning (and I can even make the attribute non-editable), but I don't think it's the right choice for this situation.
So what I'm considering is creating a set of TKWs for constituents only, in a distinct TKW_CATEGORY that I can use to base my output set elements on. Does my thinking sound correct on this? Just want to make sure I'm not overlooking anything.
Nick,
I don't know how helpful I might end up being, but I can say that in our situation we're using Constituency and Interests in about the same manner that you are.
Constituency is where we do most of our custom additions, and we use Lists and Import to Lists to add and remove Constituency data from our patrons as needed. We have Constituency values for all of our major membership groups, our Board Directors, and we even tie Constituency into giving amounts to our Annual Fund to track their level of giving for benefit purposes.
Interests we don't use very much, primarily because--and this will sound crazy--we don't use Tess for Ticketing because the performing arts center that presents us uses Tickets.com and so we have to import ticket data post-performance to have in Tessitura (and our first import likely won't happen until after we're done with The Nutcracker this month. We have been Ticketing via TNEW for our Center for Dance Education classes though, so that combined with ticket data import will have us using Interests more in the future just to assist our Ticketing/Marketing department with customer history for performance types.
Thank you,
Brian