The "Request Advanced Access" button is greyed out — and the reason is not in your app settings
Teams spend days re-checking Business Verification, privacy policy URLs and app categories, because the dashboard gives no explanation. The actual gate is somewhere else entirely, and it has a delay built into it.
That two-day lag is why this issue eats weeks rather than hours. The developer makes a call, sees nothing, assumes the call was wrong, changes the token, changes the endpoint, changes the permission, and starts the cycle again. Each wrong turn adds another wait. Nothing in the dashboard says "pending".
Four things that keep the button disabled
No logged call for that exact permission
The requirement is per permission, not per app. Approval for one permission does not un-grey another. A call that touched one endpoint does not register for a permission it never exercised.
Access Verification not completed
Meta documents that some permissions require access verification (Tech Provider) before you can apply for them. That is a separate process from App Review, with its own business prerequisites.
The permission is not available to your app
App Types determine which permissions can be requested at all, and app types cannot be changed after creation. On newer use-case apps, permissions arrive bundled with the use case — and use cases cannot be removed once added.
The permission was removed from the app
Meta documents a remove-and-restore flow with its own buttons. Previously approved advanced access that is restored does not require re-review — so the button you are looking for may simply not be the one that applies to your situation.
What actually has to happen, in order
- Confirm the permission is even requestable for this appBetween App Types and the newer use-case model, half the permission lists circulating online do not apply to the app in front of you. This has to be settled first, because it is the one problem no amount of API calls will fix.
- Make a real call that exercises each permissionMeta accepts calls made from your app or from the Graph API Explorer. The call has to succeed, and it has to be the call that the permission governs.
- Wait for the logging windowUp to two days. This is the step teams skip, and skipping it is what produces the false conclusion that the setup is broken.
- Clear Access Verification where it appliesMeta notes that business admins of an unverified Tech Provider business get an email about access verification whenever an app admin requests advanced access for a listed permission. Meta says a decision takes roughly 5 days, and that access verification is independent of App Review.
- Only then assemble the submissionScreen recordings per permission, a distinct written description per permission, testable access for reviewers, and app settings complete. This is where the work actually is.
Blocks the request vs blocks the approval
Confusing these two is the second most expensive mistake on this page. Fixing an approval-stage problem will never un-grey a button, and fixing a request-stage problem will never save a weak submission.
| Requirement | What it actually stops |
|---|---|
| Logged successful API call per permission | Blocks the request — the button itself stays disabled |
| Access Verification (Tech Provider) | Blocks the request for the permissions on Meta’s listed set |
| Business Verification | Meta’s tutorial places it after permission selection, so it interrupts the flow rather than greying the button. A separate Meta page states flatly that it is required to get Advanced Access. |
| Screen recording per permission | Blocks approval — Meta states any requested permission missing a screen recording will not be approved |
| Reviewer access to the app | Blocks approval — if Meta cannot access the app to test it, the entire submission is rejected |
| Allowed Usage match | Blocks approval for that specific permission |
| Live mode | Neither, at request time. Meta’s tutorial says to switch to Live only after App Review is complete. |
Where projects stall
- The call was made with a token that carried a different permission than the one being requested.
- The dashboard was re-checked within minutes and the two-day logging window was never allowed to pass.
- The team completed Business Verification first, assuming it was the blocker, and lost a week before touching the real cause.
- The permission belongs to a use case that was never added, or to an app type the app was not created under.
- Access Verification was triggered silently by email to a business admin who is not the developer, so nobody in the project saw it.
- The business account carries a restriction, which blocks access verification while the developer debugs code.
- Screen recordings were prepared for the bundle instead of one per permission, so some permissions come back unapproved even after a clean submission.
- Permission descriptions were copy-pasted across permissions, which Meta explicitly prohibits.
- Settings were changed after submitting, which Meta says may require re-review.
Two places Meta’s own pages disagree — worth knowing before you follow a checklist
- Live mode timing. The access levels page says consumer apps must be in Live mode before requesting permissions with Advanced Access from non-role users, while the submission tutorial says to go Live only after review. These describe different moments — using an approved permission publicly, versus requesting review — but read as a contradiction to anyone following one page in isolation.
- Business Verification sequencing. One page states it is required to get Advanced Access; the tutorial places the prompt after you have already selected permissions.
- App Types vs use cases. The access levels documentation scopes itself to apps created using an App Type, while app creation is now described through use cases. Meta has not published a page reconciling the two models, so older guidance frequently does not match the dashboard in front of you.
What Meta does not publish — treat any figure here as invented
- No documented rule that an already-granted permission greys the button.
- No documented statement that a restricted app state greys the button specifically.
- No published requirement for a Terms of Service URL or a "verified business email" as an App Review gate.
- No statement that the Data Deletion callback blocks submission — it is a Platform Terms and settings obligation.
- No confirmation that the greyed-button rule applies identically to newer use-case apps.
- No published duration for Business Verification itself.
The part that is genuinely hard
Un-greying the button is mechanical once you know the rule. What follows is not. A submission has to show a reviewer, without narration, that each permission is exercised by a real user flow inside a working product — and it has to match the written justification for that permission and the Allowed Usage Meta publishes for it. That reconciliation across product, recording and text is where prepared submissions separate from rejected ones, and it is the work we do for clients rather than describe in a blog post.
Related reading: what Meta Advanced Access actually is, every way a Meta App Review submission can fail, and why permissions break between Development and Live mode.