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 have tended to use interests for allowing customers to add themselves to (or off) mailing lists, so your solution sounds fine.
Only thing is you may want to add a weight to the interestwhen added to a constituent record (poss background sp) as that way you can see when people have unticked it as otherwise the DB just deletes the record - just helps with queries and gives you a way of seeing the deletions as well as the adds.
Mark