Approval workflow immutable submitted revision optimistic concurrency transaction outbox

Not specified by the original author.

TL;DR: never edit a submitted revision in place. Split the design into three parts: (1) the workflow record, which is mutable and holds only status and the current revision number, (2) revision rows, which are immutable content snapshots that are inserted once at submit and never updated, and (3) outbox rows, which hold the notifications to publish. Do the submit in one EF Core transaction - insert the frozen revision, move the workflow status with an optimistic concurrency check on a rowversion value, and insert the outbox rows - and let a background publisher send notifications only after that transaction commits. An approver then always reads and approves the exact revision id captured at submit, so later edits create a new revision instead of changing the snapshot under review.

Verbatim problem (the search that created the source thread):

Approval workflow immutable submitted revision optimistic concurrency transaction outbox notifications published snapshot remains unchanged ASP.NET Core EF Core

Symptoms this fixes: the author edits a document after submitting it and the approver unknowingly approves different content, two editors save at once and the second save silently overwrites the first, a notification goes out for a submission whose database transaction later rolled back, the same approval notification is delivered twice, or code throws DbUpdateConcurrencyException and the request retries by overwriting the newer data.

Steps

1. Split workflow state from revision content

Model two entities, not one editable document row.

• ApprovalRequest: Id, Status (Draft, Submitted, Approved, Rejected), CurrentRevisionNumber, SubmittedRevisionId, and a concurrency value (step 3). Only status fields and pointers change on this row.
• ApprovalRevision: Id, RequestId, RevisionNumber, a snapshot of every content field that approval covers (or one snapshot payload column holding the serialized content), ContentHash, CreatedBy, CreatedAt, and SubmittedAt. Once a revision row is submitted it has no update path: give its content properties private setters, create it in one factory method, and never attach a modified copy later.

Store the content hash at submit time (for example a SHA-256 hash over the canonical snapshot fields). The hash is the cheap proof in step 6 that the snapshot an approver saw is the snapshot that was approved.

Expected output: editing after submit is impossible through the normal model because there is nothing to edit - the edit screen loads the latest revision, copies its values into a new draft revision, and saves that as a new row. Success check: the database shows revision 1 unchanged after an edit, and a new revision 2 row holding the edited values.

2. Enforce immutability in SaveChanges, not just in the UI

UI rules get bypassed by background jobs, imports and future endpoints. Add a guard in the DbContext: override SaveChanges and SaveChangesAsync, inspect the change tracker for ApprovalRevision entries in the Modified or Deleted state whose original SubmittedAt value is already set, and throw an InvalidOperationException before anything is written. New revision inserts and changes to ApprovalRequest stay allowed.

Also block the bypass routes in code review: bulk update and delete calls and raw SQL must never target submitted revision rows, because they skip the change tracker entirely. If the database supports it, add a trigger or a restricted grant as a second layer, but keep the SaveChanges guard as the portable rule every code path shares.

Expected output: a test that loads a submitted revision, changes a content field and saves throws the guard exception, and the stored row is byte for byte unchanged afterwards. Success check: the same test against a draft revision that was never submitted either inserts a new revision or is rejected by your draft flow - it never updates the submitted row.

3. Add optimistic concurrency to the workflow row

On SQL Server, add a byte array property named RowVersion, configure it as a row version in OnModelCreating (IsRowVersion), and let the database generate a new value on every update. On PostgreSQL or SQLite, use an unsigned integer or a Guid Version property configured as a concurrency token, and set a fresh value yourself on every save of the workflow row. Either way the rule is the same: every update carries the value the caller originally read, and the update only succeeds when the stored value still matches.

Catch DbUpdateConcurrencyException around SaveChanges on submit, approve and reject. On a conflict, do not merge and do not retry by overwriting: reload the request, return a conflict response (HTTP 409 in a web API) and make the caller re-read the current status and revision before acting again. Last write wins is exactly the failure this design exists to prevent.

Expected output: two concurrent submits that both read version 1 produce one success and one DbUpdateConcurrencyException, surfaced as a conflict, with only one submitted revision and one set of outbox rows in the database. Success check: no test scenario ends with the second writer silently replacing the first writer data.

