Invite team members and assign roles

2 min read · Updated Sep 11, 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

Workspace → 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. Tenant Admins start with both switches on, so a new workspace admin can open Sales and its management tools right away. Both remain per-person: turn either one off for any admin who should not be in the CRM.

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, the sales 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 active column

The Members list carries a Last active column so you can see at a glance who's actually using the workspace. It reads Today or Yesterday for recent activity, a date before that, and "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. It counts real use of Current, not just the last time somebody typed a password: if your team signs in through Microsoft, their session can stay valid for weeks, so a sign-in date would show them as absent while they worked in Current every day.

Note

Setup and training progress

Each person's setup and training steps live in the three-dot menu at the end of their row, under Setup & training. It opens under the row and lists every step that applies to them, with the date each one was finished and a key to the marks. Steps that were never theirs to do are simply not listed.

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 an identity provider (Microsoft Entra ID, Okta, Google Workspace), anyone on a domain you verified 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. Registering that provider is also what makes single sign-on the only way in for everyone on those domains, Tenant Admins included: it is not a switch you flip afterwards and there is no exemption to grant. See "Set up single sign-on (Microsoft Entra ID, Okta, Google Workspace)".

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

How you find out somebody is waiting

You don't have to keep checking. The moment somebody lands in the queue, every admin in the workspace gets an email and a notification in the bell, and a notice appears at the top of every page in Current with a Review link straight to this section. The notice has an X: dismissing it hides it until somebody new signs in, so you can clear it without losing the next person. Only the workspace whose domain that person's email belongs to is told — or, for somebody at an outside domain, the workspace that invited them. Nobody is emailed about a sign-in they couldn't approve.

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