Best Practices for Using Membership Module

I've definitely considered storing this data here, though have not actually implemented it yet. It seems a natural place to add the info, since it automatically maintains "membership" dates within the structure. For example, with our Board Members, they have a four year term. If I store this in an Attribute or Constituency, I have to set an Action to remind myself to scrub that designation in 4 years, and if a Board Member serves 2 terms I have to enter 2 separate Attributes (clutter!) to maintain the historical data. Memberships does this automatically because you can set an “expiration date” to their membership term.

Relationships could be another very good place, but it becomes harder to filter historical relationships when pulling e/mailing lists. You would need to filter by “From” and “To” dates when pulling queries.

The pro of using Attributes or Constituencies, of course, is that you can then easily pull lists in NXT. Right now, neither Memberships nor Relationships are viable List options in webview.

I think it's viable, but maybe not the best place if you have any other giving programs or giving levels just because of the way that membership ties so well into gifts. Attributes and Constituency Codes work well for these just for ease of reporting.

I think trying to foresee how you may need to pull data for this group may be a big factor in how you proceed. @Faith Murray brings up a good point about the lack of availability in NXT, but eventually that functionality will come (hopefully!)

We use constituent codes and track their service time by using the from and to date. If there is a break in the service and they return we add the code to the record again with the new from date so we can see there was a break in the time line.