Business Manager Roles and Permissions Explained: Who Should Be Able to Do What

Editorial team Spend Ledger

Start with the difference between membership and access

A business-level advertising container brings people, advertising accounts and other business assets together. Its permissions determine who can administer that structure and who can work with particular assets. These are related but distinct forms of access: being part of a business does not necessarily mean someone should be able to manage every asset inside it.

The exact role names and controls vary by platform and may change. The useful principle is to separate broad business administration from specific work. Someone who needs to prepare campaign materials may need access to an advertising account without needing authority to add people, change business settings or manage payment arrangements.

This distinction matters whether a team prepares its own accounts or works with an account provided through an agency. In either arrangement, the team should be clear about who controls the business container, who owns or administers each asset, and what access has been granted to each person or partner. An account is a work tool, not a reason to bypass platform rules. Access should reflect real responsibilities and comply with the platform’s current policies.

Before assigning roles, make an inventory of the business assets the team uses and the work that needs to happen on each. That gives the discussion a practical starting point: access is granted to support a defined task, not simply because someone belongs to the project.

Full administrators: broad authority with broad consequences

A full administrator can generally make changes across the business container. Depending on the platform’s current structure, this may include managing people and partners, changing access, overseeing assets and adjusting business-level settings. Such authority is necessary for some operational duties, but it also carries responsibility for changes that affect other people’s work.

Administrative access should be limited to people who genuinely need to manage the overall structure. A campaign editor, reporting specialist or contractor does not automatically need full control of the business simply because they are experienced or trusted. Giving someone broad permissions for convenience can make it harder to see who is responsible for important changes and can expose assets to unnecessary disruption.

Treat administrator access as an operational role, not a status symbol. Before granting it, agree what the person is expected to manage, how changes should be communicated and how access will be reviewed when responsibilities change. Keep a clear record of who has administrative access and why. When a person no longer needs that authority, update their permissions through the platform’s official controls rather than leaving access in place indefinitely.

Teams should also understand that an administrator’s authority may extend beyond campaign work. The person could be able to change access or business settings that affect the whole team. Review the current platform help and policy pages to confirm what the role permits, rather than relying on an old description or an assumption based on a role name.

Regular members: access for the work they do

A regular member is typically someone added to the business who can receive access to selected assets and tasks without being given full administrative control. This is often the most appropriate starting point for employees and ongoing collaborators whose work is operational rather than structural.

Membership alone should not be treated as a complete permission plan. The business should still decide which advertising accounts or other relevant assets the person needs, and what actions they are expected to perform. A person who reviews campaign performance may need report access, while someone who builds and edits campaigns may need additional permissions. Neither role necessarily calls for control over billing or the ability to add more people.

Use task descriptions rather than job titles when deciding access. Titles can be broad, change over time or mean different things across teams. A useful question is: what must this person be able to do to complete their assigned work? Grant the access that supports those actions, then check whether the platform offers a narrower permission that is sufficient.

Regular membership can also help maintain clear boundaries between business administration and campaign operations. If a person needs broader authority temporarily, define the purpose and review the grant when that work ends. Avoid turning temporary access into permanent access by default.

Partner access: work across a business boundary

Partner access is designed for a separate business or external provider that needs to work with selected assets. It is different from adding every person at the partner organisation as a member of the client’s business. The partner can then manage its own team’s access, while the business granting access retains responsibility for deciding which assets and permissions to share.

This arrangement can be useful when an agency prepares or manages advertising work. It does not mean the agency should receive unrestricted control. The client and provider should agree which assets are involved, what work the provider will perform, who is allowed to change campaign settings, and who is responsible for payment arrangements and reporting.

Put those expectations in writing. Clarify who controls the business container and advertising accounts, who can add or remove people, how access will be changed when the work ends, and how billing responsibilities are handled. Also agree how campaign records and reporting will be made available. The platform’s permissions show what a partner can do technically; the written agreement should explain what the partner is expected and permitted to do operationally.

Partner access should be granted using the platform’s official process and only to the genuine business relationship. Do not use it to conceal who is responsible for an account or to avoid a restriction. If a platform limits access or requests verification, address the underlying issue through its official support or appeal channels.

