Skip to content
UnionStack logo UnionStack

UnionStack blog · Union management software

Union member database and relationship management

Design member records around positions, terms, workplaces, bargaining units, representation and dependable data governance.

UnionStack people records populated with fake member names and relationship data
UnionStack people records using fake data to demonstrate how member identity can connect to positions and organizational context. Screenshot from the UnionStack 2.0 test environment using fake data.

A union member database becomes useful when it explains relationships, not only identity. Staff may need to know a person’s current position, workplace, bargaining unit, local, leadership term, active case or upcoming meeting. Those connections determine how the record supports representation and administration.

Separate the person from the person’s changing roles

A person’s core identity should not need to be recreated when their position, employer, workplace or union role changes. Model the person once, then connect time-bound or contextual relationships around that record.

This supports a clearer history. Instead of replacing “Workplace A” with “Workplace B” in a text field, the system can record the current relationship and retain approved historical information where the union needs it.

Model organizational context explicitly

Union structures can include national or provincial organizations, regions, locals, employers, bargaining units, workplaces, committees and other entities. Some relationships are hierarchical; others cross that hierarchy.

Start with a representative branch. Create one local, employer, bargaining unit and workplace, then connect several people and positions. Use that model in a grievance, meeting, report or site before expanding it across the organization.

Use positions for employment and representation context

A position can connect the person to the place and terms relevant to their work. Depending on the union’s model, it may include status, effective dates, steps, pay rates or dues information. Buyers should verify the exact data required and whether a specialized payroll, remittance, accounting or payment system remains authoritative.

Leadership is another time-bound relationship. A president, steward or committee role should be connected to the applicable organization and term rather than copied permanently into the person’s identity.

Choose fields according to purpose

For every member field, answer four questions:

  1. Who supplies and maintains the information?
  2. What decision or procedure uses it?
  3. Does it need a controlled value for filtering or reporting?
  4. Who is authorized to see it and how long should it be retained?

Use configured choices for values that need consistent interpretation. Use notes for narrative context. Avoid collecting information simply because an old spreadsheet contained a column.

Prevent duplicates through process and identifiers

Name matching alone is unreliable. People share names, names change and source systems format them differently. Define approved identifiers, search before creation and give users a correction path when they find a likely duplicate.

Migration should include duplicate profiling and an exception register. Do not merge records automatically when the evidence is ambiguous. The migration guide includes mapping and reconciliation controls.

Connect member activity instead of duplicating it

A member may be related to cases, meetings, email conversations, notes, documents, entities and leadership terms. Relationships let each record remain authoritative for its own purpose while still being discoverable from the person.

For example, the grievance record should hold the case procedure and evidence. The person record can expose that relationship without becoming a second grievance file. An email conversation can remain intact while being related to both the person and case.

Evaluate reporting with agreed definitions

A count of “active members” is meaningful only when the organization agrees on active status, effective dates, multiple positions and exceptions. Document report definitions, test edge cases and reconcile a sample against the authoritative source.

Ask vendors to create the report from the member records entered during the demonstration. This shows whether structured relationships support the question or whether staff must export and recode the data.

Establish ongoing data governance

Assign owners for people types, position types, entity relationships, controlled values and duplicate correction. Review unused fields, stale terms, invalid contacts and disconnected records on a recurring schedule.

UnionStack connects configurable people records with positions, organizational structure, cases, meetings, email and reporting. The membership management page provides feature evidence and buyer tests for these relationships.

Video demonstration

A captioned UnionStack 2.0 demonstration using fake data to create a person record and connect a position.