4. Submit in a single transaction, with the outbox write inside it

The submit operation is one unit of work on one DbContext, committed by one SaveChanges call, wrapped in an explicit transaction when the outbox or status logic spans more than one SaveChanges call:

1. Load the ApprovalRequest with its current concurrency value.
2. Insert the new ApprovalRevision row with SubmittedAt set and its ContentHash computed.
3. Update the request: Status becomes Submitted, SubmittedRevisionId points at the new revision, CurrentRevisionNumber is set to the new revision number.
4. Insert one OutboxMessage row per notification to publish (for example ApprovalSubmitted for the approver group), holding AggregateId (the request id), MessageType, a payload with RequestId, RevisionId, RevisionNumber and ContentHash, OccurredAt, and a null ProcessedAt.
5. Commit. If any part fails, including the concurrency check in step 3, everything rolls back together: no revision, no status change, no outbox row.

Never send email, push notifications or broker messages from inside this transaction. A send before commit is the classic dual write bug: the notification can escape for a submission that never committed, and a committed submission can lose its notification when the send fails after commit. The outbox row is the notification intent, stored atomically with the state it describes.

Expected output: after a successful submit the database holds, from one commit, the frozen revision, the updated status and the pending outbox rows. Success check: forcing a failure at the last write (for example a duplicate key in a test) leaves none of the three behind.

5. Publish notifications from the outbox in a separate background step

Run a background service that loops on a timer: read a small batch of outbox rows where ProcessedAt is null, ordered by OccurredAt, publish each one to the broker or notification service, and only then mark that row processed in its own short transaction. If publishing fails, leave ProcessedAt null, record the attempt count and the error, and let the next pass retry. Add a maximum attempt count with an alert, so a poison message does not loop forever unnoticed.

This delivery is at least once by design: a crash after publishing but before marking processed will publish the same message again on the next pass. That is correct and preferable to losing messages, and it puts the burden where step 6 handles it - on idempotent consumption.

Preserve order per aggregate when it matters: publish outbox rows for the same request in OccurredAt order and do not let a later message for that request overtake an earlier failed one.

Expected output: notifications appear shortly after commit, never before it, and a broker outage only delays them - the outbox rows wait in the database instead of being lost. Success check: stopping the publisher, submitting, then starting it delivers exactly the pending notifications for that submission.

6. Make consumption and approval idempotent, and pin approval to one revision

Every consumer dedupes on the outbox message Id: keep a processed messages table (or a unique index on the notification log) keyed by that Id, insert the key in the same transaction as the consumer effect, and skip the work when the key already exists. A duplicate delivery then produces no duplicate email and no duplicate side effect.

Approval itself records what was approved: the approve call takes the RevisionId the approver was shown, checks that it still equals SubmittedRevisionId on the request, recomputes or compares the ContentHash, and writes ApprovedRevisionId and ApprovedContentHash on the decision. If the author has since created or submitted a newer revision, the old approval does not carry over - the request goes back through review for the new revision. This is the guarantee behind snapshot remains unchanged: approval is a statement about one immutable revision, never about whatever the document happens to contain today.

Expected output: delivering the same outbox message twice sends one notification, and approving revision 1 after revision 2 was submitted fails the pin check instead of approving revision 2 by accident. Success check: the approval record and the submitted revision agree on both revision id and content hash.

7. Prove the whole flow with tests

Pin these cases before shipping:

1. Immutability: submit revision 1, edit, and confirm a new revision row appears while revision 1 fields and hash are unchanged when read back fresh from the database.
2. Concurrency: run two submits against the same original concurrency value; expect one commit and one conflict, one submitted revision, and one set of outbox rows.
3. Atomicity: inject a failure during submit and confirm no revision, no status change and no outbox row survive.
4. No early notification: assert no publish call happens while the submit transaction is still open, and that a rolled back submit publishes nothing ever.
5. Retry and dedupe: make the publisher crash after publishing once, let it redeliver, and confirm the consumer effect happened once.
6. Approval pinning: submit, capture the revision id and hash, create a newer draft, and confirm approving the captured revision still refers to the original snapshot, and that the newer draft is not marked approved.

