Invite users to your organization
Use this guide to bring people into your organization. You'll choose the invite kind, set the role the invite carries, send it, and confirm it was accepted.
- Deployment: SaaS, On-premises
- Role: Owner, Admin
An invite carries the access the person receives. Getting the role right on the invite saves changing it afterward.
Before you begin
To invite someone, you need all of the following:
- Owner or Admin on the organization: Managing users and role grants requires one of these tenant roles. See Roles reference.
- The role you intend to grant: Decide the tenant role before you send, and whether the person also needs a role on a specific work area.
- The invitee's email address, for a named invite: A shareable link invite does not need one.
1. Choose the invite kind
The platform supports two kinds. The following table lists them:
| Kind | Who can accept | Use it for |
|---|---|---|
| Named | One named email address | Inviting a specific person |
| Link | Anyone holding the link, up to the use limit | Onboarding a batch of people at once |
A named invite binds to the email you enter. A link invite can carry a maximum number of uses, and each acceptance increments its use count until the limit or the expiry is reached.
Prefer named invites. A link invite grants access to whoever holds it, so treat one as a credential.
2. Set the role the invite carries
Every invite carries a tenant role. The following table lists the available values:
| Invite role | Access granted on acceptance |
|---|---|
owner | Full control, including billing |
admin | All administration except billing and Owner changes |
user | Access to their own activity only |
There is no invite role for Global viewer. To grant read-only access across every work area, invite the person as user and change their role after they accept.
Optionally, an invite can also carry:
- A work area and a work area role, granting access to one work area on acceptance.
- A group, adding the person to that group on acceptance. Group membership is binary, so a group-targeted invite carries no separate role — but the group's own conferred role applies on acceptance, so check what the group confers before naming it. See Manage access with groups.
An invite that names no work area grants organization-level access only.
3. Set an expiry
Every invite requires an expiry, defaulting to 7 days from when it's sent. An invite past its expiry moves to expired and cannot be accepted, so a fresh invite must be sent. The portal does not cap how far in the future you can set it: an expiry set far in the future stays valid until it, or a use limit on a link invite, is reached.
For a link invite, set a use limit as well as an expiry. A link with no use limit stays usable by anyone who holds it until it expires.
4. Send the invite
Send the invite from the portal. A named invite is emailed to the address you entered. A link invite returns a URL for you to distribute.
Transactional email must be configured for a named invite to reach the recipient. If your organization has not configured email delivery, use a link invite. On-premises, outbound email is one of the four deployment dependencies — see Prepare your environment.
5. Confirm the invite was accepted
Open the pending invites list. Each invite reports a status. The following table lists them:
| Status | Meaning |
|---|---|
pending | Sent, not yet accepted |
accepted | Redeemed, and the grants have been applied |
revoked | Cancelled before acceptance |
expired | Passed its expiry without being accepted |
An invite that reports accepted has already applied its grants. Confirm the person now appears in the members list with the role you intended.
Troubleshooting
The invitee never received a named invite
Named invites depend on transactional email. Confirm your organization has an email provider configured, then resend. As an immediate workaround, send a link invite instead.
The link invite stopped working
A link invite stops accepting new people once it reaches its use limit or its expiry, whichever comes first. Check the use count against the limit, then issue a new link.
The person accepted but cannot see any dashboards
Organization access and work area access are separate. A user invite that named no work area grants no work area membership, so aggregate dashboards stay empty. Grant them a role on the relevant work area. See Roles reference.
The person accepted but sees no activity of their own
Their portal login is not yet linked to the committer identity their commits carry. See No activity appears for a developer.
If this doesn't fix it
Contact support with all of the following. Tickets missing these take longer to resolve:
- The invite kind, the role it carried, and the work area and group it named.
- The invite status and, for a link invite, its use count and maximum uses.
- The invitee's email address and whether they hold an account already.
- Your deployment kind and server version.
Related
- Roles reference — what each role can do before you grant it.
- Create a work area — creating the work area an invite grants access to.
- Work areas — why membership and coverage are separate.
- Members and developers — how a login connects to captured activity.