Field notes

Shipped: bulk edit for answer blocks, with undo

A real-world request we dragged our feet on for nine months. Bulk edit is now in the product, with version-aware undo and a confirmation flow that prevents the silent overwrite that made us nervous in the first place.

PursuitAgent 2 min read Engineering

Bulk edit for answer blocks is in the product as of this morning. Select multiple blocks, apply an edit (find/replace, tag change, owner reassignment, or retire), preview the diff across all selected blocks, and commit. Undo is one click and reverts every block in the batch to its prior version.

Why we dragged our feet

Bulk edit has been in our backlog for nine months. The reason it took so long is that bulk operations on a KB without versioning are how libraries get silently corrupted. A user runs a find/replace, the find pattern hits more blocks than they intended, and the corruption is invisible until a reviewer flags it on a downstream proposal — by which point the correct prior text is gone.

We did not want to ship the feature until block versioning was solid enough to make undo trivially safe. Versioning landed earlier this year (see the block versioning deep-dive) and is the foundation under the broader Knowledge Base governance surface — owners, edit history, retirement. Bulk edit is the workflow that versioning enables.

What ships

  • Find/replace across selected blocks. Preview the diff per block before commit. Each affected block creates a new version with an automatic change note (“bulk find/replace: [pattern] → [replacement]”) and the user as author.
  • Tag changes (add, remove, replace). Tag changes are versioned the same way; the prior tag set is preserved on the prior version.
  • Owner reassignment. Bulk-set owner across selected blocks. The previous owner is recorded in the version metadata.
  • Retire. Marks all selected blocks’ current versions as retired. Citations on past proposals to those versions are unaffected.
  • Undo. Reverts every block in the most recent bulk operation to its prior version. The undo is itself a versioned operation — undoing creates new versions tagged bulk_undo_of: [batch_id].

What it does not do

Bulk edit does not delete versions. The history is append-only; “undo” promotes prior versions, it does not erase the bulk-edit versions. This is intentional. The audit trail shows what happened.

Bulk edit also does not auto-update embeddings during the diff preview. Embeddings recompute on commit, in a background job. This means the preview is text-only; semantic-equivalence checking happens after the user confirms.

How to access

In the KB view, select two or more blocks via the row checkboxes. The bulk-edit menu appears in the toolbar. Confirmation modals are deliberately verbose — they show the count of affected blocks and a sample of the diff before the action commits. We do not consider verbose confirmations a UX problem on this feature; they are the safety the version history alone cannot provide.

Documentation is on the help center and in-app via the ”?” icon. Feedback to the usual channel.