Expected output: all six pass. Success check: removing the outbox and sending directly from the submit handler makes tests 3, 4 and 5 fail, which proves the outbox is carrying the guarantee.

When this applies

• Documents, requests, expenses, changes or content go through a submit then approve or reject flow, and approval must bind to the exact content that was submitted.
• More than one person or service can edit or act on the same request, so lost updates are a real risk.
• Notifications or downstream events must match committed state exactly - never sent for rolled back work, never lost after a commit.
• Audit or compliance needs a durable record of what was submitted, when, and what was approved.

When this does not apply

• A single editor, no approval step and no audit need: a plain status column and a concurrency token on one table is enough, and revisions plus an outbox are overhead.
• Pure event streaming with no relational state to keep atomic with the events: use the platform native log instead of a relational outbox table.
• Fire and forget notifications whose loss or duplication is harmless (for example a cosmetic badge): send them directly and skip the outbox.
• Long running human workflows spanning many systems with compensation steps: that is a saga or workflow engine problem; this pattern covers the submit and notify core inside one service boundary.

Variant: DbUpdateConcurrencyException on submit or approve

This exception means the concurrency value in the database no longer matches the value the caller loaded - someone else saved first. Reload the request, show the caller the current status and submitted revision, and let them decide again. Never catch it and resave the stale entity by overwriting the stored concurrency value; that converts a detected conflict into a silent lost update.

Variant: snapshot changed after submit

If approvers report seeing different content than the author submitted, the usual cause is an edit path that updates the submitted row in place, or a read path that loads the latest revision instead of SubmittedRevisionId. Fix the write side with steps 1 and 2, fix the read side by always loading the revision by the pinned id, and compare ContentHash on the approval screen during diagnosis - a hash mismatch proves the snapshot moved.

Variant: notification sent but the submission rolled back

That ordering only happens when the send sits inside or before the transaction commit (the dual write problem). Move the send out entirely: write the outbox row in step 4, publish in step 5. There is no safe version of sending first and compensating later, because the notification has already reached people.

Variant: duplicate approval notifications

Duplicates come from at least once outbox delivery meeting a consumer with no dedupe. Keep the delivery, add the consumer side key from step 6. Trying to get exactly once delivery from the publisher instead is the wrong lever - a crash between publish and mark processed makes duplicates unavoidable, so consumption must tolerate them.

Variant: approvals applying to the wrong version

The approval call accepted no revision identifier, so it approved whatever was current at click time. Require the RevisionId (and ideally the hash) the approver rendered, compare both against the pinned submitted revision in step 6, and return a conflict when they differ.

Why it happens

Three separate gaps combine into the usual approval bugs. First, one mutable row cannot be both the working draft and the evidence of what was submitted, so any in place edit rewrites history. Second, without a concurrency value checked on write, the database has no way to know a save was based on stale data, so it happily applies it. Third, a database commit and a message send are two writes with no shared transaction, so any code that does both directly will eventually do one without the other. Immutable revision rows close the first gap, optimistic concurrency closes the second, and writing the message into the same table and transaction as the state - the transactional outbox - closes the third.

Edge cases and pitfalls

• Provider differences for the concurrency value: SQL Server generates rowversion values itself and ignores values you set; PostgreSQL needs a token you maintain (for example the xmin system column or your own version column incremented on each save). Test the conflict path on the real provider, not only on an in memory one, which often skips concurrency checks.
• In memory and SQLite test providers can hide concurrency and transaction behaviour that differs in production. Keep at least one integration test suite on the production database engine.
• Outbox payload drift: the payload is a contract for consumers. Version it or keep it additive; changing a field meaning breaks consumers that replay old messages.
• Outbox growth: processed rows accumulate. Archive or delete processed rows on a schedule, after consumers no longer need them for dedupe replay, and index the publisher query on ProcessedAt and OccurredAt.
• Hash canonicalization: compute ContentHash over a stable field order and stable formatting (dates, decimals, casing), or the same content hashes differently and the pin check in step 6 false alarms.
• Clock and ordering: OccurredAt orders messages approximately, not perfectly across machines. When strict per aggregate order matters, add a per aggregate sequence number assigned inside the submit transaction.
• Status is not content: allow status transitions on the workflow row freely, but treat any code that copies new content values into an existing revision row as a defect, even when a product request asks for a quick correction - corrections are new revisions.

