Request-and-Approve Workflow for Access Changes in a Business Container

Editorial team Spend Ledger

Treat access as an operational decision

A business container is a shared work environment in which permissions can affect advertising accounts, billing, audiences, assets and the people responsible for them. Access changes may be routine, such as adding a colleague to a task, or significant, such as granting administrative control. Either way, they should be treated as business decisions rather than informal favors.

A small written workflow helps a team answer five questions: who may request access, who decides, why the change is needed, how it is applied and checked, and where the decision is recorded. The process need not be bureaucratic. Its purpose is to make changes visible, limited to a work need and traceable afterward.

This is especially useful when a team is preparing its own advertising accounts, working with an agency, or managing accounts obtained through a commercial arrangement. An account is a work tool and a purchased good, not a way to bypass platform rules. Ownership, identity checks, account eligibility and other platform requirements remain separate from the team’s internal approval process. The workflow should never be used to disguise who controls an account or to avoid a restriction.

Define who can request and who can approve

Start by identifying the people who may request a change. A request might come from the person responsible for a campaign, a manager coordinating a project, or an operations contact handling a staff change. The requester should be able to explain the work need, but should not automatically be able to grant the access they request.

Approval should come from someone with authority over the relevant business work and the assets involved. In a small team, this may be a business owner or a designated administrator. In a larger organisation, responsibility may be divided: a project lead confirms the work need, while an account or security administrator checks the requested permission and applies it.

Keep the distinction between approval and implementation clear where practical. The person changing permissions should act on an approved request, not infer approval from a conversation or a colleague’s presence in a group chat. If one person must handle both steps in a small team, the record should still show the request, the decision and the change as separate actions.

Make the roles understandable to everyone. People should know where to send a request, who can approve it and whom to contact if the usual approver is unavailable. Do not give broad access simply because the approval route is unclear.

Record a useful justification

A request should explain the task the person needs to perform and the assets or area of work involved. “Needs access for the launch” is less useful than a short description of the work, the relevant account or asset, and the kind of action the person must carry out.

The justification should be specific enough to support a decision without collecting unnecessary personal or confidential information. For example, record that a colleague needs to review campaign performance or prepare billing documentation, rather than adding unrelated details about their employment or private circumstances.

The requester should propose the least extensive permission that appears sufficient for the task. An approver can ask for clarification or suggest a narrower role. If the work changes, the team can submit a new request rather than letting an old permission expand informally.

A useful request record can include:

• The requester and the person who needs access.
• The business reason and the work involved.
• The relevant container, account or asset.
• The permission being requested, described in plain language.
• The approver’s decision and any conditions.
• The person who made the change and confirmation that it was checked.

The team should avoid storing credentials or sensitive authentication material in the request record. Access management is about assigning appropriate permissions through the platform’s supported controls, not sharing passwords.

Make the change and confirm it

After approval, the designated administrator should make the change using the platform’s available access controls. The administrator should follow the platform’s rules and any required identity or verification steps. If the platform does not allow the requested change, or requires an additional review, the team should follow its official instructions rather than trying another route to obtain the same result.

Once the change is made, confirm that the right person received the intended permission on the intended asset. The confirmation should be based on the access information available in the platform, not on an assumption that clicking a control completed the task. If the permission does not match the approved request, correct the discrepancy through the supported process and update the record.

The person receiving access should be told what they are expected to do and which work remains outside their role. This reduces accidental changes and helps the recipient recognise when a request falls beyond their approved responsibilities. For sensitive actions, the team can also document who is responsible for making or reviewing them.

Confirmation does not mean promising that the person will be able to perform every task. Platform settings, account status and policy requirements can affect what is available. If access is blocked or an account is restricted, use the platform’s official support or appeal channels and address the underlying issue. Do not use an access change to evade a restriction.

Keep the record in a dependable place

