# Moderate new user posts in Firebase before they go live

> Every new review, listing, or community post gets judged against your house rules, marked approved, held, or blocked, and only the risky ones reach your team.

- Workflow type: agent
- Services: Firebase, Slack Bot
- Categories: Operations, Product
- Published: 2026-08-04

## What it does

- Watches the collection where your user submitted content lands and picks up each new review, listing, or community post as it arrives
- Looks at the author's recent earlier submissions too, so repeat spammers get caught as a pattern instead of being judged one post at a time
- Checks the content against your house policy covering scam and affiliate spam, harassment and hate, adult content, exposed personal details, and attempts to move the deal off your platform
- Writes a verdict of approved, needs review, or blocked back onto the record along with a short reason, a severity, and a timestamp, so your app can hide or hold the content on its own
- Posts only the flagged and blocked items to your moderation channel in Slack, with enough context for a human to review and overturn the call

## What you'll need

- A Firebase project with the collection where your user generated content is stored
- The names of the fields on those records that hold the submitted text and the author id
- A Slack workspace and a moderation channel for the flagged items
- Your house rules for what counts as acceptable content, in whatever wording you already use

## Prompt

Whenever a new document lands in my Firestore collection of user generated content (reviews, listings, and community posts), I want you to moderate it against my house policy before it can do any damage. Use the Firebase poll trigger for a new document in a collection, pointed at that collection.

Start by reading the submitted text and the author id off the triggering document. Remember that Firestore wraps every field in a typed value envelope, so a field arrives as something like {"fields": {"body": {"stringValue": "..."}, "authorId": {"stringValue": "..."}}}. Unwrap those before you reason about them, and keep hold of the document's full resource name, which looks like projects/{projectId}/databases/(default)/documents/{collection}/{docId}.

Before judging the post on its own, use Run Firestore Query on the same collection to pull that author's recent prior submissions: filter on the author id field equal to this author, order by the creation timestamp descending, and limit it to roughly the last twenty. The point is that repeat spammers get caught as a pattern rather than judged one post at a time. If the same author has been posting the same link, the same pitch, or the same abuse repeatedly, treat that as an aggravating factor and escalate the severity even when the single post in isolation looks marginal.

Judge the content against this house policy: scam and affiliate link spam, including referral link dumping and repetitive promotional posting; harassment, hate, and targeted abuse; adult or sexual content; exposed personal details such as phone numbers, home addresses, card numbers, or government id numbers, whether the author's own or someone else's; and attempts to take the transaction off platform, such as asking to pay directly, move to a private messaging app, or deal outside the marketplace.

Land on exactly one verdict: approved, needs_review, or blocked. Reserve blocked for content that clearly and unambiguously violates the policy. Whenever the call is genuinely borderline, prefer needs_review over blocked. It is much worse to silently take down a legitimate post than to route a grey area to a human.

Write the verdict back onto the triggering document with Update Firestore Document, patching a moderation status field set to approved, needs_review, or blocked, a short one-sentence reason explaining the call, a severity, and a moderation timestamp. This is important: a Firestore PATCH replaces the whole document unless you limit it with updateMask.fieldPaths, so pass an update mask naming only the moderation fields. The user's original content fields must never be clobbered. My app reads the status field itself to hide or hold the content, so this write is what actually enforces the decision.

Only when the verdict is needs_review or blocked, post it to my moderation channel using the Slack Bot Send a Message operation. Include the verdict, the reason, the severity, a short excerpt of the content (a couple of lines, enough to judge without reprinting the whole thing), the author id, a note if this author has prior flagged submissions, and the full Firestore document path so a human can jump straight to the record and override the call.

Keep clean items out of Slack entirely. Approved content still gets its status written to Firestore, but it must not generate a Slack message, so the moderation channel stays signal only and my team actually keeps reading it.

## How to customize

- Rewrite the house policy in your own words to match your community, and add or drop categories as your rules change
- Decide how far back to look at an author's history, and how much weight repeat offences should carry
- Rename the fields the verdict is written to so they line up with what your app already reads
- Change which channel gets the alerts, or split blocked items and borderline items into separate channels

## FAQ

### Does this delete or hide the content by itself?

No. It only writes a verdict onto the record, so your app stays in control of what actually happens. Most teams read that field and hide anything blocked, hold anything marked needs review, and show the rest. Nothing is deleted and the original submission is left untouched.

### Will it overwrite the rest of the record?

No. Only the moderation fields are added or updated. The user's original text, images, and any other fields on the record are left exactly as they were.

### What happens with borderline content?

It is deliberately biased toward marking things needs review rather than blocked whenever the call is genuinely close. That keeps a person in the loop for the grey areas instead of silently taking down something legitimate.

### Will clean posts clutter my Slack channel?

No. Approved content never gets posted to Slack. Only flagged and blocked items are sent, so the channel stays worth reading and your team is not scrolling past hundreds of harmless posts.

### Can a human overrule the decision?

Yes, and that is the point of the Slack alert. Each message carries the verdict, the reason, a short excerpt, the author, and a direct pointer to the record, so a moderator can check the call and change the status themselves.

### Does it work for reviews, listings, and comments at the same time?

It watches one collection, so if all your user content lands in the same place it handles every type. If reviews and listings live in separate collections, run a copy for each with its own policy wording.

Use this prompt in General Input: https://www.generalinput.com/prompts/moderate-new-user-posts-in-firebase-before-they-go-live