Prepare your review submission
Use these templates after the actual connection and feature test work. Replace every placeholder before submitting.
Build the submission
1. Complete a real test before writing the submission
Open Application test installation
App owner and test user
- Choose one specific feature and the corresponding platform guide. Complete creation, configuration and connection first.
- Follow the user action from a fresh signed-in test session. Check the actual provider result.
- Write down the real screen/button labels you used and the test asset needed. If a reviewer would need a plan or feature flag, prepare it in the supplied application test account.
- Use the files below as drafts. Replace metadata placeholders with your own values, but do not claim an action or approval you have not observed.
Expected result A person can repeat the actual feature using the intended application test account.
If this does not happen If the action cannot be repeated, fix the test setup or feature before improving the wording of the review form.
Reviewer instructions
Provide an application test account that can reach the feature. Keep provider/business account ownership separate. Enter any necessary test-only credentials only through the protected reviewer mechanism supported by the platform.
Copy and complete
APPLICATION REVIEW INSTRUCTIONS — FILL BEFORE SUBMITTING
Application name: [actual name]
Provider app/project ID: [actual ID]
Website: [public production/review website]
Application login URL: [exact reachable URL]
Environment/build: [version and environment]
Feature and permission being demonstrated: [one specific feature/scope]
Test account access: [supply test-only credentials in the provider's protected field; no secret here]
Prerequisites: [required plan, enabled app and permitted test asset]
1. Open [exact login URL] and use the supplied application test account.
2. Open [actual menu > screen].
3. Select [actual Connect button].
4. Use the provider-supported authorized test asset/account flow described here: [details].
5. Select [asset name/type] and return to [application screen].
6. Enter [non-sensitive test content] and select [actual action button].
7. Check [specific application state] and [provider-side result].
8. Disconnect the disposable connection using [actual control], if part of the test.
Expected result: [observable result]
Known restrictions: [sandbox, visibility, quota or reviewer-asset limitations]
Video: [accessible link/file reference and timestamps]
Contact: [monitored app support address]
Remove every placeholder and test these instructions in a fresh session.
Permission explanations
Write one explanation per requested permission. Name the user’s deliberate action and the exact result. Do not use a generic paragraph claiming that every permission is required.
Worked example: Page selection
EXAMPLE — ADAPT TO YOUR REAL WORKING PAGE-SELECTION FLOW
Permission: pages_show_list
User task: Connect one Facebook Page the user is authorized to manage.
Why access is needed: Populate the Page selection list after the user authorizes
the app. The user chooses the Page to connect to their workspace.
Reviewer path: Sign in to the supplied application test account. Open Channels,
select Add channels and start the Facebook Page connection. Complete the permitted
Meta test-asset authorization flow. Select the intended Page in the returned list.
Expected result: The selected Page appears in this workspace's Channels list.
Not covered by this explanation: Publishing, messaging, comments or insights.
Before submission: Add the real website, permitted reviewer access instructions
and the actual video timestamp. Remove this example heading.
Use pages_manage_posts only for an implemented publishing action and prepare its own explanation/video. A Page-list demonstration alone does not justify posting or inbox access.
Record the demonstration
2. Record a usable end-to-end video
Open Current application + the intended provider test asset
App owner / demonstrator
- Before recording, open the correct app domain and test user. Hide credential panels, notifications and unrelated customer data.
- Start at the application login or explain the starting signed-in state permitted by the platform. Show the actual domain and feature.
- Show the provider connection, requested access and asset selection. Do not replace OAuth with a manually inserted successful state.
- Perform the actual feature. Keep the relevant user options and consent visible.
- Show its result in the application and at the provider where appropriate. For posting, a queued item is not the final published result.
- Add timestamps for each requested permission. Save the video, reopen it and test reviewer access to the submitted file/link.
Expected result The reviewer can identify the app, follow the feature and see the result without guessing.
If this does not happen If a recording skips the rejected operation, re-record that real operation. Do not solve missing implementation with captions claiming it works.
Track the actual state
Setup and review record
APP SETUP RECORD — NO SECRET VALUES
Platform / product: [value]
App/project name and ID: [value]
Legal owner / environment: [value]
Application version: [value]
Website and policy URLs: [values]
Actual OAuth redirect URL: [value or not applicable]
Actual webhook URL: [value or not applicable]
Configured permissions: [actual requested values]
Granted permissions/access tier: [console evidence; unknown until checked]
Business/brand verification state: [actual state or not applicable]
Review submission reference/date: [value or not submitted]
Review decision/date and conditions: [value or not reviewed]
Token expiry/rotation responsibility: [person/process only; never the token]
Test account/asset reference: [reference only]
End-to-end test result/date: [actual result or not run]
Open issue and next action: [value]
Final check and resubmission
3. Check the final form and respond to a decision
Open The provider app’s review form
App owner
- Compare the form’s App/project ID, Website, Scopes and requested product with the current configuration. All must refer to the same submitted app.
- Open every public policy/video link while signed out. Use a fresh browser session to test the application login path supplied to the reviewer.
- Provide test-only application access in the protected mechanism supported by the platform. Do not put your provider/business login password or secret keys in an ordinary document.
- Review every scope explanation and video timestamp. Remove all unfinished placeholders and unsupported claims.
- Submit through the owning account’s form. Record its actual reference, date and current status.
- For a rejection, copy the exact item and feedback into your private issue record. Reproduce it, fix the actual cause, repeat the affected test and update the relevant video/instructions.
- After approval, check the specific product/scopes/tier granted and run the feature again. Save that result before considering the setup complete.
Expected result The submission is reproducible and its actual state and follow-up actions are recorded.
If this does not happen A draft, a sent form or an app created under another account is not proof that this app’s required permissions were approved.