---
title: Reviewing recommendations
nav: Review recommendations
description: How the inbox is ordered, what makes an item approvable, and what approval does and does not do.
group: workflows
order: 2
status: shipped
updated: 2026-09-21
---

The Recommendations page is the decision layer. Everything upstream of it is calculation; everything downstream is deployment.

## What lands here

A recommendation is created when a market's parity target differs materially from its current price — at least 5% — and the calculation's confidence is high enough to act on.

Items are ordered by **evidence-weighted impact**: the size of the change, weighted by how much the evidence supports it. A large change on thin data does not outrank a moderate change on solid data.

## Reading an item

Each item carries its application, product, plan, billing period, and market, along with:

- the current price and the recommended price;
- the change as a ratio;
- a confidence level and score;
- the explanation lines from the calculation — the economic factor applied, the FX rate used, whether an override took precedence, and the rounding step.

If a product has been withdrawn from the store, the item is marked with the date and can no longer be approved. It stays visible so it can be dismissed.

## What approval does

Approving records a decision. **It writes nothing to any store.** The confirmation says so explicitly, every time, because the whole design depends on that being unambiguous.

An approved recommendation becomes eligible to be staged into a deployment draft — a separate action, described in [Staging and publishing](/guidelines/dry-run-and-publish).

## Bulk decisions

Select many and approve or dismiss in one action. The button states how many of the selected items are actually approvable, which is often fewer than the number selected.

The result lists every skipped item individually with its reason. Skips are reported by product and market rather than by internal id — a reviewer who selected forty needs to know which ones are still waiting, and an id tells them nothing.

## Store drift alerts

Alerts appear above the inbox when the store's actual price no longer matches what was expected — usually because someone changed a price in Play Console directly. See [Drift](/guidelines/drift).

## A known structural limit

The inbox is a single flat list scoped to the workspace. It carries each item's application name but does not group or filter by application, product, or plan.

With one connected app this reads fine. With several it becomes an undifferentiated pile, and the per-application context that the pricing matrix provides above the table has no equivalent here. Adding that structure is open work, not a design position.