Facebook Login for Business: Why config_id Replaces scope, and What App Review Actually Checks
Classic Facebook Login asks for a list of permissions at run time. Facebook Login for Business does not. You build a configuration inside the Meta App Dashboard, Meta hands you a configuration ID, and that ID is what your login dialog sends. It looks like a one-line code change. It is really a change in who decides what your app can ask for.
If your product connects other companies' Pages, ad accounts, WhatsApp numbers or Instagram professional accounts, this is the login surface Meta expects you to use. Getting it wrong does not usually produce a clean error. It produces a login dialog that loads, grants less than you asked for, and an integration that fails days later on a specific customer.
What actually changes when you move to Login for Business
The configuration is the request
In the App Dashboard you specify the access token type, the business assets your app needs, and the permissions attached to them, then save it as a configuration. Meta returns a configuration ID. Your app passes that ID instead of a scope list.
Rollback is not free
Meta's own documentation notes that classic Facebook Login does not support the config_id parameter. If you revert, the login dialog can fail to load until you swap config_id back to scope.
Users still grant granularly
A person managing several Pages can grant your app access to only one of them. Public profile is the only part that is always included. Every other permission can come back partially granted.
Permissions can lapse
Meta documents that a permission unused for 90 days may expire, and that this applies even when the permission was approved through App Review. Approval is not a permanent state.
Why this is harder than a parameter swap
The configuration is not a private developer setting. It is the contract your customer sees at the moment they decide whether to trust your product. Three separate things have to line up before it works in production.
First, the permissions inside the configuration have to be ones your app is approved for. Serving businesses that you do not own or manage requires Advanced Access through App Review — see what Meta Advanced Access is and how it gets approved for how that gate behaves.
Second, business-asset data access can pull in its own reviewable feature. Business Asset User Profile Access is reviewed separately from the individual permissions, and it changes how user profile data reached through a business asset is handled.
Third, the token type you chose in the configuration decides what your backend can do afterwards. If your platform needs access that survives the user closing the browser, you are in system user access token territory, and that has to be designed in before review, not bolted on after.
Worth noting: classic Facebook Login is still the right tool for consumer sign-in. If all you need is identity, the older path and its permission set are covered in Facebook Login permissions: when email and public_profile are not enough. Login for Business is specifically for reaching assets other companies own.
How the process runs, at a high level
Decide the asset and token model first
Which asset types will customers connect, how long your backend must hold access, and whether one configuration covers every customer tier or you need several. This decision is expensive to reverse later.
Map each asset to the permissions that unlock it
Every business asset in the configuration implies a permission set, and every permission in that set is a separate review obligation. Over-requesting is the most common reason a submission comes back.
Build the review evidence around the real flow
Reviewers test the configuration as a customer would. The screencast, the test credentials, and the written use case all have to show a business connecting its own assets — not your own internal account.
Handle partial grants in the product
Because users can grant a subset, your app has to detect what was actually granted and recover gracefully. An app that assumes full grant will produce support tickets that look like outages.
What a correctly prepared setup looks like
One configuration per genuine customer journey. Only the permissions the journey needs. A token model that matches how long your backend has to keep working. Review evidence recorded against a real third-party business connection. Product code that reads the granted permission list on every session rather than trusting the first response.
Approval outcomes are decided by Meta and no specific result or timeline can be promised. What preparation changes is how many review cycles it takes to get there.
Where these submissions commonly come apart
- The configuration requests business-asset permissions the app has not been approved for, so real customers see fewer options than the developer tested with.
- Only the developer's own business was ever used in testing, so the reviewer cannot reproduce a third-party connection.
- Business Asset User Profile Access is assumed to be included with the other permissions rather than requested and justified on its own.
- The app treats a partial grant as a failure, or worse, as a success, and breaks quietly for the customers who granted one Page instead of all of them.
- A rollback to classic Facebook Login leaves config_id in the call, and the dialog stops loading.
- A permission sits unused past the documented 90-day window and has to be regranted by the user before the feature works again.
The short version
Facebook Login for Business moves the permission request out of your code and into a configuration Meta reviews. That makes the login dialog cleaner for your customers and makes the preparation work heavier for you. The configuration, the permissions, the reviewable features and the token model are one decision, and they have to be decided before the submission rather than discovered during it.