One Text Field. Seven Wasted Days. The Use Case Description Problem.
Meta App Review has a required text field for every permission you request: "Provide details about how your app uses this permission or feature." Most developers write two sentences. Most of those reviews come back rejected. The use case description is not a formality — it is the primary document reviewers use to verify that your permission request is legitimate, your data handling is proportionate, and your screencast is consistent with what you claim your app does.
What the Use Case Description Field Actually Is
This is a permission-specific justification field in the Meta App Review submission form. It is separate from your general app description. You must complete one for every permission or feature your app requests. A reviewer reads it alongside your screencast recording and cross-checks it against your privacy policy. If any of the three documents contradict each other — even a minor inconsistency in the described user flow — the submission is rejected and the review period restarts from zero.
What Meta Reviewers Check in the Use Case Description
Purpose Clarity
Is the stated use case specific enough to evaluate? Generic language like "to improve user experience" or "we need this permission for core functionality" gives a reviewer nothing to work with. The description must name the exact user-facing feature that requires the permission and explain why a user would encounter it.
Data Minimization
Does your use case actually require this permission, or could a lower-access alternative work? Reviewers look for whether the requested access level — Standard or Advanced — is the minimum necessary for the feature described. Requesting Advanced Access when Standard Access would suffice is a common rejection trigger.
Privacy Policy Alignment
Does your description match what your privacy policy says about data use, storage, and deletion? Reviewers cross-check both. If your policy states no Facebook user data is stored server-side but your description implies otherwise, the contradiction ends the review immediately.
Screencast Consistency
Does the user flow you describe in the text match the screencast frame by frame? If the description says "users connect their Facebook Page and see analytics" but the screencast skips the Page connection step, that mismatch triggers rejection. Reviewers use the description to navigate the recording.
Why Generic Descriptions Are Rejected Without Detailed Feedback
- "We need this permission to allow users to post content." No user flow, no data handling detail, no justification for the access level. Rejected.
- "This permission is needed for our app's core functionality." Zero specificity. Reviewers cannot evaluate proportionality from this. Rejected.
- "We use this data to improve our product." Does not describe what data, which users, or whether it is stored. Rejected.
- Descriptions that reference features not shown in the screencast. The reviewer will attempt to replicate the flow using a test user account and will not be able to find what you described. Rejected — and may trigger a second screencast review.
- Copy-pasted descriptions across multiple permissions. Each permission has a different purpose and data scope. Identical text across multiple fields signals to reviewers that the developer did not understand what they requested. Rejected.
What a Use Case Description Must Address (Per Permission)
pages_read_engagement, describe exactly which engagement data your feature surfaces and why no lower-privilege alternative covers it. Vague references to "analytics" or "insights" are insufficient.Common Mistakes That Restart the Review Clock
- Describing a feature not visible or reachable in the screencast — reviewers test using a test user account with your exact app
- Requesting Advanced Access when Standard Access is sufficient for the described feature
- Omitting server-side data storage details while your privacy policy discloses it
- Writing a single description and copying it across multiple permission fields
- Using the general App Description as the use case justification — they are different fields for different purposes
- Finalizing the description before the screencast is complete — the two must match exactly and neither can be edited after submission
- Not accounting for the test user in the described flow — if a Meta reviewer cannot replicate your described feature using a Development Mode test user account, the description and screencast both fail
Every rejection resets the review period and returns the permission request to the queue. A single inconsistency between your description, your privacy policy, and your screencast can produce a rejection with minimal diagnostic feedback — often just a code pointing to "insufficient information" or "policy concern." Identifying which of the three documents caused the failure, correcting it across all three consistently, and resubmitting can take an additional two to seven business days per attempt — and those attempts compound.
For a complete map of all rejection categories and what triggers each one, see the Meta App Review Rejection Reasons guide. For the full Facebook App Review preparation and submission support service, see the Facebook App Review Service. For how to handle a prior rejection and prepare a corrected resubmission, see the Meta App Review Rejection Fix service.