• Replies 3 replies
  • Subscribers 338 subscribers
  • Views 82 views
  • Users 0 members are here
Related

When to use Interests vs Constituency codes?

Nick Reilingh
$organization

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.

Parents
  • $organization

    We’ve been using mail purpose. Our web implementation displays them as check boxes that patrons can manipulate when they are logged in. One of the options is “No e-mail to this address.”

     

    People who check that get the e-marketing box unchecked for that eaddress. (I have a report that looks daily for that as well as other e-mail issues and calls to my attention any e-mails where someone has inadvertently selected positive e-mail lists (News, Special Offers, and the like) as well as the No Mail box, which, if they were entered at the same time, I uncheck. This happens, during busy periods, perhaps a couple of times a week.

     

    Lucie

     

     

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Mark Ridley
    Sent: Monday, December 12, 2016 4:39 AM
    To: Lucie Spieler <lspieler@fgo.org>
    Subject: Re: [Tessitura Technical Forum] When to use Interests vs Constituency codes?

     

    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

    From: Nick Reilingh <bounce-nicholasreilingh4883@tessituranetwork.com>
    Sent: 12/10/2016 2:50:28 PM

    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.




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

Reply
  • $organization

    We’ve been using mail purpose. Our web implementation displays them as check boxes that patrons can manipulate when they are logged in. One of the options is “No e-mail to this address.”

     

    People who check that get the e-marketing box unchecked for that eaddress. (I have a report that looks daily for that as well as other e-mail issues and calls to my attention any e-mails where someone has inadvertently selected positive e-mail lists (News, Special Offers, and the like) as well as the No Mail box, which, if they were entered at the same time, I uncheck. This happens, during busy periods, perhaps a couple of times a week.

     

    Lucie

     

     

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Mark Ridley
    Sent: Monday, December 12, 2016 4:39 AM
    To: Lucie Spieler <lspieler@fgo.org>
    Subject: Re: [Tessitura Technical Forum] When to use Interests vs Constituency codes?

     

    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

    From: Nick Reilingh <bounce-nicholasreilingh4883@tessituranetwork.com>
    Sent: 12/10/2016 2:50:28 PM

    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.




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

Children
No Data