Invite team members and assign roles

2 min read · Updated Jul 18, 2026

Every person who works inside Current needs a role, and the role decides what they can see the moment they sign in — so it's worth getting right at invite time rather than fixing it after the fact.

Sending an invite

Admin → Users & roles. Each row shows the person's role, their linked PSA resource or member, their CRM access, and when they last signed in.

1
Open Settings → Users & roles
Only Tenant Admins can invite, change roles, or deactivate members.
2
Click Invite and pick a role
Choose from Tenant Admin, Project Manager, Engineer, Account Executive, or Read-only (Partner). Sales Manager isn't assigned as a base role — it's a separate leadership toggle you add to any CRM member afterward. See "Roles & permissions: who sees what" for what each one can do.
3
Send it
They get an email invitation to set up their sign-in. Until they accept, they show up under Pending invitations, with options to resend or revoke.

Note

CRM access is a separate switch

If someone needs into the Sales area, turn on their CRM access toggle — it's independent of their base role. A Sales Manager sub-toggle appears once CRM access is on, giving that person leadership visibility across the whole CRM rather than just their own book.

Grouping people into teams

Below the members list, the Teams panel groups people into named teams. A role sets what someone can do; a team sets who they work with — the two are independent. There are two kinds. A project team is a lead plus the engineers under them: it powers the "My teams" filters on Portfolio, Reports, Schedule, and Calendar, and projects follow the people automatically. A sales team is a sales manager plus their reps (people with CRM access): when a manager runs a sales team, their sales dashboard, reports, and deal views open focused on just that team instead of everyone with CRM access — with "Everyone" still one click away. Teams change defaults and filters, not permissions: a sales manager without a team, and everyone not on a team, sees exactly what they did before. A person can be on one sales team and one project team, but not two of the same kind — so a manager's "My team" view is never ambiguous. When you build a team, anyone already on another team of that kind (whether as its lead or a member) is greyed out in the picker with a note showing which team they're on.

Note

The Last login column

The Members list carries a Last login column so you can see at a glance who's actually using the workspace. It reads "Never" for a member who has been invited and set up but has never signed in — a quick way to spot a seat that isn't being used, or an invite that never got accepted.

Approving SSO sign-ins

The Invite user dialog — pick the role at invite time; it decides what they can see.

If your workspace signs people in through Microsoft Entra ID, anyone in your verified Entra domain can reach Current's sign-in screen before you've ever added them as a member. They authenticate, but Current holds them at a pending screen with no data access until a Tenant Admin approves them — no role, no visibility, nothing synced.

1
Open Settings → Users & roles → Pending SSO sign-ins
Anyone who's signed in via SSO but hasn't been assigned a role shows up here. Each row carries a "Last attempt" line with the date that person last tried to sign in — so you can tell someone actively waiting on you from a login left over months ago.
2
Approve with a role
Approving assigns a role and activates them immediately.
3
Deny, or Delete — they're not the same
Deny blocks that sign-in from reaching the pending screen again but keeps the record, so it's reversible. Delete permanently removes the login altogether — use it for a genuine orphan, like a stray login left behind by an old, torn-down test tenant. Current refuses to delete anyone who already has a real profile in your workspace, so you can't remove an actual member this way.

Note

Super admins: Clear all stale

A Current super admin sees a one-click "Clear all stale" on this screen. It sweeps clearly-abandoned logins — ones older than 7 days whose email domain no live workspace has claimed — the fastest way to clear a backlog of orphaned logins from old test tenants without deleting them one at a time. Recent sign-ins, anyone on a real workspace's claimed domain, denied sign-ins, and anyone with a real profile are all left untouched; a large backlog clears in a few passes.

Deactivating a member

People leave, or roles change enough that starting fresh is cleaner than reassigning.

1
Open Settings → Users & roles
Find the person and choose Deactivate.
2
Confirm
They lose access to every piece of your workspace's data immediately and land on an "access turned off" screen the next time they load the app. Nothing is deleted — their logged time, comments, and history stay intact and attributed to them.

Heads up

Seats, and what deactivating doesn't do

Deactivating frees their seat at your next billing cycle — see "Seats, pricing, and what counts as a user." It does not reassign whatever was still on their plate; move any open tasks or tickets to someone else before or after deactivating. You also can't deactivate yourself, and you can't deactivate the workspace's last remaining admin.

Tip

Changing a role instead

If someone is staying but moving into a different job, change their role rather than deactivating and re-inviting. It takes effect on their next request — no re-login required.

Was this helpful?

← Previous

The partner financial firewall

The audit log: what's recorded and who can read it