Managed Meta accounts are an account type for business tools across Meta. Organizations are able to manage these accounts with administrative features including single sign-on (SSO) support, automated account provisioning and more. With these accounts, individuals can access Meta’s business tools, such as Business Manager, with their work credentials, without needing to use their personal Facebook account.
Since managed Meta accounts are meant to be used for work only, the following are constraints within the managed Meta accounts type:
user_*
related permissions, such as user_friends
or user_posts
. Note that managed Meta accounts can still complete login flows requests, but will ignore user_*
related permissions.Businesses undergoing migration to managed Meta accounts will transition users from using their Facebook accounts to using their work credentials to access Meta’s business tools. Users will be able to log into Business Manager with their work accounts instead of their Facebook accounts.
If your app is accessing clients’ business assets using System user access tokens or partner sharing, your third-party integration should not be impacted. If your app is using User access tokens (or Page access token generated from User access tokens), your app’s permissions and access to business assets granted by personal Facebook accounts will not automatically transition to the new managed Meta accounts. Users will be required to regrant permissions to those business assets using their new work accounts to preserve your apps' access to those assets.
To proactively minimize potential disruptions to your API calls, it is recommended your app provides the following:
Sandbox to validate that Meta work accounts are supported by your integrations.
In the Test Users section of your app dashboard, we provide a way to create and manage simulated managed Meta accounts to test your app's implementation of Facebook Login and any permissions or features your app uses. By leveraging the Test User Tool's capabilities for creating and managing Managed Meta account test users, you can ensure a smoother experience for users logged into managed Meta accounts while integrating Facebook Login functionality into your app.
These test accounts cannot interact with real users, and any data you generate with a test user will only be visible to other test users on your app, or to real users who have an Administrator, Developer, or Tester role on your app. You can create, edit, delete, and login as a test user only through your App Dashboard (not via Graph API).
Please refer to the primary documentation for additional details on test user limitations. The same limitations for test Facebook users apply to test managed Meta accounts, except that apps are limited to 1 test managed Meta account.
You can create test users in the App Dashboard by going to the Test Users section in the Roles > Test Users panel, choosing the managed Meta accounts tab, and clicking the Create test users button. This will open a dialog that allows you a test account.
The Create Test Accounts dialog allows you to:
Once created, test users will appear in the Managed Meta accounts table.
You can test your app with a test account by using the test managed Meta account's credentials in Facebook Login and granting your app any permissions it needs. You can also grant your app permissions on behalf of a test user by clicking the ellipsis icon (•••) in the Options column within a given test user's row in the managed Meta accounts table. Clicking the ellipsis icon will give you the option to edit the permissions the test user has granted your app, generate User access tokens for the test user, and log into the test user's account.
After you log into the test account, it is recommended that you assign the business assets needed to go through your app integrations successfully. You can do so by navigating to Business settings to manage your test user’s business manager account and assets assigned to your test user such as pages, ad accounts, and product catalogs.
You can simulate the changes in business permissions that occur when a Facebook user transitions to a managed Meta account, allowing you to test the impact of user migrations on your app. To use this feature, visit the Facebook test user, click the ellipsis icon (•••) in the Options column, click Transfer business permissions to work account, and follow the instructions.
The following prerequisites must be met to use this feature:
After you have completed a transfer, you will be able to:
Meta is delaying the potential disruption by offering a 30-day grace period, where the User/Page Access Token backed by Facebook user still has access to the business assets via third-party APIs. During the 30-day grace period, the user needs to reauthenticate on a third-party Tech Provider’s surface and create a new access token for the Tech Provider to store. By “reauthenticate”, the user has to authenticate with their MWA identity, reselect the same set of business assets, and pass back business permissions to the Tech Provider in the form of a new access token. If that 30-day grace period passes and the user has not authenticated or is still using their personal FB account, the API call will start failing.
Meta has a persistent 30-day banner in Business Manager that counts down and shows all the third-party apps that the user needs to re-authenticate with their managed Meta accounts. If a third-party app is only using a System User Access Token (SUAT), it will not show up in the section since migration doesn't impact system users.
The managed Meta account migration APIs and troubleshooting documentation provides information on how to determine which users and Business Accounts are migrating, their expiration date, and whether they are a managed Meta account or not.
is_work_account
is a boolean return type that indicates whether the user is using a managed Meta account or not. It is available in the User object.
The user_access_expire_time
field is a timestamp that indicates when the user's access to specific assets will be revoked. After this timestamp has passed, the user is expected to no longer have manage access to the assets. Subsequent API calls using the Facebook user's access token needing to access these specific assets will start returning permission errors. user_access_expire_time
is available on the following objects:
user_access_expire_time
has certain limitations. It will only return expiration time data of assets which the user has explicit access through business permissions of the migrating business. For example, the data will only return a timestamp if the Facebook user is an admin of the Page through a migrating Business Account. Pages owned by the migrating business that are not directly assigned to the user will not yield a timestamp.
is_work_account
status GET /v17.0/{user-id}?fields=is_work_accountResponse
{ "id": "{user-id}", "name": "Romane Richter" "is_work_account": true }
user_access_expire_time
during a 30 day window
GET /v17.0/{object-id}?fields=user_access_expire_time&access_token=<access-token>Response
{ "user_access_expire_time": "2023-06-23T12:00:00+00:00" }
GET /v17.0/{object-id}?fields=user_access_expire_time&access_token=<access-token>Response
{}
GET /v17.0/{object-id}?fields=user_access_expire_time&access_token=<access-token>Response
{ "error": { "message": "(#100) Object does not exist, cannot be loaded due to missing permission or reviewable feature, or does not support this operation. This endpoint requires the 'pages_read_engagement' permission or the 'Page Public Content Access' feature or the 'Page Public Metadata Access' feature. Refer to https://developers.facebook.com/docs/apps/review/login-permissions#manage-pages, https://developers.facebook.com/docs/apps/review/feature#reference-PAGES_ACCESS and https://developers.facebook.com/docs/apps/review/feature#page-public-metadata-access for details.", "type": "OAuthException", "code": 100, "fbtrace_id": "AZdHiJUBflrZnE-RNKrHAah" } }
user_access_expire_time
and make API calls to it, developers should ensure that the required permissions are granted to load these objects. In the provided examples, if object-id
is referring to a business object id, then the user must have been granted at least the business_management
permission to load the object. Please refer here for more details.
100
and the type OAuthException.
This indicates the object is no longer accessible via API, since the user no longer has access to the asset.
Visit the Tech Provider Integrations FAQ.