# Team Invitation and Access Request Copy Audit Workflow

> Audit invitation, join, approval, expiry, and access-request copy in Figma so people understand which workspace they are entering and what permission they will receive.

- Canonical page: https://www.hypermatic.com/articles/copydoc-team-invitation-and-access-request-copy-audit-workflow/
- Published: 2026-10-16T00:00:00.000Z
- Updated: 2026-10-16T00:00:00.000Z

For related resources, read [the resource directory](https://www.hypermatic.com/resources/llms.txt). The [site index](https://www.hypermatic.com/llms.txt) links to products and current pricing. Article and tutorial Markdown URLs replace the final slash with .md; product Markdown uses /<plugin>.md.


“You have been invited to join the team” sounds harmless until the recipient belongs to five organisations, the link has expired, their address does not match the invitation, or accepting it grants access to confidential customer work.

Invitation and access-request copy is identity infrastructure. It needs to explain the actor, organisation, resource, role, and consequence consistently across email, browser, product UI, and administrator notifications. [CopyDoc](/copydoc/) can export Figma text for structured review, find repeated language, and sync approved copy back into designs. The team must still reconcile that language with the real permission model and identity system.

## Inventory the entry routes

Start with an experience map, not a terminology spreadsheet. Include every route by which someone can enter or request entry:

- direct invitation to an organisation, workspace, project, or file;
- domain-based or link-based joining;
- request-access flow from a restricted resource;
- administrator approval or denial;
- invitation to an address that already has an account;
- invitation to a new user;
- single sign-on or managed-domain handoff;
- expired, revoked, duplicate, and already-accepted invitations;
- invitation opened while signed into the wrong account.

Capture the associated emails, banners, dialogs, empty states, toasts, and settings rows in Figma. A copy review that covers only the invite modal misses the places where recipients actually become confused.

## Define the permission nouns

Create a small glossary for the hierarchy used by the product. “Team,” “organisation,” “workspace,” “project,” and “group” must not drift between surfaces unless they refer to different objects.

Then define each role in terms of observable capability. “Member” is not self-explanatory. Reviewers need to know whether a member can invite others, create projects, see billing, export data, or access every existing resource.

This workflow is related to the [permission and role copy audit](/articles/copydoc-permission-and-role-copy-audit-workflow-in-figma/), but it focuses on the transition into access: invitations, requests, identity mismatch, acceptance, and expiry. The permission audit goes deeper on managing authority once a person is already inside.

## Audit each message as a five-part promise

Every invitation or request state should make five fields clear where relevant:

| Field | Example question |
| --- | --- |
| Actor | Who invited me or who requested access? |
| Scope | Which organisation, workspace, project, or file is involved? |
| Role | What access will be granted? |
| Action | What will happen when I accept, approve, or deny? |
| Time | Does the invitation expire or require another step? |

Export the relevant text with [CopyDoc](/copydoc/) and place those fields in spreadsheet columns. Missing information becomes obvious when messages are reviewed side by side.

Do not force every surface to repeat all five fields. A small toast can be concise if the preceding dialog supplied the context. The complete journey, however, must not leave the person guessing.

## Write the difficult states first

The happy path tends to get all the attention. Draft these states before polishing the initial invitation:

### Wrong signed-in account

Name the address that received the invitation only when it is safe to do so, explain that the current account is different, and provide a clear switch-account or sign-out path. Do not suggest that the user request another invitation until the mismatch is understood.

### Expired or revoked invitation

Distinguish expiry from revocation if the recovery route differs. Say who can issue a new invitation and whether an access request has been sent. Avoid a dead-end “Invalid link” page.

### Existing membership

If the user already has access, route them to the resource. Do not show an alarming error for a harmless repeat click.

### Approval and denial

Tell administrators what scope and role the requester asked for. Tell requesters whether denial is final, whether they may contact an owner, and whether a reason will be shared.

### Managed identity restrictions

When SSO, verified domains, guest policies, or seat limits block entry, separate the policy from the recovery action. “Contact your administrator” is insufficient if the product knows which administrator or workspace owner can help.

## Keep email and product copy aligned

An invitation email may say “Join Acme,” the landing page may say “Accept workspace invite,” and the product may announce “Project access granted.” These could describe the same event, but the shifting scope makes it impossible to know what was accepted.

Use one content matrix containing subject lines, preheaders, email body copy, browser states, in-product confirmations, and administrator notifications. Assign stable keys to repeated strings. After approval, sync text back into the Figma frames and inspect the full designs with realistic names, roles, and translations.

For the email side, coordinate with the authentication or lifecycle owner. CopyDoc governs the design content; it does not prove that the email is sent to the intended address or that an invitation token is safe.

## Stress-test names, roles, and boundaries

Replace tidy placeholders with fixtures such as:

- a 60-character organisation name;
- two workspaces with nearly identical names;
- a person's name using non-Latin characters;
- a long custom role label;
- a guest invited to one project rather than the whole organisation;
- a user who belongs to several accounts;
- singular and plural request counts;
- an invitation that expires today across different timezones.

Check whether truncation hides the differentiating part of a workspace name or whether a compact mobile button changes from “Approve project access” to the dangerously vague “Approve.”

## Approval checklist

Before copy is released, verify:

- the product hierarchy uses one agreed vocabulary;
- invitations identify actor, scope, and role where needed;
- CTA labels describe the permission consequence;
- wrong-account, expired, revoked, duplicate, and accepted states exist;
- access request and administrator-review copy agree;
- managed-domain and SSO restrictions have actionable recovery;
- email, browser, and product messages describe the same scope;
- realistic long names and translations fit;
- support documentation uses the current terms;
- implementation strings have been reconciled with approved Figma copy.

Good invitation copy does more than sound welcoming. It lets a person understand exactly where they are going, why they have access, and what accepting the invitation will allow them to do.