?onstituent Code or Attribute?

Yuriy Iordakiev

We are College Alumni relations department so we have a primary constituent code "Alumni" We have a consultation service to help alumni find a job. It's called Alumni Career Services. Would you say we can track Alumni who use this service with a constituent code "Alumni Career Service Client"? Is this the best way to track them (with "Date from")? Or attributes are better? Do you think it would be more consistent to use "Alumni Career Service Client" code to avoid confusion with queries? I mean to keep all info in the same place (Bio2-->Constituent Codes)? Thanks!

Joshua Bekerman bCLO bCRE

Yuriy Iordakiev:
We are College Alumni relations department so we have a primary constituent code "Alumni" We have a consultation service to help alumni find a job. It's called Alumni Career Services. Would you say we can track Alumni who use this service with a constituent code "Alumni Career Service Client"? Is this the best way to track them (with "Date from")? Or attributes are better? Do you think it would be more consistent to use "Alumni Career Service Client" code to avoid confusion with queries? I mean to keep all info in the same place (Bio2-->Constituent Codes)? Thanks!

I would use actions, with the action date the date they started using the service, and the completion date the date they no longer needed the service (got hired?).  This way you can track if they use the service multiple times, when and for how long.

Being an Alumni Career Service Client isn't their primary relationship with your organization, Alumni is, which you already have a cons code for.  I wouldn't use cons codes for this at all.  Maybe attributes (if you don't like the actions idea), but then how do you handle when they are no longer using the service?  (Please don't say "Former Alumni Career Service Client.")  [;)]

 

JoAnn Strommen

Josh Bekerman:

I would use actions, with the action date the date they started using the service, and the completion date the date they no longer needed the service (got hired?).  This way you can track if they use the service multiple times, when and for how long.

Being an Alumni Career Service Client isn't their primary relationship with your organization, Alumni is, which you already have a cons code for.  I wouldn't use cons codes for this at all.  Maybe attributes (if you don't like the actions idea), but then how do you handle when they are no longer using the service?  (Please don't say "Former Alumni Career Service Client.")  [;)]

 

I like Josh's suggestion of Action.  If not, I'd go attribute.  I also agree that constituent code is not the place for this. 

My 2 cents...

Vanessa Taylor

Yuriy Iordakiev:
We are College Alumni relations department so we have a primary constituent code "Alumni" We have a consultation service to help alumni find a job. It's called Alumni Career Services. Would you say we can track Alumni who use this service with a constituent code "Alumni Career Service Client"? Is this the best way to track them (with "Date from")? Or attributes are better? Do you think it would be more consistent to use "Alumni Career Service Client" code to avoid confusion with queries? I mean to keep all info in the same place (Bio2-->Constituent Codes)? Thanks!

Agreed with the above that action or attribute would be a better choice than constituent code. Which you choose probably depends on how you intend to use the information. For example, if you add it as an Action, you can use a Action Summary Report to quickly see how many constituents have used the service during a certain timeframe. If you add it as an Attribute, you will have the option of very easily filtering by that in reports so you can see things like giving information for just Alumni Career Services clients. (You can still narrow reports if you go with Action, you'll just need an extra step of selecting from a query.)

Another potential option (although not necessarily a better one) would be to add a relationship record with Alumni Career Services to the Relationships tab. If Alumni Career Services is a record in RE, you could reciprocate the relationship and have a list of all clients show up on the Alumni Career Services record. If it isn't already a record in RE, I would recommend one of the options above over creating one. We haven't quite figured out the best way to utilize the Relationships tab at our organizations...there are a lot of things you can put there, but it's hard to figure out which things are the right ones!

JoAnn Strommen

Vanessa Taylor:
Agreed with the above that action or attribute would be a better choice than constituent code. Which you choose probably depends on how you intend to use the information. For example, if you add it as an Action, you can use a Action Summary Report to quickly see how many constituents have used the service during a certain timeframe. If you add it as an Attribute, you will have the option of very easily filtering by that in reports so you can see things like giving information for just Alumni Career Services clients. (You can still narrow reports if you go with Action, you'll just need an extra step of selecting from a query.)

Another potential option (although not necessarily a better one) would be to add a relationship record with Alumni Career Services to the Relationships tab. If Alumni Career Services is a record in RE, you could reciprocate the relationship and have a list of all clients show up on the Alumni Career Services record. If it isn't already a record in RE, I would recommend one of the options above over creating one. We haven't quite figured out the best way to utilize the Relationships tab at our organizations...there are a lot of things you can put there, but it's hard to figure out which things are the right ones!

Vanessa, Constituent record and relationship might be a really good option. It just depends on what needs to be reported.  I could see that working.

Vanessa Taylor

JoAnn Strommen:

Vanessa, Constituent record and relationship might be a really good option. It just depends on what needs to be reported.  I could see that working.

We have run into a bit of insanity/confusion with departments being added as organization records in RE, particularly when we go to link employees (which record do we use?), so I get nervous about suggesting someone add one! If the service is actually a separate entity from the college I would think creating a record would be less apt to cause problems, and one would hope that process documentation/training should prevent issues in either case (HA!). I think it could be a reasonable option. But as you say (and as usual), the best place to put it will depend on your reporting needs.