Junify
Guides

Managing client accounts at an agency

Staff reach client accounts by delegated access, a shared login, or an access tool. That decides whose name the history shows and how hard a staff change is.

Updated October 16, 2026

Agencies that run social profiles, ad accounts or online stores for clients have to decide how they get into each account. That choice decides what you can tell a client after something goes wrong, and how much work a staff change takes. Setup on each platform, such as Google Ads or Meta, is covered in the platform articles.

What managing a client’s account means

Managing a client’s account means your staff can work in an account the client owns. The client stays the owner, and your agency acts within the scope the client gave you. That scope (what you may do) is a separate question from access (whose login is used and who knows the password). A contract can settle the first and leave the second open.

The question matters on both sides. The client lets outside people post, spend and sell under its name. Your agency works in one account per client per platform, so the count multiplies quickly. One staff member may work in the same platform for several clients, on screens that look alike. Posting to the wrong client and logins left behind after a staff change both come from that count and that overlap.

Three ways to get into a client account

The three ways differ in who holds the password and how staff get in.

  1. Delegated access. The account stays under the client’s control, and the client invites your staff through the platform’s own sharing feature. Each person signs in as themselves and never learns the client’s password.
  2. A shared login. The client gives you its username and password, and your team uses them as they are.
  3. An access management tool (access tool for short). Your agency stores the username and password in a tool, and staff sign in through it. Staff never see the password, and the tool records who used each login. A password manager that reveals the password to staff counts as a shared login here, because staff end up knowing it.
  Delegated access Shared login Access tool
What it allows A different permission level for each person Works on any account, whatever the platform offers Staff use accounts without seeing the password, even with no sharing feature
What it can’t do Nothing to use if the platform has no sharing feature Can’t show which person did something To the platform, everyone is still the one shared login
Who the records name The invited person, as far as the platform keeps history The one shared login The person who signed in to the tool
When someone leaves Remove that person on each platform, from the client’s account or your manager account (such as a Google Ads manager account) Ask the client to change the password, then send the new one to everyone who still needs it Stop that person’s access in the tool

A few points don’t fit in the table. Delegated access needs the client to change a setting before you start. A shared login also can’t limit what each person may do. An access tool takes time to set up, but a staff change no longer means a password change.

You don’t have to pick one. A practical setup uses delegated access wherever the platform offers it, then handles the rest with a shared login or an access tool. What is delegated access? explains how it works.

Why shared logins stick around

Delegated access should make shared logins unnecessary, yet they remain. There are three reasons, and your agency can’t remove any of them alone.

First, the platform may offer no way to invite people. If an admin screen has one username and password and nothing else, your options are a shared login or an access tool.

Second, the platform may invite people but keep some actions for the owner. Some settings and screens open only to the owner’s login, so that login gets shared for those tasks. On Meta, for example, only someone with full control of a Facebook Page can give another person access to it. Adding a staff member can then mean using the client admin’s login (how Meta business portfolios handle agency access).

Third, the client may not change its settings. Delegated access starts with the owner sending an invitation. The client may have no one who knows the platform, or may keep putting the request off. Asking in the middle of a contract can also feel awkward. In each case, you keep using the login you were given.

Which platforms fall under which reason changes over time, so the platform articles cover it. What matters is whether each remaining shared login has answers to three questions. Who knows the password? Who used it, and when? What happens when someone leaves?

When clients ask you to explain

The way you get into accounts becomes visible when a client asks you to explain it. That happens at three points.

The first is a security questionnaire, a list of questions a client sends about how you protect its data. California’s privacy law gives some clients a reason to send one. Under the California Consumer Privacy Act (CCPA), a “business” that discloses consumers’ personal information to a service provider must sign a contract with it (Cal. Civ. Code 1798.100(d)). A “business” here is a for-profit company doing business in California that meets a size or data threshold. A “service provider” processes personal information for the business under a written contract (1798.140(ag)). That contract must let the business take “reasonable and appropriate steps” to help ensure the provider uses the information in line with the business’s own obligations (1798.100(d)(3)). The CCPA regulations say those steps may include assessments or audits at least once every 12 months (11 CCR 7051(a)(6)). A questionnaire about who can get into which account is one way a client can take such a step.

Whether this reaches your agency depends on whether the work touches personal information. Writing and scheduling posts may not. Answering direct messages, collecting contest entries or uploading customer lists for ad targeting does. For work outside the rule, the reason to explain comes from the contract and the client relationship.

The second point is an incident report. After a wrong post or a wrong setting, the client will ask who did it and when. With a shared login, the platform’s history names the login, not the person. You end up matching the history against shift schedules and task lists. Delegated access and an access tool both record each person separately.

The third point is a staff change. You need to show that people who left, or moved off the account, can no longer get in. The work follows the table above. With a shared login you have to ask the client for a new password, and the request itself tells the client that several of your staff knew it.

Where to start

Start with a list of every client account your staff work in, one row per account. Use these columns: client, platform, account, how you get in (delegated, shared or tool), and staff who use it. Add one more for who receives the two-step verification code, the one-time code sent at sign-in. Without this list, you can’t tell what to remove at a staff change. The handover checklist works from it.

Next, pick the accounts you can move to delegated access. Start where the platform supports it and the client is able to send invitations. When you switch, ask the client to change the old shared password, which ends the sharing. Platform steps are in the articles on Google Ads manager accounts and Meta business portfolios. If your team works inside clients’ help desks, see support outsourcing in Zendesk and Freshdesk.

Last, decide how to handle the shared logins that remain. For each one, write down who knows the password, how it gets changed when someone leaves, and how you record who used it. That record can come from an access tool or from a work log kept by hand. Once this is done, you can answer a client’s questions straight from the list.

Articles in this guide

Frequently asked questions

Can staff work in a client account without knowing its password?

Yes, if the platform lets the client invite your staff. If it doesn't, or the client can't change its settings, your options are a shared login or an access tool that signs staff in without showing the password.

What goes wrong with a shared login?

The platform's history names the login, not the person, so you can't say who made a change. Every staff change also means asking the client for a new password and sending it to everyone again.

What should we do first when a staff member leaves?

Pull up every account they used. Remove their invitations, ask clients to change the shared passwords they knew, and stop their access in your tool. Without a list of accounts, you won't know what you missed.

Does the CCPA apply to an agency?

If you process consumers' personal information for a client that is a "business" under the CCPA, its contract with you must let it check how you use that information (Cal. Civ. Code 1798.100(d)).

How Junify handles this

Doing this by hand
You agree with each client on how access is handed over, add and remove people platform by platform whenever staff change, and keep track of which staff member used which client's account.
With Junify
Junify is for platforms with no delegated access, and for tasks only the owner's login can do. Your admin adds the client's login to Junify and picks which staff can use it. Staff verify on their own phone and click to sign in, and never see the password. Each use is recorded under the person's name. Change the password at setup so only Junify holds it, and you can remove someone who rotates off in Junify without asking the client for a new one.

Sources