> ## Documentation Index
> Fetch the complete documentation index at: https://docs.moderationapi.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Review
> The inbox, content views, and how content gets reviewed
Review is where people look at content. Everything you submit lands there, and you
decide what a moderator sees by building **content views** on top of it.
## Inbox and content views
Plenty of content gets flagged, and most of it your rules settle on their own — allowed
or rejected on the spot. The rest is the judgement calls: the ones your thresholds and
rules deliberately don't make for you.
**Inbox** is where those land, from every channel. It always exists, you can't narrow
it, and its badge counts what's still pending. It's the safety net: if something needs a
person, it's here even when it matches none of your views.
What the system settled itself isn't in the inbox — there's no decision left to make.
It's all still stored, though, and a view can select it, which is how teams audit their
own auto-rejections.
**Content views** are saved slices of the same content — "Escalations", "German",
"Listings". A view is a filter plus a few workflow settings, shared with everyone on
the project. Views don't copy or move content, they're windows onto it, so one item can
appear in several at once.
Everything you send to a [moderation endpoint](/content-moderation/submit-content)
is stored and can be put in a view. What your rules left for a human also shows up
in the inbox.
They open an item, read it in context, and run an
[action](/actions/content-actions) — or correct what the policies got wrong.
Resolved items leave the pending list. Whether they leave *other* views too is a
per-view setting.
## Where to go next
Create a view, filter it, and save it for the team.
Ordering, resolve behaviour, deduplication and columns.
Working through a view, item by item.
Views worth copying, and when to use them.