A workflow is only useful if the record can be found when responsibilities change or a question arises. Choose a central location that the people responsible for access management can use and protect it according to the sensitivity of the information. The record might be an internal request log or a controlled business document; it should not be scattered across private messages, personal notes and informal task comments.

Keep the record focused. It should show what was requested, why, who approved it, what was changed and whether the change was confirmed. Avoid copying more platform data than needed. Do not include passwords, recovery details or identity documents in an ordinary access log.

Make it clear who may edit the record. Where possible, preserve the history of decisions and updates so later readers can distinguish the original request from a correction or removal. If the team uses a separate system to track work, the access record can refer to the relevant internal task without duplicating sensitive information.

The platform’s own help and policy pages are the source for current permission options and account requirements. Internal documents should explain the team’s decision process, not replace platform guidance or invent controls that the platform does not provide.

Choose a light or stricter workflow

A small team can use a light process as long as it remains written and repeatable. A requester sends a short form or message in the agreed channel, a named responsible person approves or declines it, and an administrator records and confirms the change. The same person may perform more than one role when staffing is limited, but the decision should still be visible in the record.

A larger team generally benefits from more separation. It can route requests by asset or business area, require review from both the work owner and an access administrator, and maintain a queue for changes awaiting action. The record can also capture why a request was declined, what clarification was needed, and when access was later revised or removed.

The difference is not simply the amount of paperwork. A light workflow should still prevent unrecorded changes; a stricter workflow should not create delays that encourage people to bypass the process. Match the checks to the business risk, the sensitivity of the assets and the team’s ability to administer permissions. Current platform roles and available controls should be confirmed in the platform’s own help and policy pages.

For work involving an agency or another external partner, agree in writing which party may request, approve, apply and review access changes. Clarify the assets covered, the purpose of the access and how it will be handled when the work ends. A commercial arrangement does not override platform rules, and an external provider should not be asked to conceal control or bypass verification.

Review access and prevent permission creep

Permission creep happens when access granted for a particular task remains in place after the task changes or ends, or when small informal additions accumulate without an overall review. A written workflow reduces this risk because each grant has a recorded purpose and an accountable decision-maker. The record gives the team a basis for asking whether the permission still fits the work.

Review access when responsibilities change, a project closes, a partner’s engagement ends or an account’s operating needs change. Compare the permissions in the platform with the team’s current records. If a permission is no longer needed, have an authorised person remove or adjust it through supported controls, then record the action and confirm the resulting access state.

A review should not assume that every unfamiliar permission is improper. First establish why it exists and whether it is required for an active responsibility. If the record is incomplete, ask the relevant business owner or administrator to clarify it before making a decision, unless a separate security or platform process calls for immediate action.

Do not use a new account, a different identity or another route to get around a denied request, limit or verification requirement. If the platform has restricted access, use its official appeal and support channels and correct the cause. The internal workflow should make legitimate access easier to manage, not provide a workaround.

Make the process easy to follow

A sound process is short enough that people will use it and clear enough that approvals mean something. Publish the request route, the responsible approvers, the information a request must contain and the place where records are kept. Explain that verbal approval or a forwarded message is not a substitute for the agreed record.

When a request is incomplete, ask for the missing work reason or permission detail rather than guessing. When it is declined, record the decision in neutral terms and explain what would need to change for the request to be reconsidered, if appropriate. When work is urgent, use an established urgent-review route if the team has one; do not treat urgency as automatic permission to skip platform requirements or erase the audit trail.

The team should revisit the workflow when its structure, responsibilities or platform access arrangements change. Keep internal guidance aligned with the platform’s current help and policy pages, especially where role names, permissions or verification steps may differ. A modest, maintained process is more useful than a detailed document that no one follows.

Routing each access change through a written request, decision, implementation and confirmation creates a practical boundary around shared business assets. It gives people a way to obtain the access their work requires while preserving accountability. Most importantly, it makes permission changes deliberate: tied to a reason, approved by someone responsible and reviewed when that reason no longer applies.