Facebook Messenger for Business: Roles & Permissions

When a customer sends a message to a business on Messenger, the conversation belongs to the business Facebook Page. Meta’s Messenger Platform collection requires a Facebook Page and an app with pages_messaging for the API. Its sample bot uses a Page, a Page access token and a webhook; the example lets a human answer from the Page Inbox after the bot hands over the thread. That gives an owner a concrete model: the Page is the asset, the responder is a person with Page access, and the app is another actor with its own credential.

Meta Business Suite can show messages for Facebook and Instagram together, according to Meta’s Business Suite introduction. That shared inbox is convenient for a team, but it can hide which asset granted access. A person assigned only to an Instagram account should not be counted as a Messenger backup. Open the Facebook Page’s access settings and test a Messenger conversation specifically. The Instagram roles guide covers the separate Instagram authorization paths.

A small business may manage the Page directly, while a larger organization may place it in a Meta business portfolio and assign people or partners there. For a useful audit, write down which business controls the Page, who has full access to it, who can perform its Messages task, and which apps are attached. If a vendor created the app, the business still needs a named person who can review the Page authorization. Do this before the vendor contract ends; a live bot does not prove the business can renew its token or reconnect its webhook.

Meta’s current business-asset permissions distinguish Full control from Partial access for a Page. The Page task for customer replies is Messages and calls, separate from Community activity, Content, Ads and Insights. Those are the business-portfolio labels. On the Page itself, Meta’s Page access article uses different words: Facebook access with full or partial control, task access (Content, Messages and Community Activity, Ads, Insights) and Community Manager access for live-chat moderators, so match the labels to the screen you are on. As of November 2026, inspect that Page task before assigning a support agent broad control. A responder needs the ability to read and answer Page messages; an ad buyer may need Ads but no customer inbox.

Full control is a recovery and governance role. Give it to people who are responsible for keeping the Page and its access under the business’s control. If the only full-control holder is an agency contractor, the business may discover during an outage that it cannot remove the bot or add a replacement responder. Partial access lets the owner separate the actual work. For example, a customer-service contractor can answer messages while a campaign contractor manages ads, with neither role assumed to include the other.

The API also has a Page-task vocabulary. Meta’s Conversations API reference says a Messenger Page access token is requested by someone with the MESSAGING or MODERATE task and lists pages_manage_metadata, pages_read_engagement and pages_messaging for Messenger conversations. These uppercase task values help a developer diagnose a token. They are not a reason to grant an employee full control of the Page. Keep the human assignment and the app permission review in separate columns.

This table uses the access names Meta publishes for the Page experience and the task names its API describes. It does not treat the older named Page roles as a stable instruction for a current Page. Read the actual Page access screen before accepting an invitation or changing a role. A person who can see the Page’s content calendar may still fail the Messenger reply test if Messages and calls was not assigned (Meta Page permissions).

Keep the access review tied to a job. A founder can delegate inbox work without handing over the ability to change every Page setting. A developer may need to authorize the Page for an app and then stop using the day-to-day inbox. A support lead can be the designated responder for escalations while ordinary agents have a narrower task assignment.

Have someone with portfolio Full control open Meta Business Suite Settings > People > Invite people, enter the person’s account, select the Page as an asset and assign Partial access > Messages and calls (Meta invitation steps). The invitee must accept before you test a Messenger thread in the Page inbox. If the owner has Page Full control but lacks portfolio Full control, Meta’s change-access guidance says to switch into the Page on Facebook to manage its access instead. Meta’s Page permissions explicitly put Messages and calls in its own Partial access column. If the Page is also in a business portfolio, inspect its assignment there so a portfolio invitation does not get mistaken for tested Page access.

For a role change, start from the work the person now performs. A content editor taking a support shift may need Messages added. A support agent becoming an analyst may need Messages removed while retaining Insights. Keep a written owner for the customer queue during the change. Use Settings > People > person > Manage to change the Page asset or Remove access to end it (Meta change-access steps). After saving, ask the person to reply from their own account and confirm the message appears on the business Page. The test catches a wrong Page selection, an unaccepted invitation and a task that did not include messaging.

When someone leaves, remove their Page or portfolio assignment and inspect any connected app they configured. A Page access token is a separate route into the conversation. Meta’s sample Messenger app shows an app dashboard where a Page is added and a Page token appears. Its interface is an older sample, so use it to understand the credential relationship, not as a promise that the 2026 menu is identical. Revoke or rotate a credential the departing person controlled, then send a fresh customer message to verify the replacement.

Do not leave the full-control check until after the removal. Confirm the remaining owner can open access settings and see the Page before taking away the previous owner’s account. If the person was the only one able to authorize the Page for the app, transfer that operational knowledge and the app dashboard access as part of the handoff. Otherwise a token expiry or webhook failure can turn an ordinary departure into a support interruption.

