Review a release before you share it
Check the player journey, source rights, purchase behavior, and rollback evidence before an owner makes the release decision.
A clear release decision with remaining gaps visible.
Completed example
Original fictional example. These are filled-in worksheet answers, not evidence of a built or tested game.
Hold an orchard build with an unresolved repeat reward
- Candidate
- Orchard Delivery, internal candidate orchard-r3. Record the actual saved revision and output location before any release review.
- Required checks
- Spawn-to-basket route, incomplete delivery, repeated delivery, reconnect behavior, and phone input. A check needs a recorded result against this candidate.
- Illustrative gap
- The repeated-delivery result is unresolved. A screenshot of the open gate cannot establish whether a second completion is prevented.
- Decision
- Hold. Assign the repeat-delivery check to the systems owner and require its evidence before another review. Do not publish this candidate.
- Recovery
- Retain the last reviewed source and record how to restore it. Any source change creates a new candidate for the affected checks.
Expected resultA defensible hold decision tied to a specific candidate, one unresolved behavior, and a named path back to review.
Try it in your blank worksheetIdentify 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.
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.
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.