Moderate new user posts in Firebase before they go live

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.