Meta App Review Screencast Rejection explains demo evidence, permission flows, reviewer expectations, and practical recording fixes.
Meta App Review Screencast Rejection: 5 fixes before you resubmit
What the screencast is actually for
The screen recording is not a marketing demo of your product. Meta’s reviewers use it as a test script: they replicate the exact steps you show to verify that your app genuinely needs each permission and feature in the submission.
Per Meta’s own guidance, any requested permission or feature that is missing a screen recording will not be approved — the recording is mandatory, not optional polish.
That single rule reframes the whole task. The video is evidence, and it has to stand on its own. If a reviewer watches it and still cannot tell how to trigger the permission, the safe decision for them is rejection.
The three things every recording must show
For each permission you request, Meta expects the recording to walk through a complete, reproducible journey. Miss any one of these stages and the submission is at risk.
1. The full login flow
From logged-out to logged-in — including the business login button and the moment the user authorizes your app. Reviewers need to see how a real user actually gets in.
2. The permission being granted
The consent screen requesting that specific scope, and the user approving it. A recording that skips the authorization step never proves the scope is really used.
3. The data actually being used
The app performing the action that depends on the permission — creating the post, reading the data, sending the message — and the visible result of that action.
Every permission, individually
One scope without its own demonstrated flow is enough to fail the whole submission. Each requested permission needs its own clear, on-screen proof.
Screencast Not Aligned with Use Case Details: what the rejection means
Screencast Not Aligned with Use Case Details is one of the most common screencast rejections. Meta cites Developer Policy 1.6 (Build a Trustworthy Product) with it. The notice usually says your use case is allowed. The video just did not show the end-to-end experience you described in your submission notes.
So this is not a ban on your feature. It is a proof gap. Your written use case and your recording tell two different stories, and the reviewer cannot square them.
The notice usually asks for a new recording that shows:
- The complete Meta login flow
- A user granting your app access to the permission or feature
- The end-to-end experience of the use case for that permission
- An English UI with captions or tooltips that explain buttons and on-screen elements
If your app runs server-to-server or uses a system user token, there is no front-end login to record. Say so clearly in your next submission. Otherwise the missing consent step can look like a gap.
Why a working app still gets “not aligned”
A reviewer compares five things in a row: the permission you requested, your written description, the live feature, the screencast, and what they can reproduce. One mismatch anywhere is enough to cause a rejection.
Some patterns we see often: the notes describe publishing, but the video stops at a draft screen. The consent dialog shows a different scope set than the one requested. Or the video shows the result without the user action that triggers it. If the reviewer could not reproduce the flow at all, the label is often Unable to Verify Use Case Experience instead. If the video was too thin to judge, see Inadequate Demonstration.
Re-recording right away usually repeats the mismatch. Rapid, blind resubmissions can also trigger a cooldown of up to 7 days on the review button. First, find where the story breaks. Then fix the notes, the product, or the video, whichever one is wrong.
Why so many screencasts get rejected
The failures are rarely about app quality. They come from the gap between what a founder thinks is obvious and what a reviewer — working from the video alone, with no context — can actually verify.
The reviewer cannot reproduce it
Reviewers test with their own accounts and test users. If your flow depends on hidden setup, a specific account state, or steps that are not shown on screen, they cannot replicate it — and an unreproducible flow is treated as unproven.
It is a product tour, not a permission proof
A polished walkthrough of your dashboard that never clearly shows the consent screen or the scope in action is the single most common reason demo videos fail. Reviewers are looking for the permission, not the features.
Advanced Access raises the bar
Publishing or managing data for accounts your users do not own requires Advanced Access, which is only granted through a clean App Review. A weak screencast is what blocks that step. See our guide to Meta Advanced Access for how this gate works.
Each rejection costs weeks
App Review is not instant, and every failed round means re-recording, resubmitting and waiting again. Two or three avoidable cycles can stretch a launch by a month or more — which is exactly the cost a correct first submission avoids.
How a review-ready submission comes together
A screencast that passes is the output of preparation that happens before the camera ever rolls. At a high level, this is the sequence we handle end to end.
Map every requested permission and feature to a concrete, demonstrable action in the app, so nothing is requested that cannot be shown on screen.
Confirm Business Verification and the supporting details — privacy policy, data handling, use-case description — line up with what the recording will show.
Stand up a clean, reviewer-ready environment with working test users so each flow can be reproduced exactly as recorded.
Record each permission’s full journey — login, consent, and the data being used — in English, in high resolution, with clear annotations on the moments that matter.
Submit, monitor the review, and if a specific item comes back, fix that exact reason and resubmit without disturbing the scopes that already passed.
What a clean submission gets you
If you have already been rejected, the path back is the same discipline applied to the exact failure point. Our case study on a rejected Facebook App Review walks through how a corrected justification and a proper screencast turned a denial into an approval.
Common reasons demo videos fail review
Need Us to Get Your Meta App 100% Approved?
Stop losing weeks to repeated rejections. With 500+ apps approved, we handle your entire submission from start to finish. You get 100% Approval or a 100% Refund — and for your complete safety, you can hire us directly through Upwork or Fiverr Escrow (or use the WhatsApp / Calendar buttons in the header & footer).
Chat on WhatsAppScreencast rejection FAQ
Does “Screencast Not Aligned with Use Case Details” mean my use case is banned?
Usually not. The notice typically confirms the use case is allowed. The recording just did not show it end to end.
Can I just upload a new video?
Only if the video was the only thing wrong. If your use-case text or the live feature doesn’t match, a new video will fail the same way.
What if my integration uses a system user token?
Say clearly in the submission that the app is server-to-server, then show where the data appears in your product.
Does one misaligned permission fail the whole submission?
That permission gets rejected. Fix it without disturbing the scopes that already passed.
Can I appeal instead of resubmitting?
If you believe the reviewer missed something that is clearly in the video, reply through the App Review feedback with timestamps. If something really was missing, a corrected resubmission is faster.
Free 15-Minute Rejection Audit on WhatsApp
Real examples: pages_manage_posts approval · all case studies · hire a Facebook API developer
Failing review over the screencast?
If your Meta App Review keeps getting rejected on the demo video, I provide hands-on App Review and screencast submission support — from mapping permissions through to an approval-ready recording. See the Facebook App Review service or reach out directly.
Approval support and submission preparation only. Final approval decisions rest solely with Meta.
Map the user journey and reviewer steps for Meta App Review Screencast Rejection prevention.
Show login, permission prompts, test accounts, and successful outcomes in Meta App Review Screencast Rejection evidence.
Keep narration concise and demonstrate each requested permission during Meta App Review Screencast Rejection.
Prepare privacy details, app roles, and reproducible steps before Meta App Review Screencast Rejection submission.
Test video links, access, and redirects to avoid Meta App Review Screencast Rejection.
Update recordings when flows change after Meta App Review Screencast Rejection.
Review the official Meta App Review documentation for current requirements.
See our Meta API guide for implementation planning.
Related: the full what-reviewers-must-see guide.