Add your first client and invite your team
Create a client organization, add a manual contact for it, grant that contact portal access, then add a staff member to your own team with a permission group and see the invite they receive.
What you will have
- Create a client organization with Clients > New Client, and know which fields are required and what a new client defaults to.
- Add a manual contact to that client, and know plainly that a contact is not the same thing as a portal login.
- Grant that same person portal access from the one door that actually does it, and know what happens (and doesn't) when you do.
- Add a staff member to your own team, assign a permission group, and see exactly what they receive.
Why it works this way
A client record and a portal login are two different things that happen to live on the same person. Users > Contacts creates a User row with no role, so it cannot sign in - the page says so outright: "Manual contacts for billing, tickets, and meetings. No portal login required." Only Users > Portal Access grants a sign-in role (Primary Contact, IT Admin, or Billing). Search for the contact by name there and click their result to grant it; if they were already a User (as any Contacts-tab entry is), that grant is instant and silent - no email goes out, because the invite email only fires when Portal Access has to create a brand-new User from scratch. A person who was already a portal user (for example synced in from a connected Microsoft 365 or Google Workspace directory, where every synced user already carries basic read access) gets the same silent, instant grant. One person is the exception: whoever is named under Edit > Primary Contact on the client record is that client's portal owner, and carries the Owner and Full Access badges on Portal Access automatically, keeping every right. The Contacts tab's own Type picker (Billing, Primary, Technical, Other) is a label on the record only and grants no access by itself, even when its value reads Primary - newer builds rename that value "Owner (Designated) Contact" without changing what it does.
Permission groups are the only source of staff rights. There is no per-user override and no role fallback: every staff member holds exactly one Admin Permission Group, and that group's tier (None/View/Edit/Admin) per nav section is the entirety of what they can see and do. Viewer, the least-privileged group, is the default for anyone added without picking one - the Owner promotes them to a real group afterward from the Group column on the Team > Staff list.
Dedicated tech and owning pod both live on the client record, not on the New Client form. A brand-new client is created with Co-Managed IT off, no Default Ticket Assignee (so the pod's own dispatch waterfall picks the tech for every new ticket), and is placed on the instance's default pod automatically - on this trial that's the "Help Desk" pod, visible immediately as the "Pod: Help Desk" badge under the client's name. All three live on Edit > Settings on the client record, not on the creation form.
Steps
Go to Clients and click "+ New Client".
The Clients list opens on the Managed tab. This trial already has one client, Bluebird Dental, from earlier setup; a trial with none yet reads "No clients yet - your first one brings tickets, devices, and billing into the portal" in the same spot. New Client sits at the top right next to Show Inactive either way.
Go to Clients and click "+ New Client". Fill in the client's basics and billing address, then click Create Client.
Only four fields are required: Company Name, Domain, Billing Email, and the billing Street Address / City / State / ZIP. Primary Contact, Contact Email, and Phone are optional plain text on the client record itself - they are not a Contact record and grant no login. Client Type (Managed / Non-Managed) and Identity Provider (Microsoft 365 / Google Workspace / None) only show up because this instance has the MSP module; Identity Provider defaults to Microsoft 365, but None is the honest choice for a client you haven't connected yet. Country defaults to "Use instance default". Shown here filled in with Bluebird Dental's own values, since that client already exists on this trial - Create Client is not clicked a second time.
Fill in the client's basics and billing address, then click Create Client. See the new client record, then open Edit > Settings to see what it defaulted to.
Saving lands you on the client's Overview tab, already showing "Pod: Help Desk" and "No Plan" under its name - the instance's default pod is assigned automatically, with no prompt. Edit > Settings confirms the rest: Status is Onboarding, Client Board is Managed, Portal Access is on, Co-Managed IT is off, and Owning Pod already reads Help Desk. Default Ticket Assignee reads jordan.reyes here - it was pointed at him later, for the SLA response-target walkthrough elsewhere in this trial; a brand-new client instead defaults to "None (use board notification rules)", so the pod's own dispatch waterfall picks the tech for every new ticket.
See the new client record, then open Edit > Settings to see what it defaulted to. Open Users > Contacts, then click "+ Add Contact".
The Contacts tab states its own limits up front: "Manual contacts for billing, tickets, and meetings. No portal login required." and points ahead: "Need to give one of these people portal access instead? Use the Portal Access tab." This trial carries one contact before this step, Priya Shah, from earlier setup, with a Type badge next to her name reading Billing. The Type picker's own options now read Billing, Owner (Designated) Contact, Technical, and Other - the value that used to be labeled Primary is the one now renamed Owner (Designated) Contact, and either way the badge is only a label and grants no portal access by itself.
Open Users > Contacts, then click "+ Add Contact". Fill in a new contact's name, email, type, and job title, then click Create Contact.
Name and Email are the only required fields. Type is a label only, one of Billing, Owner (Designated) Contact, Technical, or Other, and it grants no access by itself; the panel says so directly underneath the field: "Type is a label on the record. It grants nothing. The client's portal owner is the person you name with 'Edit' on the client, under 'Primary Contact'." Priya Shah, the office manager, already carries the Billing label on this client's Contacts tab from earlier setup, so this demo adds a second contact instead: Dana Whitfield, a billing coordinator, also set to Type Billing. This creates a User row with no sign-in role - nothing about this step grants either of them a login. The client's actual portal owner is a separate fact: whoever is named under Edit > Primary Contact. Only that person carries the Owner and Full Access badges on Portal Access automatically - everyone else, including a contact labeled Owner (Designated) Contact here, gets a login only when someone invites them on Portal Access.
Fill in a new contact's name, email, type, and job title, then click Create Contact. Open Users > Portal Access, click "+ Add User", search her name, then click her result to grant access.
The tab's own copy: "Users with elevated roles get additional portal access. All synced users have basic read access by default." Searching "Dana" surfaces Dana Whitfield with a Contact badge - this search returns both existing portal users and manual contacts, so you never have to guess who's who. Clicking her row grants access immediately, defaulted to the Billing role (change it from the row's own dropdown afterward); because she already existed as a Contact, this grant is instant and sends no email.
Open Users > Portal Access, click "+ Add User", search her name, then click her result to grant access. She's listed with portal access - her role is changeable any time from this row.
Dana Whitfield now appears on Portal Access with the Billing role in an editable dropdown next to her name, alongside Priya Shah, granted the same way earlier. This is the client's page now, with both her Contact record (Users > Contacts) and her portal login (Users > Portal Access) in place - two separate facts about the same person. Neither of them carries the Owner or Full Access badges - those belong only to whoever is named under Edit > Primary Contact on this client, the client's actual portal owner.
She's listed with portal access - her role is changeable any time from this row. Go to Team > Staff, click "Add Staff", enter an email, pick a permission group, then click Add.
Add Staff asks for two things, Email and Role (labeled Role (required)) - no name field, and no pod picker on a single-pod instance like this one, which auto-enrolls every new hire into its one pod. The Role list is every built-in group except Owner: Full Admin, Service Manager, Senior Tech, Help Desk Tech, Account Manager, Billing Admin, and Viewer (read-only, and the safest group to start someone on). No group is picked for you: the Role field opens on "Select a role..." and Add stays greyed out until the email and a role are both set, and the group you choose is the group the account is created with. The dialog says as much under its own title: "Invite by email and assign a role." Jordan Reyes, an earlier hire, is already on this trial's team as Help Desk Tech - "Day-to-day ticket workers. Edit tickets + log time + write KB. View-only on clients and devices." This demo adds a second technician the same way, Renee Castillo, also set to Help Desk Tech. Full Admin and Service Manager hold admin-tier access to Team, which is why they alone can reach Staff Roles; the other five groups get view-only there, so Staff Roles doesn't even show in their nav.
Go to Team > Staff, click "Add Staff", enter an email, pick a permission group, then click Add. See the new team member and, if the invite email couldn't send, copy the link yourself.
Renee Castillo now appears on the Staff list, active, already placed in the Help Desk pod, with Help Desk Tech as her group - right below Jordan Reyes, the technician added earlier the same way. Adding a brand-new person also mints a 7-day magic-link invite and tries to email it; this trial has no email provider configured, so the page surfaced it instead: "Couldn't email [email protected] automatically (no email provider configured or send failed). Copy this link and share it directly - it's valid for 7 days." The person she replaces this way - or anyone whose invite email did go out - clicks the same kind of link and lands signed in on /admin directly; no password is ever set. Promoting someone who already has a User row (an existing contact or synced user) never shows this panel, because that path never sends an invite at all.
See the new team member and, if the invite email couldn't send, copy the link yourself.
Other ways to do this
Integrations > Matching > Create
When switching from a PSA, create a client straight from a matched external company. It carries over the name, domain, contact name and email, and billing email/address/city/state/ZIP - but not the external system IDs or the phone number, and QuickBooks is still checked for an existing customer first.
Connect Microsoft 365 or Google Workspace (client's Integrations tab)
Once connected for a client, its whole directory appears under that client's Users > Synced automatically, with basic read access already in place for each of them - no manual Contact or Add Staff step per person.
Elise
Ask Elise, in chat, to create a client organization or grant someone portal access on a client - both are things Elise can do directly. Elise cannot add a manual Contact or add a staff member to your own team; those two stay UI-only.
If it did not work
- If the invite link 404s or the recipient can't sign in with it, there's no resend on the row itself - remove them from the team from the row's menu and add them again with Add Staff to mint a fresh link. Links are single-purpose and expire after 7 days.
- If a contact says they can't sign in, check Users > Portal Access on their client - a name that only shows on Users > Contacts was never granted a role and was never expected to be able to. The one exception is whoever is named under Edit > Primary Contact: that person is the client's portal owner and carries Owner and Full Access on Portal Access automatically, whether or not they were ever added as a Contact.
- If a new staff member can't see a page you expected them to, check their permission group on the Team > Staff Group column, not their account itself - every admin.* right comes from that one group, with no per-user override.
- If you picked the wrong permission group when adding staff, change it any time from the Group dropdown on their Team > Staff row - no need to remove and re-add them.
Questions this page answers
What is a Managed client, and what is a Non-Managed one?
Managed clients are the ones you run day to day across the systems you have linked. Non-Managed clients are invoice only. You pick from the Client Type list on the new client form. That list shows only when the MSP module is on. Without it, every new client is Managed. Your pick puts the client on the board of the same name. Internal is a third type, but you cannot pick it. It is the one record for your own company. Boards live at Settings > Clients > Client Boards. You can add and rename boards there. Take care: matching goes by name. Rename the Managed board and new managed clients fall to the default board instead.
How do I manage who can sign in from a client?
Open the client, go to Users, then Portal Access. The Portal Users card lists everyone who can sign in. Each row has a picker with three roles: Primary Contact, IT Admin and Billing. Your own client groups sit in the same picker under those. A new person starts on Billing. What a person can see comes from their role or group. There is no per person grid here. The client owner has no picker at all. They carry an Owner badge and a Full Access badge and always keep everything. To take access away, use Remove. That person drops back to plain user access.
What can each client portal role do?
There are four. User works their own tickets and can read docs, their own vault and training. Billing adds invoices, devices, licenses, meetings and the payment card page. IT Admin runs the place day to day. It can read invoices but not pay them, and it can edit people rather than fully manage them. Primary Contact is the same again, plus full control of people and client settings. The client owner sits above all four. They keep full access and carry an Owner badge.
Do people added here get a portal login?
Contacts are the people on file for this client. Most never get a login. The client's portal owner is the person you name with "Edit" on the client, under "Primary Contact". That person carries the "Owner" and "Full Access" badges on "Portal Access" and keeps every right. The "Type" picker on this tab is only a label on the record. That includes "Owner (Designated) Contact". It grants nothing. Anyone else gets a login only when you invite them on "Portal Access".
How do I add a team member?
Go to Team > Staff and click "Add Staff". Enter the person's email address, choose the permission group that sets their access, and pick a pod if your instance has more than one, then click Add. The group is required: Add stays disabled until you choose one, and the group you choose is the group they are created with. They are added as staff and sent a sign-in link. You can change their access later from the Group column on the Staff list.
Was this helpful?