Get started with UnionStack

What this guide helps you accomplish

Use the first session to prove one complete outcome. The dashboard, navigation and connected-record model make more sense after the team has agreed on what it is trying to accomplish.

Before you begin

• Administrator access to a UnionStack test organization and a written description of the procedure you are configuring.
• A small set of fake records that covers an ordinary example and at least one exception.
• A named configuration owner who can approve terminology, access and any change to shared settings.
• A 60-minute pilot session with the administrator and at least one everyday user.

Procedure

1. Define the first useful outcome

   Choose one practical workflow, such as member lookup or grievance intake, that the first configuration must support. A narrow first outcome makes terminology, access and testing decisions easier.

2. Map your vocabulary

   List the names your union uses for people, entities, positions, cases and leaders. Configure UnionStack types and fields to match language staff already understand.

3. Confirm administrators and users

   Decide who can configure settings, who performs everyday work and which groups need distinct access. Invite a small initial working group before the full team.

4. Model structure before bulk data

   Create the core organizational types and relationships before entering large numbers of people. People and positions become more useful when there is a stable structure behind them.

5. Test one complete workflow

   Configure one representative case or member procedure and walk it from beginning to end with sample data. Record questions and adjust the configuration before expanding.

6. Connect services deliberately

   Add email, Mailchimp, API credentials or Sites after the core records and access model have been reviewed. Test every connection with controlled sample data first.

Product view

Troubleshooting

The team starts configuring every module at once

Return to the first useful outcome and defer settings that do not affect it. Record later ideas in a decision log instead of implementing them during orientation.

Users describe the same concept with different names

Pause configuration and reconcile the labels used in policies, forms and everyday work. Choose one preferred term and document any legacy synonyms for onboarding.

A pilot user can see too much or too little

Compare the user’s actual responsibility with the planned access matrix. Correct the role or group assignment, then repeat the test with a second representative account.

The configuration works only for the sample record

Add an unusual but valid scenario and trace it through the same procedure. Adjust the model only when the difference affects a real decision, relationship or report.

Validation checklist

• The pilot team can sign in, find the target record and explain the next action from the dashboard.
• A second administrator can explain the configuration and its owner without relying on undocumented knowledge.
• A pilot user can complete the intended task without a spreadsheet, private note or duplicate record.
• Names, statuses and structured choices match the approved terminology list.
• Access was tested with representative non-administrator accounts.

Version applicability