One of the big tasks ahead in the Next Generation project is redefining all the ways in which a constituent relates to other constituents. Today we call this Associations and we know that it doesn’t begin to cover all the bases. So just as we have in the past, we need you to help us out with your thoughts on any or all of the following questions:
1. What are the ways that constituents relate to one another, particularly ways that aren't so easy to track in Tessitura today? 2. What are some scenarios that describe ways that your business needs to communicate with different segments of related constituents? (A simple example: “Sometimes I need to send a mailing out with only one piece per household. But if I’m doing the same promotion in an email I need to send it to all the members of the household.”)3. One of the things we struggled with in designing Tessitura the first time was the whole name1/name2 construct. Is there a reason to treat spousal relationships differently than any other type of family/household relationship? 4. What other questions need to be asked about this topic?
Hi All,
Good day.
I think to identify a real world item needs three components.
these are time, object and logic.
in the current Tessitura structure, the time component is missing.
So there is an overlap problem in the constituency process.
the association time frame is not the same time frame as constituency.
So we need a tx_ table to synchronize them.
have fun
Ben
Hello, all,
Lots of great perspectives here. Some of what I was thinking of has already been said. So I guess I'd boil my suggestion down to this - Have separate entity/record types for "people", "households/company/org" (and grouping of people), and "benefits." (Maybe other types?)
"People" entities would have certain, personal pieces of information like name, birth date, e-mail address, phone numbers, etc.
"Household" entities would have information like an address, mailing restrictions, etc.
"Benefit" entities would contain information related to a membership/donation/etc.
Any number of people could be associated to a household/company, using different types of associations. Both individual people or a whole household could be associated with a benefit.
Rules that are set within each benefit would determine which types of associations those benefits are allowed to disseminate down to (and in which direction). There could be simple rules like: parent->child, yes; child->parent, no. Or more complex ones like if a member of a household has made a donation, do the benefits that go along with that apply to whole household, or only certain types of relationships within the household, or only certain types of relationships regardless of if they're in the same household or not. Another example, for a company that has been given an admission discount for its employees, it would be something like: company->employee, yes; employee->company, no.
This would do away with the N1/N2 requirement and allow for much more flexibility in benefit structures. While at the same time, the rulesets would allow for the enforcement of a N1/N2-type structure if it's desired.
-Morgan
Ooops... "(and grouping of people)" should have read "(any grouping of people)".
Hi Morgan,
You can use "More ---> Edit" to modify your post.