Skip to content
Current

Invite team members and assign roles

Send an invite, assign a role up front, approve SSO sign-ins, change someone's sign-in email, and what happens when you deactivate someone.

Updated 2 min read
On this page · 5 sections
  1. Sending an invite
  2. Grouping people into teams
  3. Approving SSO sign-ins
  4. Changing someone's sign-in email
  5. Deactivating a member

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

Settings › Users and roles › People. Each row is one person: their role, their access level, their linked PSA resource, their teams, and when they were last active. Click any column heading to sort by it, and click a row to open everything you can change about that person.
  1. 1
    Open Settings › Users and roles › People
    Only Tenant Admins can invite, change roles, or deactivate members.
  2. 2
    Click Invite and pick a role
    Choose from Tenant admin, Project manager, Engineer, vCIO, Finance, Account executive or Read-only, plus Service manager and Dispatcher where your workspace runs its tickets in Current. 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. 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
When every seat is taken
On a subscribed workspace the seat meter under the Members heading shows how many of your purchased seats are in use and how many a pending invite reserves. If you invite someone (or enable a disabled member, or give a read-only viewer a staff role) when every seat is taken, the dialog switches to a seat step: it shows the exact prorated amount for one more seat, and a single click buys it and finishes what you started. Nothing is charged until you approve, and a read-only viewer never takes a seat. Details in "Manage your subscription: seats, plans, cards, and invoices".
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. A Full CRM switch appears beside them for an Account Executive, Project Manager or Engineer: it gives that person the whole CRM on every account in the workspace, including opportunities, notes, Business Reviews, campaigns and website leads, without commissions, coaching, goals, approvals or the team's performance views. For a Sales Manager or Tenant Admin the row reads Included, because leadership already covers it. Only a Tenant Admin can turn it on, nobody can turn it on for themselves, and it turns off if the person becomes a Partner.

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 opportunity 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. The list itself is one line per team (name, kind, lead or manager, how many people, how many projects), and every column sorts. Click a team to see who is actually on it, each person with the role they hold, and to edit or delete it from there.

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
Click a person's row to open their panel; Setup & training is one of its sections. It 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. 1
    Open Settings › Users and roles › People → 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. 2
    Approve with a role
    Approving assigns a role and activates them immediately.
  3. 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.

Changing someone's sign-in email

Nobody can change their own sign-in email. A Tenant Admin changes it for them, and the person confirms the new address from its inbox before anything changes. Use it when someone's address changes, for a new company domain or a new name.

  1. 1
    Open Settings › Users and roles › People and click the person's name
    Their panel opens. Press Change sign-in email under Access to this workspace. You can't change your own, a super admin's, or a disabled member's: another Tenant Admin, or Current support, changes yours.
  2. 2
    Type the new address and send the link
    Current emails a confirmation link to the new address. It works once and expires in 24 hours. Current also tells the current address that a change was asked for, with the new address partly hidden.
  3. 3
    They press Confirm my new email
    The link opens a page with one button, and nothing changes until they press it. From then on the old address no longer signs them in, every device they had remembered asks for a sign-in code once more, and you get a notification. The change is written to the audit log.
Note
A change that is waiting
While a change waits for the person to confirm, their panel shows it with a Cancel this change button. Sending a new link replaces the old one, so only the newest link works. An address that already signs in to Current, has an invitation waiting, or is on your blocked sign-ins list can't be used.
Note
Single sign-on and the new address
Single sign-on follows the email's domain. If the new address is on a domain your workspace signs in with single sign-on, the person signs in that way from now on. If it isn't, they sign in with a password and a code; someone who has never set a password chooses "Forgot password" on the sign-in page. The confirmation email and the confirm page both say which applies.

Deactivating a member

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

  1. 1
    Open Settings › Users and roles › People
    Find the person, click their row, and choose Disable member at the foot of the panel.
  2. 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 right away for someone else. It does not lower your bill: you keep paying for the seats you bought until you lower the allocation on the Billing page, which takes effect at renewal. See "Seats, pricing, and what counts as a user." It also 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
Next →
People in Current who aren't in your PSA

Related articles