Facebook App Review · Case Study
A fully built, working Facebook app. Advanced access permissions already wired into the product. Then Meta sent back a rejection — no specific reason code, just a generic message about the submission not meeting requirements. The developer had spent weeks preparing the screencast, privacy policy, and test user setup. Still rejected.
Permissions Requested and Why They Were Needed
The app’s core functionality required reading and managing Facebook Page data on behalf of the authenticated business user.
pages_show_list
Required for users to select which of their Pages to connect to the app
pages_read_engagement
Required to read post reactions, comments, and engagement data for analytics
pages_manage_posts
Required to publish and schedule content to the connected Facebook Page
pages_read_user_content
Required to read visitor posts and comments on the managed Page
What Was Wrong With the Original Submission
Screencast Issues
The screencast demonstrated the features but used a personal profile instead of a test Business Page. Meta reviewers could not verify the permission flow as it would work for a real business user.
Missing Use-Case Justification
The submission notes explained what the permissions do, but not why this specific app’s business use case requires each permission. Meta expects explicit justification tied to a real user workflow.
Privacy Policy Gaps
The privacy policy mentioned data collection but did not explicitly state how Facebook data is stored, processed, and deleted. Meta’s review checks for this level of detail.
Test User Access Not Set Up
No test user credentials were provided in the submission. Meta reviewers could not independently verify the app flow, which triggers rejection.
How the Submission Was Fixed
1
Audit of all existing submission notes — Each permission’s justification was reviewed against Meta’s official permission reference. Generic explanations were replaced with specific user-flow descriptions tied to the app’s actual features.
2
Screencast rebuild with a test Business Page — A dedicated test Facebook Page was created. The full user journey was re-recorded: login, OAuth flow, permission grant screen, and each permission being actively used in the app interface.
3
Privacy policy rewrite for Facebook data — Added a dedicated section covering what Facebook data is collected, how it is stored, retention period, deletion procedure, and how users can request data removal. The data deletion callback URL was also verified and tested.
4
Test user setup and documentation — Created a Meta test user with access to the test Business Page. Included test credentials and step-by-step reviewer instructions in the submission notes.
5
Resubmission with structured notes — Each permission was submitted with a structured note: business use case, user workflow, why no lesser permission covers the need, and where in the screencast the feature is demonstrated.
ResultApproved
Review Round2nd Submission
Permissions ApprovedAll 4
Access LevelAdvanced Access
Common Reasons Facebook App Review Gets Rejected
- Screencast recorded on a personal profile instead of a test Business Page
- Permission justification is generic — does not reference the actual app workflow
- Privacy policy does not mention Facebook data storage, retention, or deletion
- No test user credentials provided for Meta reviewers to independently test the app
- Data deletion callback URL is missing, broken, or untested
- App description does not match what the screencast demonstrates
- Requesting permissions that the demonstrated use case does not actually require
- Business use case does not align with Meta’s approved use-case categories
This case study describes the general submission structure and common rejection patterns for Facebook App Review. Outcome, timeline, and required documentation vary by app type, permissions requested, and Meta’s current review criteria. No approval is guaranteed.