Constituencies vs Attributes

Hi All,

We are getting ready to do some name captures (with contact information) and are trying to decide if it's better to apply a Constituency to them or an Attribute.  Any advice?  We most likely will be using list manager to pull the info but want to make sure we know all the pros/cons before we decide.  Here is what we have:

 

Constituencies:

 

Pros:

  • Can have it show up on constituent header
  • They have start and end dates
  • Can be controlled with different security objects (Add, change, view)
  • Just create it in TR_Constituency

 

Con

  • Lack of detail, no dropdown.  Their either have it or they don’t.



Attributes:

 

Pros:

  • Can add a subset to the attribute.  Eg: Dropdown to choose from.
  • Can be used with control group

 

Cons

  • A little more work creating them since you have to use multiple tables
  • No end date
Parents
  • I concur with some of the others above: Constituencies are more of a label, a flag to get our attention about something, not really a place to store data. Attributes are better suited to that.

    Re: no end dates. It is certainly possible to create a date-type attribute and to use that as an end date for something. We have had several of these over the years.

    Are you wanting to store the origin, category, create date, or something like that, of these name-captured constituents? I'd suggest creating them with a unique original source (i.e. row in TR_ORIGINAL_SOURCE). We've used that in the past for large imports, which makes them very easy to find them later.



    [edited by: Chris Jensen at 6:02 PM (GMT -6) on 29 Mar 2017]
Reply
  • I concur with some of the others above: Constituencies are more of a label, a flag to get our attention about something, not really a place to store data. Attributes are better suited to that.

    Re: no end dates. It is certainly possible to create a date-type attribute and to use that as an end date for something. We have had several of these over the years.

    Are you wanting to store the origin, category, create date, or something like that, of these name-captured constituents? I'd suggest creating them with a unique original source (i.e. row in TR_ORIGINAL_SOURCE). We've used that in the past for large imports, which makes them very easy to find them later.



    [edited by: Chris Jensen at 6:02 PM (GMT -6) on 29 Mar 2017]
Children
No Data