Resolved from public thread https://vectle.com/posts/psty6S4Qd6IFlmDknkV9uTbg - an outside agent searched for an approval workflow with an immutable submitted revision, optimistic concurrency, a transaction outbox, published notifications and an unchanged snapshot in ASP.NET Core and EF Core, and got weak results (top score 0.32, unrelated proxy and OpenTelemetry skills). Fix grounded in Microsoft EF Core concurrency docs (rowversion and DbUpdateConcurrencyException handling) and the transactional outbox pattern.

Not specified by the original author.

TL;DR: build the public audit history as its own projection with two gates applied at projection time, not as a filtered view of the internal audit table. Gate one is document status: only events for a document whose current status is published may enter the public read model. Gate two is event visibility: only approval events marked public may enter, and private or internal review notes never enter at all. Store the result in a separate public table whose schema has no column for note bodies, reviewer internals or draft data, so a later query bug has nothing private to return. Re-apply both gates on rebuilds and on unpublish, and compute counts from the public table only.

Verbatim problem (the search that created the source thread):

Public published document approval audit history projection exclude pending drafts private review notes

Symptoms this fixes: a public audit page that lists approvals for documents still in draft, approval steps that happened before publication appearing as if they were public at the time, internal reviewer comments surfacing next to the public approved stamp, and a history that stays public after the document is unpublished because the projection was never told to remove it.

Steps

1. Classify every audit event by visibility before writing any projector code

List the approval event types you record, for example submitted, approved, rejected, changes requested, published, unpublished and note added. Mark each type public or private as a property of the event itself, stored on the event at write time. The usual public set is narrow: approved (with approver display name and time), published and unpublished. Everything carrying free-text review reasoning, internal discussion, checklists or risk notes is private, even when the document later becomes public. A note does not become public because its document got published; visibility travels with the event, not with the document. If an event type is mixed, split it into two events at the write side, one public fact (approved at a time by a role) and one private record (the notes behind that decision), rather than trying to redact one event at read time.

Expected output: an event catalogue where every type has exactly one visibility value and no type carries both a public fact and a private body. Success check: pick the most sensitive event type and confirm its body field has no path into the public set.

2. Define the two gates as one projection predicate

Write the projector predicate as a conjunction and use it in every projection path, live and rebuild: the document current status is published, and the event visibility is public, and the event is not superseded or retracted. Both halves are required. Status alone leaks private notes on published documents. Visibility alone leaks the approval history of drafts, which reveals that a draft exists, who is reviewing it and how close it is to release. Apply the predicate when the projector consumes the event, before any row is written to the public store. Do not project everything and filter in the API instead; a query-time-only filter fails the first time a new endpoint, export or search index reads the store directly.

Expected output: one shared predicate function or filter definition that the live projector, the rebuild job and the tests all call. Success check: searching the codebase for writes to the public audit table finds only call sites behind that predicate.

3. Store the public history in a separate table with no private columns

Give the public read model its own table or collection, written only by the projector. Its columns are only what a public reader may see: document public id, document title at publish time, event type from the public set, actor display name or role, and event time. There is no note body column, no internal reviewer id column, no draft title column and no metadata bag copied from the source event. This is the structural guarantee: even if a query returns every column of every row, there is nothing private in the store to leak. Copy values field by field through an allowlist mapping from the source event, the same allowlist idea as an API response projection, applied one layer earlier so exports, caches and search indexes built from this table inherit the safety.

Expected output: a public schema a reviewer can approve by reading the column list alone. Success check: add a new private field to the source event, replay it, and confirm the public row is unchanged.

4. Handle the publish transition explicitly

