ContactsLifecycle tracks
One status field forces a lie. A track per relationship you actually have, your own stages on each, and a contact holding a position on every one that applies to them.
A track per relationship. Not one column doing five jobs.
Supporter, volunteer, member: each is its own ladder with its own stages, and somebody stands on all the ones that apply to them at the same time.
- A track per relationship you actually have with people
- Your stage names, your order, your colours
- A contact holds a stage on every track that applies
- One track is the default: its stage is what a single label shows
- Mark the stages that are genuinely end states
And every change, kept. In a log that takes no edits.
Transitions append: what moved, from where to where, and when. Nothing rewrites it, so “when did they lapse” is something you look up rather than reconstruct from memory.
- Every transition appended: from what, to what, when
- Entries are only ever added: nothing edits or deletes one, including us
- So “when did they lapse” is a lookup, not a reconstruction
- And a stage set you reorganize later cannot rewrite it
Three things the tracks won’t do. On purpose.
Archived, not deleted
A track you stop using is archived. The states and the transitions that referenced it stay exactly where they are, because they were true.
One default, enforced
Exactly one live default track per account, enforced by the database rather than by convention, so the single stage label shown across the product is never ambiguous.
Stages don’t move people
A track is a structure and a record. Moving somebody is either an operator action or a workflow you built: never something the track does on its own.
Every relationship, side by side
Your tracks across, your people down, and each cell the stage they are actually at, so a segment can be “lapsed supporters who still volunteer” without a spreadsheet.
Stages say where. The score says how warm.
Because one field forces a lie. A person who gave for six years, stopped, and now volunteers every Saturday is a lapsed donor AND an active volunteer, and a single status column makes you pick, usually by whichever changed most recently. Tracks let both be true.
As many as you have kinds of relationship. Supporter, volunteer, member, partner, alumnus: each with its own stages, and each contact holding a position in whichever apply to them.
Everywhere the product has room for one stage label (a list column, a compact card) it shows the default track’s stage. Exactly one track can be the default at a time, and the database enforces that rather than trusting us to.
Yes, but not from the track. A stage transition is one of the workflow triggers, so you build the consequence as a workflow. The track itself stays a structure and a record, which is what makes the history trustworthy.
New transitions use the new stages; old ones keep saying what they said. The transition log is append-only, so re-planning your supporter journey in 2027 cannot rewrite who lapsed in 2024.