Meta Business Manager structure for agencies: the operational playbook

TL;DR

Meta Business Manager (now "Business Portfolio") is where agency access architecture goes right or wrong on the platform that usually carries the most client spend after Google. The structure that survives: the agency runs one Business Portfolio; clients own their own portfolio holding their ad account, Page, and dataset (pixel); the two connect via partner access — the client assigns assets to the agency's portfolio, the agency assigns its own people internally. People from the agency are never added directly to client assets, API pipelines run on system users rather than humans, and a quarterly audit reconciles people + partners against reality. Get the ownership direction wrong — agency-owned ad accounts and pixels "for convenience" — and offboarding means the client loses their account history and their dataset's learning. The cross-platform version of these rules is the multi-account pillar; this is the Meta-specific mechanics, the way the MCC playbook is the Google-specific one.

---

Every agency eventually inherits a Meta setup assembled by accretion: the client's ad account living inside a freelancer's Business Manager from 2021, the pixel owned by a web developer who left, three agency employees added as people directly on the ad account with personal Facebook logins, and nobody sure who can grant whom access to what. Meta's asset-permission model is genuinely more granular than Google's — which means it rewards deliberate structure and punishes improvisation harder.

The model in one paragraph

A Business Portfolio is a container that owns assets (ad accounts, Pages, datasets, catalogs, domains) and grants access two ways: to people (individuals in your business) and to partners (other Business Portfolios). The entire agency architecture follows from one rule: ownership stays with the business the asset describes; access flows through partnership. The client's portfolio owns the ad account, the Page, and the dataset. The agency's portfolio is added as a partner and receives assigned assets. Inside the agency portfolio, the agency assigns its own people to those partner assets — without the client ever managing (or even seeing) individual agency staff.

The five structural decisions

1. Partner access, never people access. Adding agency employees directly as people on client assets recreates the personal-login problem: ungoverned, unauditable, and orphaned when someone leaves. Partner access means the client made one grant — to the agency's portfolio — and every staffing change after that is the agency's internal business. Offboarding in either direction is one partner removal, not an archaeology dig through person-level permissions.

2. The client owns the ad account and the dataset — especially the dataset. An ad account carries spend history and billing; a dataset (pixel) carries the event history that ad delivery learns from. Both are useless to the agency after the engagement and load-bearing for the client forever. Creating them inside the agency's portfolio "to move fast" builds the hostage situation the pillar warns about — and on Meta it's worse than on Google, because dataset ownership can't simply be transferred out later without losing the connection structure. New client with no presence: create the client's portfolio first, create assets there, then partner in. Ten minutes now, weeks saved later.

3. One naming convention, business asset groups for the rest. Partner-assigned assets land in the agency portfolio under whatever the client named them — which is how you end up scrolling past four "Main Ad Account"s. Apply the same client slug you use everywhere else (the pillar's one-slug rule), and use business asset groups to bundle each client's assets so per-client access assignment is one action, not five.

4. System users for anything automated. Every API integration — the spend export to BigQuery, CAPI gateways, catalog syncs — runs on a system user: a non-human identity inside the agency portfolio with a long-lived token that survives the org chart. A pipeline on an employee's personal token is scheduled to break on their last day, and it will pick the worst week to do it.

5. Security hygiene as configuration, not intention. Enforce two-factor for everyone in the portfolio (Business Manager has the setting — turn it on), keep portfolio admins to two or three (admin here can remove every other admin; Meta account compromises routinely escalate through over-provisioned BMs), and treat ad-account spending limits as a blast-radius control on compromised access.

The per-client verification pass

Structure decays, so the monthly per-account check from the pillar's cadence gets a Meta-specific checklist: the dataset is receiving events and browser/server deduplication is holding (the discipline from Pixel + CAPI without double counting); the client's domain is verified in their portfolio (not yours — another ownership trap); billing is current and the card on file isn't the one that expires next month; and custom audiences sourced from customer lists are fresher than 60 days. Quarterly, run the people + partner audit on the agency portfolio itself: every person reconciled against the team roster, every partner connection reconciled against the active client list. The standing findings are former employees with admin and former clients still partnered — both one click to fix and both real risks while they persist.

Where this lives operationally

Each client's Meta stack — portfolio, ad account, dataset, Page, the partner edge connecting it to the agency — is structure worth modeling, not memorizing. In Phloz — the CRM for social media agencies — it sits as nodes on the client's tracking infrastructure map with health states and the verification tasks above attached on their cadence, so "dataset stopped receiving events" or "partner access revoked" surfaces as a task, not as a performance mystery three weeks later.

Companion reading: the multi-account pillar for the cross-platform rules, the MCC playbook for the Google mirror of this post, and the Meta-to-BigQuery export guide for what the system user makes possible.