Per-asset permissions: match access to the task

Within a business container, permissions can often be assigned separately for particular assets. The available controls vary, but common work categories include creating or editing campaigns, viewing reports and managing billing. These tasks should not be treated as interchangeable.

Campaign permissions should go to people who need to create, edit or manage advertising activity. Report access may be enough for someone who evaluates performance but does not change campaigns. Billing access should be restricted to people responsible for payment administration or financial oversight. A person may need more than one category, but each should be granted for a clear reason.

Separating who can spend from who can edit is especially useful. A campaign operator may be allowed to prepare or change campaigns while financial controls remain with an authorised finance or business administrator. Conversely, a finance reviewer may need to examine payment information without changing campaign settings. The platform may not offer a perfect division in every case, so check what each permission actually allows and document any limits that must be handled through team procedures.

The goal is not to make work difficult. It is to avoid giving a person a consequential permission when their task does not require it. If the permission names are unclear, consult the platform’s current help pages before assigning access.

Least access needed: a practical rule for every grant

The least-access principle is straightforward: give each person or partner only the permissions needed for their current responsibilities. This reduces accidental changes, helps keep financial authority distinct from campaign work and makes it easier to understand who can take a particular action.

Apply the principle when access is first granted, and revisit it when duties change. A person who moves from reporting to campaign management may need different permissions. A contractor whose work has ended should not keep access simply because removing it was overlooked. A partner should not retain access to assets that are no longer part of the agreed work.

Before making a change, check the platform’s current description of the relevant role or permission. Names can sound similar while allowing different actions, and interfaces can change. Keep a basic access record outside the platform if that helps the team track the reason for each grant, the person responsible for approving it and the conditions for reviewing it. Do not record passwords or other sensitive authentication details in that record.

Least access is not a substitute for sound account ownership, secure working practices or compliance with platform policies. It is one part of a wider operating process. If a permission problem results from a platform restriction, do not create replacement access to get around it. Use the official support and appeal channels and correct the cause.

A permission matrix the team can fill in

A simple matrix can turn broad role discussions into specific decisions. Create a row for each person or partner, and columns for the business role, assets needed, campaign work, report access, billing access, administrative authority and reason for access. Add a review note if the team needs to record when a responsibility changes. Leave a cell blank where access is not needed.

| Person or partner | Business role | Assets needed | Create or edit campaigns | View reports | Manage billing | Administer business | Reason and review note | |---|---|---|---|---|---|---|---| | | | | | | | | | | | | | | | | | | | | | | | | | | |

For each row, mark the permission as needed, not needed or requiring confirmation. Do not assume that a person needs every permission because they need one. For example, campaign work does not automatically require billing access, and report access does not automatically require campaign editing.

The matrix is a planning aid, not a substitute for the platform’s actual permission controls. Check that the permissions selected in the business interface match the decisions recorded in the matrix. If the platform combines permissions that the team would prefer to separate, note the limitation and agree on a process for managing it.

Review access and keep the structure understandable

Permissions can become outdated as teams, projects and agency arrangements change. Make access review part of ordinary account administration. Compare the people and partners with access against current responsibilities, confirm that each asset is still needed and remove permissions that no longer support active work.

When a working relationship changes or ends, follow the platform’s official process to update access. Consider the effect on ongoing campaigns, reporting and billing before making changes, and coordinate with the people responsible for those functions. Do not assume that changing a person’s business membership automatically resolves every asset-level permission; verify the relevant access in the platform.

Keep the structure understandable to someone who did not set it up. Use clear internal descriptions for why access exists, maintain written agreements with external providers and make responsibilities explicit. If an account is supplied or administered by an agency, establish who controls it and how the client’s team can obtain the information needed for its work. Do not treat access arrangements as a substitute for clear ownership and accountability.

Business roles work best when they reflect real duties. Reserve broad administration for people responsible for the business structure, use regular membership for internal operational work, and grant partners access only to agreed assets. Within those boundaries, distinguish campaign editing, reporting and billing wherever the platform allows. Review the platform’s current help and policy pages for role definitions, permission details and any current requirements.