Treat Page control as a business continuity question. Who can add a new responder if the support lead is unavailable? Who can inspect a connected app if Messenger stops delivering messages? Who has the recovery details for the personal account used to manage the Page? Meta says attackers often target the personal accounts connected to business Pages before trying to reach business tools in its security guidance. Secure those personal sign-ins as part of Page ownership.

Keep at least one trusted backup able to reach the Page access screen, and check the business portfolio’s Page assignment at the same time. A backup who only knows the password to a shared inbox is not a reliable access owner. Meta describes Accounts Center as a place for Passwords and security across its apps. Review recovery contacts, two-factor authentication and active sessions for the people who hold control. This is especially useful before an agency contract ends or a founder changes their personal phone.

A verified badge is a different signal from a Page permission. Meta’s New Pages Experience announcement discusses verified Page comments separately from its task-based administration. Do not infer that a badge gives someone Full control or that Full control makes a bot eligible for public messaging. For an app, check the permission and access review requirements in the developer setup; for a person, check the Page access screen. A business verification process may matter to a particular app review, but it is not a replacement for the Page’s Messages task.

A Page access token lets an authorized app call Messenger endpoints on behalf of the Page. Meta’s Messenger Platform sample pairs a PAGE_ACCESS_TOKEN with a webhook and a Page subscription. The Messenger Platform collection lists pages_messaging and describes the Send API as the route for texts, attachments and sender actions. An app dashboard is therefore part of the access inventory even if all human agents work in Business Suite.

For standard replies, Meta’s collection says the recipient must have messaged the Page within the last 24 hours or agreed to messages outside that standard window. Do not build a sales workflow that assumes the Page token permits an unlimited first contact. For example, a list of webinar attendees is not itself a set of Messenger conversations the Page can open. Check the approved use case and current permission before scheduling any automated follow-up (Messenger Send API).

Meta’s Conversations API description says Advanced Access is needed to read conversations with people who do not have a role on the app, Page or business. This matters in testing: a developer’s own message can succeed while real customer conversations remain unavailable. Use a consenting test customer who has no role on the app to check the production permission path. Record the test result, app owner, Page ID, token owner and webhook destination without putting the token itself into a handoff document.

To remove an integration, review the Page authorization and its app dashboard, revoke the old Page token, and confirm the webhook no longer receives a newly sent test message. Rotate any app secret or webhook verification credential the former supplier held. Then test the new integration with the same Page. A person disappearing from the People list is not proof that their old deployed service stopped calling the API.

Begin with the people who have broad Page access. Meta recommends two-factor authentication, login alerts, session review and business notifications for people using its business tools. A useful monthly check is to compare the Page access list with the current support and agency roster, then ask the owner to explain every Full control holder. An unknown name should trigger an access review, not an assumption that it is an old employee.

For an app, inspect where its webhook delivers messages and whether it can send replies. The Meta handover sample demonstrates a bot passing a thread to Page Inbox and back. If your team uses both automation and humans, write down which system holds the conversation at each stage. A support agent should know how to take a customer from a failed bot flow without sending a duplicate answer. Test handover when changing vendors, since two functioning applications can still route a conversation to the wrong place.

Offboarding should include the Page assignment, business portfolio access, app roles, Page tokens, webhook credentials, active personal sessions and unresolved customer threads. Run a new-message test after each credential change. Keep a dated record of which connection was retired and who approved the replacement. That record is useful when a message failure appears days later: the team can distinguish a permission removal from a delivery outage or an unhandled customer request.

Do not publish Page tokens in screenshots, issue descriptions or logs. Meta’s sample keeps token values in configuration variables; follow the same separation for production credentials (sample webhook setup). A token is effectively a way for a service to act as the Page within its granted permissions. Treat the exposure of one as an access incident and rotate it rather than merely deleting the visible screenshot.

Giving Ads instead of Messages: the marketing agency can see campaigns but the support agent cannot reply to a Page message. Meta lists Ads and Messages and calls as distinct tasks (Page access); grant and test the task that matches the job. Testing only with a developer: the bot answers its creator, then fails for ordinary customers. Check Advanced Access using a test person without an app or Page role (Conversations API).

Confusing the channels: a teammate sees Instagram DMs in Business Suite and assumes the same assignment covers the Facebook Page. Open the Page access settings and test Messenger separately. Treating a Page token as a password for staff: several agents share one token to work around missing Page access. Assign people individually; reserve the token for a reviewed app. Leaving a bot attached after handoff: a new support tool is connected but the old webhook still receives events. Review the old Page authorization and perform a fresh message test after revocation.

Assuming the 24-hour window is a marketing list: an ops lead queues follow-ups to people who never wrote to the Page. Meta’s Send API guidance describes a recent incoming message or another qualifying agreement. Design replies around that rule and check the current permitted exception before sending outside it. Keeping only one Page controller: the sole full-control account is deactivated during a staff departure. Verify a business-held backup before removing that account. Each mistake has a different fix; repeatedly regenerating a token will not repair a missing human task assignment.