- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
Before the training starts, the assistant needs an account of their own, scoped to the clients and areas the job actually touches, with a password nobody else ever sees.
VA onboarding sign in: the access layer underneath the training
Most advice about bringing a virtual assistant into an agency is about what they will do — the tasks, the tone, the escalation rules. training a virtual assistant covers that side well, and the wider first-week onboarding checklist covers the rest of the first week. This piece is about the step that happens before any of it: the sign in. How the account is created, what it can reach, how the password moves from you to them, and how it is switched off later. Get it wrong and the training does not matter, because the person is either locked out of what they need or able to reach what they should not.
One person, one login, always
The shortcut is to hand over the owner’s credentials, or a shared team login, so the new assistant can start today. It works for a day and costs for a year. Every change made through a shared login is attributed to whoever’s name is on it, so when a contact is deleted or a workflow is edited there is no way to know who did it. Two-factor codes go to one phone, so the assistant either cannot get in or has to ask for a code each morning. And revocation means changing a password everyone uses, which is why it never gets done.
An account of their own fixes all three. The activity log names them, the second factor lives on their device, and removing them is one switch that touches nobody else. It costs nothing but a few minutes, and it is the single decision that makes everything below possible.
The three ways to grant access, compared
| Approach | Who did what | Second factor | Removing them |
|---|---|---|---|
| Shared login | Unknown | One phone for everyone | Change a password everyone uses |
| Own login, full access | Named | Their device | One switch |
| Own login, scoped | Named | Their device | One switch, and less to check afterwards |
Choosing the scope before you send the invitation
The invitation is where scope gets decided, and it is easier to decide it before the person is waiting on the other end. Two questions do most of the work. Which client accounts does this person actually need to work in, and which parts of those accounts do they need to touch?
Which accounts
An agency-level user sees every client under the agency; a user added inside one client account sees only that client. A new assistant handling two clients’ inboxes needs to exist in those two accounts and nowhere else. Adding them at the agency level because it is quicker gives them the whole book of business on day one, and it also means a mistake in one client’s settings can happen in any client’s settings.
Which parts
Inside an account, permissions are usually a set of switches by area — conversations, contacts, opportunities, calendars, funnels and sites, automations, settings, billing. Start from the tasks in their SOP and switch on only the areas those tasks live in. Inbox and appointment work needs conversations, contacts and calendars; it does not need the funnel builder, and it almost never needs settings or billing. Where the platform offers it, restrict them to records assigned to them rather than every record in the account, so a misclick on a bulk action has a small blast radius.
This is not a statement of distrust. It is the same reason an SOP with named owners and exceptions names who may do what: the scope is the job description made enforceable. Widen it later, deliberately, as the work widens. Narrowing it later is always harder than it should have been.
Which email address the account should use
An easily missed choice. If the assistant signs in with a personal address, the invitation, the password reset and the second-factor recovery all route through a mailbox you do not control, and if the relationship ends badly you cannot reclaim any of it. For anyone expected to stay more than a few weeks, a mailbox on a domain the agency owns is the better foundation: you can reset it, forward it and close it. It also keeps client notifications from landing in a personal inbox next to somebody else’s agency’s notifications, which is a common arrangement for assistants who work for several firms at once.
How the password should travel
It should not travel at all. The invitation email carries a link that lets the person set their own password, which nobody else ever sees, and the second factor is enrolled on their own phone during that first sign in. If the platform’s invitation flow is not used and a password has to be created for them, treat it as temporary: send it through a channel separate from the one carrying the username, require a change on first login, and never leave it in a chat thread or a task card where it will sit for years. The same discipline as keeping an API credential safe applies to a login — a credential in a message is a credential that has been copied.
The first sign in, done together
- Confirm they are signing in from their own device, not a shared or family machine with saved passwords.
- Enrol the second factor on that device, and confirm a recovery route exists that does not depend on your phone.
- Set their profile time zone to where they actually are. Assignments, task due times and quiet hours all read it, and an assistant in a different hemisphere with the agency’s zone on their profile will schedule things at the wrong hour without ever noticing.
- Have them open each client account they should see, and one they should not, and confirm the second is absent.
- Have them try to open settings or billing and confirm it is refused.
- Assign one real task — a manual action, a conversation — and watch it appear in their queue under their own name.
That last step matters more than it looks. manual actions assigned to a user and the conversation SLA both attribute work to a user, so a login that exists but has never been assigned anything will sit outside every report until the first thing is routed to it.
Keep a record that does not live in your head
Write down, somewhere shared, who has access to which accounts, at what level, since when, and when it is next due for review. an audit trail in a sheet is enough — one row per person, one column per client — and it pays for itself the first time a client asks who can see their data, or the first time an assistant moves on and nobody is sure how many accounts they were in. Store the review date in a real date field rather than as text, and a reminder can count down to it.
The record is also where contact database hygiene meets people rather than contacts: dormant logins are the human equivalent of duplicate records, and a quarterly look at the sheet usually finds one or two that should have gone months ago.
Switching it off is part of switching it on
The last step of onboarding is deciding how offboarding will work, because the day someone leaves is the wrong day to work it out. the offboarding checklist covers the handover; for the sign in specifically, the rule is that the account is removed or deactivated on the day, not at the end of the month, and that anything the person could have seen but did not own — a shared inbox password, a client’s portal login, an API key in a workflow — is rotated the same day. Then their assigned records and open conversations are reassigned, so nothing sits in a queue nobody reads.
None of this is elaborate. It is the boring, one-time cost that turns a helper with your password into a colleague with an account, and why an SOP has to exist before the hire is the same argument made about the work itself.
Frequently Asked Questions
Should a virtual assistant share the agency owner’s login?
No. A shared login makes every change anonymous, ties two-factor codes to one phone, and can only be revoked by changing a password everyone uses. An account of their own gives a named activity trail, a second factor on their device, and one-switch removal.
Should a VA be added at the agency level or inside a client account?
Inside the client accounts they actually work in. An agency-level user sees every client from day one, and a mistake in one account’s settings can then happen in any of them. Widen access later, deliberately, as the work widens.
Which permissions does an inbox and appointments VA need?
Conversations, contacts and calendars, usually with visibility limited to records assigned to them. They do not need the funnel builder, and they almost never need settings or billing. Start from the tasks in their SOP and switch on only the areas those tasks live in.
Should the account use their personal email address?
For anyone staying more than a few weeks, use a mailbox on a domain the agency controls. Password resets and second-factor recovery route through that address, and a personal one cannot be reclaimed if the relationship ends badly.
How should the password be sent to a new VA?
It should not be sent. Use the invitation link so they set their own password and enrol two-factor on their own phone. If a temporary password is unavoidable, send it separately from the username, require a change on first login, and never leave it in a chat thread.
Why does the VA’s profile time zone matter?
Task due times, assignments and messaging quiet hours are read against the user’s profile zone. An assistant in another hemisphere carrying the agency’s zone will schedule and send at the wrong local hour without noticing.
What has to happen on the day a VA leaves?
Deactivate the account that day, rotate anything they could have seen but did not own — shared inbox passwords, client portal logins, API keys in workflows — and reassign their records and open conversations so nothing sits in a queue nobody reads.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.