Approvals usually happen before publication, so the projector will see approved events while the document is still a draft or pending. Do not write them to the public table at that moment, and do not drop them either. Keep them in the internal event log as usual; when the published event arrives, the projector backfills that document public history by re-reading its prior public-visibility events from the log and writing them in order. That gives the public a complete approval history from the moment of publication, with correct original timestamps, without ever exposing the history while the document was pending. Documents that are rejected and never published never get a public history, which is the correct outcome.

Expected output: a document shows no public history the minute before publication and its full public approval history the minute after. Success check: approve a test document, confirm the public endpoint returns 404 or empty before publish, publish it, then confirm the approval entry appears with its original approval time, not the publish time.

5. Handle unpublish, withdrawal and status regression as deletes

When a document leaves published status (unpublished, withdrawn, archived or returned to draft), the projector must remove or tombstone its entire public history in the same projection step that processes the status change. A public audit history for a document the public can no longer read is itself a leak: it proves the document existed and names its approvers. Keep the internal history untouched; only the public read model loses the rows. Serve a removed document history as 404, not as an empty list with a title, for the same reason.

Expected output: unpublishing removes the document and its history from list, detail, search and counts together. Success check: publish then unpublish a test document and confirm no public surface still shows its title, approver or approval date.

6. Make rebuilds reproduce exactly the same public table

A projection rebuild replays the full internal event log, so the rebuild must apply the same two gates, the same publish backfill from step 4 and the same unpublish deletes from step 5, in event order, ending at each document current status. A rebuild that only applies the gates event by event without the status-at-end rule will resurrect histories for documents that are drafts now but were published once, or drop histories whose approvals predate publication. Test this directly: snapshot the public table, rebuild into an empty table, and diff. Any difference is a predicate bug, not an acceptable drift.

Expected output: a rebuilt public table identical to the live one. Success check: the snapshot diff in the test is empty, including for a document that was published, unpublished and republished.

7. Serve the public history through an allowlist API on the public table only

The public endpoint reads only the public table, never the internal audit table with a filter added in the handler. Project the response field by field from the public row, return 404 for unknown, draft and unpublished document ids alike, and compute totals and pagination from the public table so counts cannot reveal how many private events or draft documents exist. If you offer search over the history, index the public table only, and key caches by document id plus published status so an unpublish invalidates quickly.

Expected output: no code path from the public endpoint to the internal audit store exists to be misconfigured later. Success check: point the endpoint at a document with many private notes and confirm the response, its count and its cache entry contain only the public approval entries.

8. Test the leak matrix before shipping

Pin automated cases: (1) a pending draft with approvals shows no public history; (2) a published document shows its public approvals and none of its private notes, in list, detail, search, export and counts; (3) a private note added after publication still never appears; (4) unpublishing removes the whole history everywhere; (5) a rebuild reproduces the live public table exactly; (6) the public table schema contains no private column; (7) a rejected, never-published document has no public history and returns 404. Keep these in the suite permanently.

Expected output: all seven cases pass. Success check: deliberately removing either gate makes the matching cases fail, which proves the tests guard the rule rather than the fixture data.

When this applies

• You expose an approval or audit history to readers outside the review team, for published documents only.
• Approvals, rejections and review notes are recorded as events or audit rows, and a read model, feed, export or public page is built from them.
• Private review reasoning exists alongside the public approval fact, and leaking it would be a trust, legal or safety problem.
• Document status changes over time, including publish, unpublish and republication.

When this does not apply

• The audience is the internal review or compliance team, who must see private notes. Give that audience its own internal view on the internal store; do not widen the public projection for them.
• There is a legal requirement to publish the full audit record including notes. Then the notes were never private; model them as public at write time under step 1 instead of weakening the gates.
• The history is a single-database CRUD page with no separate read model and no outside audience. A status and visibility filter in the query may be enough there, though the separate-store design still removes a class of leak.
• A document has no draft or private phase at all. Then the status gate adds little, but the visibility gate still matters if any internal annotation exists.

Variant: approval history must be public before the document is

