# Review a release before you share it

BerryBlox creator resources
Edition 1.0 · November 4, 2026

Check the player journey, source rights, purchase behavior, and rollback evidence before an owner makes the release decision.

Take away: A clear release decision with remaining gaps visible.
Beginner · 7 min read

Original BerryBlox editorial worksheet. You may copy, adapt, and use it in your own projects and team handoffs. Linked sources and third-party materials retain their own terms.

Download this Markdown file and fill it in with any text editor. Your notes stay in your copy; this worksheet does not upload or save them to BerryBlox.

## Identify exactly what is being reviewed

Freeze a named candidate and preserve a recoverable copy. List included features, known issues, source rights, and supported devices. A checklist can organize a decision; it cannot grant release permission or certify a build.

- [ ] The intended first session works from a fresh start.
- [ ] Returning players and existing saves have been considered.
- [ ] Failure, retry, respawn, and rejoin cases have explicit results.
- [ ] Assets, music, names, and references have documented reuse permission.
- [ ] Screenshots and descriptions match this candidate's actual behavior.

- **Candidate / source revision / artifact location:** ____________________
- **Owner responsible for release:** ____________________
- **What changed:** ____________________
- **Supported devices and inputs actually checked:** ____________________
- **Known issues and user impact:** ____________________
- **Restore point and rollback owner:** ____________________

## Review purchases only if your game offers them

Keep the core experience understandable without a purchase. Explain the item, price, duration, and what the player keeps. Avoid claims of guaranteed earnings or success.

Roblox developer products can be purchased repeatedly; passes are for one-time purchases. For developer products, purchase completion must be handled through ProcessReceipt on the server. PromptProductPurchaseFinished is not proof of a successful purchase. Use Roblox's current documentation when implementing and reviewing receipts.

- [ ] Product identity and current price are shown clearly before the Roblox purchase prompt.
- [ ] The grant is validated against the correct player, product, and receipt.
- [ ] Receipt retries do not create duplicate grants; interrupted or pending grants have a recovery path.
- [ ] Refusal, cancellation, repeated delivery, and returning-player cases have recorded results.
- [ ] Unsupported or unverified purchase behavior blocks release of that feature.

Source checked November 4, 2026: [Roblox: Developer products](https://create.roblox.com/docs/production/monetization/developer-products).

## Separate evidence from assumptions

Use a small evidence table: requirement, build, environment, observed result, evidence link, and unresolved limit. Include real input and the complete result; a green file check does not establish visible quality or integration.

Check the current Roblox publishing and content requirements for your intended audience before release. Policy eligibility and moderation decisions belong to Roblox; this guide is not a legal or platform approval.

- **Requirement / evidence / reviewer:** ____________________
- **Local checks completed:** ____________________
- **Studio checks completed:** ____________________
- **Real-device or live-service checks completed:** ____________________
- **Blocked or not-tested checks and next owner:** ____________________

Source checked November 4, 2026: [Roblox: Create and publish games and places](https://create.roblox.com/docs/production/publishing/publish-games-and-places).

## Make a decision you can explain

Record approve, hold, or reduce scope, with the reason and the responsible owner. Decide what to monitor after an authorized release and what would trigger a rollback. Leave publishing and any real purchases to the authorized operator.

- **Decision / decision maker / date:** ____________________
- **Blocking issues and their owners:** ____________________
- **First checks after release:** ____________________
- **Rollback trigger / restore procedure:** ____________________
- **Next review date:** ____________________

## Rehearse the hold decision

Before review, name a concrete condition that would stop release: for example, a returning save losing progress or a paid reward being granted twice. Record who can resolve the issue and what fresh evidence would remove the hold.

Check that the restore procedure identifies an actual recoverable candidate and a responsible operator. Writing rollback on a checklist does not prove that a restore can be performed.

- **Stop condition / next owner / required retest / recoverable candidate:** ____________________

## Evidence and limits

This is a planning and review checklist with no executable purchase code or game assets. It does not prove secure receipt handling, successful payments, Studio performance, or release readiness. Those need evidence from your implementation and the relevant environment.

No release, purchase, affiliate arrangement, or publishing action is performed by this resource. Verify current platform documentation again when your implementation changes.