# Invite your team and keep a history

> Admin, Editor or Viewer on each system, and a named version before every big change so a restore is one click.

- Source: https://flashdsm.com/blog/team-roles-and-history
- Published: 2026-09-11
- Author: Flash DSM Team
- Track: Learn Flash
- Reading time: 5 min read

---

## Open the People panel

Once a second person edits tokens, you need to know who may change what, and you need a way back when someone gets it wrong. In Flash those are the People panel and Version History.

You can get to People from two places:

- In the editor, open the menu next to the system's name and choose **People…**
- On the dashboard, open a project card's menu and choose **People…**

The panel lists everyone on the system with their role, plus any pending invites. Inviting collaborators starts on the Team plan.

## Roles, and who can do what

Every system has one **Owner**, the person who created it. Everyone else is an **Admin**, an **Editor** or a **Viewer**.

| | Owner | Admin | Editor | Viewer |
|---|---|---|---|---|
| Read the system and export it | Yes | Yes | Yes | Yes |
| Edit tokens, components, modules | Yes | Yes | Yes | No |
| Save a version | Yes | Yes | Yes | No |
| Invite, change roles, remove people | Yes | Yes | No | No |
| Publish the live sync link or MCP access | Yes | Yes | No | No |
| Invitee needs a paid plan to accept | - | Yes | Yes | No |

The split between Admin and Editor is on purpose. Changing a colour and publishing the system to the internet are different decisions. An editor can do the first all day. Only an admin can do the second.

Viewing is free for the invitee. Editing a shared system needs a paid plan, so a viewer invite never costs your stakeholder anything. If you invite someone as an editor and they have no plan, they see "Upgrade to accept" in their inbox. Asking for view access instead is always free.

A viewer who opens the editor sees a banner: "You have view access to {system}. Nothing you change here is saved." They can move things around to explore and nothing sticks.

## Sending invites

Click **Invite**, type an email address, pick a role, send. Flash emails the link, and the invite shows up under **Pending invites** with a **Copy link** button and a **Revoke** button.

Copy the link and send it yourself, in Slack or wherever your team actually reads things. As the panel says, it's the surest way to get someone in. The link opens `/invite/<token>`, a page titled "Join {system}" with **Sign in to accept** and **Create an account**.

- **The email doesn't have to match.** "Sent to {email}. Signing in with a different address works too." Someone with a personal and a work account can accept with either.
- **In-app invites need a verified email.** Invites also appear in the invitee's dashboard under **Shared with you**, with **Accept** and **Decline**, but only after they verify their address. If someone says they can't see your invite, that's usually why. The link works either way.

Revoke any pending invite you no longer want. Someone who left the team gets **Remove**, and anyone can **Leave system** on their own.

## Save a version before a big change

Flash checkpoints automatically while you work, so there is always something to go back to. Autosaves are unnamed, though, and a list of forty checkpoints from Tuesday doesn't tell you which one was before the rebrand. Save a named version before any change you might want to undo as a unit.

Open [[Version History]]. The page is titled **History** and has three tabs: **Timeline**, **Compare** and **Releases**. Click the add button next to the title, the one labelled **Save a version**:

1. Under **What changed**, write the change in a sentence. The placeholder, "Warmed up the neutrals", is the right length.
2. Pick a **Release type**: **Patch** (bug fixes), **Minor** (new features) or **Major** (breaking changes).
3. The dialog shows the number it will get, for example "Saves as v1.4.0". Click **Save version**.

Use the release types the way you would for code. Renaming or removing a token breaks every file that referenced it, so that's a major. Adding a spacing step is a minor. Nudging a hex value by a few points is a patch. [Versioning a design system](/blog/versioning-a-design-system) goes further into where to draw those lines.

Select any version in the timeline and you get who saved it, when, and counts of its tokens, colours and components. You can rename it later or delete it.

## Compare any two versions

The **Compare** tab has two pickers, **From** and **To**. Pick two versions, autosaves included, and you get a token-level diff: what changed, what was added, what was removed. When nothing moved you'll see "Nothing moved since the previous version".

Before you restore, compare the version you're about to go back to against the current state, so you know what you're throwing away. Before a release, compare it against the last one you shipped, so you have the changelog's raw material.

## Restore a version

Pick a version and choose restore. Flash asks "Restore v1.3.0?" and spells out what happens: your current tokens and components are replaced by that version, and Flash first saves a copy of where you are now, so you can come straight back.

If a restore turns out to be wrong, restore the copy it made.

> [!NOTE]
> Version history and diffs are a Team feature. On a system that only exists in your browser, History reads "Not saved yet": save it to your workspace and Flash starts keeping versions.

## A workflow that holds up

Here's what we'd set up for a team of four to ten:

1. One or two **Admins**, usually the design system lead and an engineering lead. They own sharing and people.
2. Designers and front-end engineers who change tokens as **Editors**.
3. PMs, stakeholders and clients as **Viewers**. It's free for them, and export still works.
4. Save a named version before any Major or Minor change, every time, even when it feels like overkill.
5. Make the change. Check it in [[Documentation]], which rebuilds from your tokens as you go.
6. **Compare** against the last released version and paste the diff into your changelog or PR description.
7. If a handoff or repo depends on the system, push the change out the same day: see [Get your tokens into code](/blog/export-tokens-to-code) for the GitHub route.