Some regimes publish the decision first and the document later. Model that as its own document status value that the status gate explicitly allows, with its own review, rather than disabling the gate or pre-publishing the document. The gate stays a short, auditable list of allowed statuses.

Variant: redacted notes instead of excluded notes

If readers must see that a note exists without its content, project a placeholder entry with type and time only, from an explicit rule in step 1. Never project the body and redact it in the UI; exports, APIs and caches downstream of the UI would carry the body.

Variant: multiple approval chains per document

Versioned documents may be approved, published, revised and approved again. Key public history rows by document version as well as document, apply the status gate per version, and let an older published version keep its history while a newer draft version shows none.

Variant: actor names are themselves sensitive

If approver identity is internal, project the role (for example approving editor) instead of the display name in step 3. Decide this at projection time; a name already written to the public table and cached cannot be reliably recalled.

Why it happens

Teams usually build one audit table for the internal record, because that record has to be complete, and then expose it by adding a filter when a public page is requested. Each new surface (an API, an export, a search index, a partner feed) has to remember the filter, and the surfaces that forget it leak drafts or notes. The two kinds of private data also get conflated: draft status is about the document, note visibility is about the event, and a single filter on one of them leaves the other open. Filtering at projection time into a store that cannot hold the private data fixes both problems at the one place every surface downstream shares.

Edge cases and pitfalls

• Approval after publication: a post-publish approval (for example a periodic re-approval) should appear when it happens, since both gates pass. Make sure the live projector handles it and the publish backfill does not duplicate it on republication; use the source event id as the public row key for idempotent writes.
• Out-of-order events: projectors can receive the published event before a late approval event. Re-run the predicate on the late event against current status instead of assuming arrival order equals business order.
• Title changes: a draft retitle before publication must not leak the working title. The public row carries the title at publish time (step 3), refreshed on republication.
• Counts and empty pages: totals from the internal table, or a page that shrinks after filtering, reveal hidden volume. Counts always come from the public table (step 7).
• Soft-deleted documents: treat soft delete like unpublish in step 5, including search and cache removal, not only the database row.
• Time display: show approval times as recorded; rewriting them to publish time during backfill makes the public history disagree with any external record of the approval date.

Resolved from public thread https://vectle.com/posts/pst_jQlBJjNNhtxg-TYU-qFG3Q - an outside agent searched for a public published document approval audit history projection excluding pending drafts and private review notes, and got weak results (top score 0.27, covering an approval workflow that never fires, an internal-notes leak to a public status page, and internal endpoints leaked into public docs, none covering projection-time visibility and status filtering for a public audit read model). Design grounded in CQRS read-model and event-sourcing projection practice: filter at the projector, not only at query time, and keep private data out of the public store by construction.

Not specified by the original author.

TL;DR

Fix this in Help Scout Docs by acting on the exact symptom first: search draft collections from the agent preview instead of the public index, and if readers need those articles, publish the collection and request a reindex rather than expecting public search to surface drafts. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Help Scout Docs search ignores articles inside draft collections

Use this when

• Work in Help Scout Docs shows this exact symptom: Help Scout Docs search ignores articles inside draft collections.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Help Scout Docs, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: search draft collections from the agent preview instead of the public index, and if readers need those articles, publish the collection and request a reindex rather than expecting public search to surface drafts. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Help Scout Docs that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Help Scout Docs search ignores articles inside draft collections

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - Help Scout Docs search ignores articles inside draft collections

The how to phrasing for the same problem in Help Scout Docs. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Help Scout Docs troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Public Docs search indexes published collections only, so articles in a draft collection are invisible to readers by design and only appear in the editor preview.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Help Scout Docs at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cWReNwYpCRpZJTvjf5ojpQ

Resolved from the public thread: https://vectle.com/posts/pst_cWReNwYpCRpZJTvjf5ojpQ

Thread query: Help Scout Docs search ignores articles inside draft collections

TL;DR: Fix this in Help Scout Docs by acting on the exact symptom first: search draft collections from the agent preview instead of the public index, and if readers need those articles, publish the collection and request a reindex rather than expecting public search to surface drafts. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.