Access is granted by role, not by password: every major platform lets the owner of an account give a third party exactly the permission needed to publish and read metrics, and take it back whenever they want. Sharing credentials breaks at the first two factor change, and it leaves nobody able to say who did what.
Why the shortcut costs you three times
Asking for the password looks faster on day one, and it is. The trouble arrives later, and it always arrives through one of these three doors.
The first is technical and turns up on its own. The account has two factor verification, the code goes to the phone of somebody who is on holiday, and your community manager is left staring at a confirmation screen at nine on a Tuesday morning. Every time the client changes device it breaks again, and by the fourth time nobody calls it an incident any more, they call it how this works.
The second is contractual. The terms of use on these platforms say an account is personal and not transferable, and signing in with somebody else's credentials breaks them even when that somebody gave you permission. The day there is an argument about who published what, or you need something from platform support, your position is worse than that of somebody who had no access at all.
The third costs the most money and is the hardest to see coming: there is no trail. When four people sign in as the same user, the question of who deleted that post has no possible answer, not from you and not from the platform. A delegated role, by contrast, leaves a name on every action.
What to ask for on each platform
Every platform that matters has delegated access, and the gesture is the same everywhere: the client keeps ownership and grants you a bounded role over one specific asset. What changes is where that button lives and what the role is called.
| Platform | Where it is granted | The minimum you need | What not to ask for |
|---|---|---|---|
| Instagram and Facebook | The client Business Manager, over their page and account | Partner access to publish and read insights | Their personal Facebook login |
| The company page itself, in its admin list | A content admin role | To be left as the only super admin | |
| TikTok | The client Business Center, over the account and the ad account | A member role with that account assigned | Their email and password |
| YouTube | Channel permissions, from the account that owns it | A role that allows uploading and reading analytics | Their Google account password |
| Google Business | The business listing, in its users section | A manager role over the listing | Ownership of the listing |
| Their business account, through partner access | Access to the profile and the ad account | That the profile be created under your name |
There is a prior question that saves half the emails: who administers each of these today. In more than half of new accounts, the client does not know. The Facebook page was created by an intern in 2019, the Google listing was claimed by the owner with a personal address and the ad account hangs off the previous agency. Finding out is detective work and it belongs on day one, because each of those threads takes its own time to pull.
One warning about the role you ask for: ask for the minimum, but ask for the minimum that works. A role that is too narrow does not fail on day one. It fails on the day you try to publish a reel or read one specific metric, which tends to be the day you had already promised the report. Checking every granted permission by publishing a test piece is the step that turns a list into a fact.
Connecting an account in a tool and holding a role on the platform are two different things and you need both. The role is granted by the client inside Meta, LinkedIn or Google; the connection is authorised afterwards, on the platform's own screen, and it inherits exactly what that role allows and nothing more.
What a connected account actually holds here
This deserves precision, because the category is full of promises that do not hold up. Connecting an account here is an authorisation granted on the network's own screen by whoever holds the role over that account, not a form where credentials get typed in. The client's password is never asked for at any point in the process, nor anybody's, which is why there is no client password stored anywhere either.
That authorisation lives where it was granted. The person who gave it can withdraw it from the platform's settings whenever they like, without going through you and without telling you, and that is the correct behaviour even on the occasions when it is inconvenient. What gets connected is a borrowed permission, not a handed over key.
One distinction is worth having straight before you build the team around it. Connected social accounts belong to the brand and are used by whoever holds the permission inside the workspace. Google Calendar and Google Drive connections, by contrast, belong to each person: everyone links their own Google account from their own session, and the link refuses a Google account that is not the one signed in. When somebody on your team leaves, what leaves with them is their personal Google link, not the client's social connections.
Inside the workspace, who can publish with a connected account is not decided by the platform. You decide it with roles and permissions, and that is the second half of this conversation: it is in roles and permissions.
And when somebody on your team is missing one of those permissions, the route is not to message you: they request it from the same screen that just refused them, with a reason, and it reaches somebody who can grant it. That is what access requests are for, and explaining it on day one is what stops anybody borrowing a colleague's login, which is the domestic version of exactly the mistake this article is about.
The short route: let them connect it
The recommended way to connect an account does not go through you at all. The client signs in to their portal, opens the connections row and authorises their own accounts from there. Nobody shares credentials with anybody, the authorisation sits under their name, and on the day the work ends it is withdrawn from the same place it was given.
It has a side effect people do not anticipate: it turns access into a decision of theirs rather than a favour they are doing you. A client who has authorised three accounts with their own finger understands far better what they are allowing, and the awkward questions of month six stop existing because they were already answered in week one. What they see and what they do not is covered on the client portal page.
Everything in this article happens in one place in GoFeed.
Try it freeWho owns the accounts when this ends
The temptation on day one is to create whatever is missing yourself. The client has no LinkedIn company page, no ad account, no Google listing, and setting it up with your own address takes ten minutes instead of three emails. Those ten minutes get paid back in full eighteen months later.
An account created under your name is an account that will have to be handed back, and the handover never lands in a quiet week: it lands in the week somebody has decided to change supplier. Until then it is a risk for both sides, because a business's whole history of posts, ads and audiences is hanging off a person who does not work there.
The practical rule is short. Whatever gets created, gets created from an account belonging to the client, in front of them if necessary, and you come in afterwards as an invited administrator. If the client has nobody who can do it, it still gets created under their name and the credentials are handed over the same day, through a channel that is not email. Five extra minutes, no awkward conversation.
The access record, and a clean exit
The last thing in this script is the one almost nobody writes down: a list of what was granted, by whom, when and over which asset. It needs nothing sophisticated, a table in the client's file will do, and it gets updated on the day something changes rather than reconstructed from memory on the last one.
That list has two uses. The first is the start: it tells you what is missing when something will not publish, instead of making you test platform by platform all over again. The second is the exit. A relationship that ends well ends with access withdrawn and an email saying exactly which access was withdrawn, and that email can only be written if somebody wrote the list at the beginning. Which accounts connect and what each network does once it is in are covered in supported social networks.
It is worth saying the positive version, because this sounds like paperwork and is not: handing access back cleanly is what makes a client who leaves recommend you anyway. The rest of the first week, with the other four boxes on the checklist, is in the client onboarding guide.
