Check whether one solution would satisfy both requests
“Export reports” might mean a finance admin needs monthly CSV data for reconciliation, while a manager wants a presentation-ready PDF. They share a verb, but a CSV export would not solve the second job.
Compare the user, task, constraints, frequency, and desired outcome. If one shipped change could satisfy both, they may be duplicates. If not, keep separate ideas and note the relationship in the discussion or your team’s planning notes.
The request template makes these details explicit. AI suggestions can help locate candidates, but a similarity suggestion is not enough reason to merge.
Check the audience before the content
A private request cannot become public just because it resembles a public idea. Review both the visibility boundary and the wording of the source. Customer names, internal constraints, or support excerpts may need to stay private even when the underlying need can be described publicly.
In BuildCaster, merge targets must belong to the same product and have compatible audiences. Pending source details do not become public through a merge. Treat those checks as a minimum; an editor still needs to decide whether the public summary is appropriate.
Choose the record people should keep using
A good merge keeps the source connected to a canonical destination. Existing links should still explain where the request went. Deleting the source without a reference makes older discussions and customer bookmarks harder to understand.
- Choose a destination that describes the shared outcome clearly. The oldest card is not automatically the best summary.
- Improve the destination’s public summary without copying private source material.
- Compare support and status. Do not merge a new request into a shipped card if the delivered feature does not actually solve it.
- Confirm the merge only after checking its effects. BuildCaster does not offer an undo action for a completed merge.
Do not turn duplicate evidence into extra support
If the same participant voted on both cards, the destination should count that person once. Keep historical imported support separate from verified participant votes; a legacy count is not proof of a current identity.
Following is a notification preference, not just another number to add. Preserve opt-outs. A merge should not enroll someone in email they declined, and the act of merging is not a release announcement.
BuildCaster combines eligible follows without sending mail. Review the resulting card and its history after the operation, especially when one card had different notification preferences or moderation state.
Close the review with a clear record
Once merged, revisit the canonical title, summary, and current decision. A well-maintained card should explain the combined problem without becoming a paste of every incoming message.
If the request is still undecided, leave it in Considering. If the team decides to pursue it, record that decision through the roadmap workflow. Combining votes does not itself commit work.
Run this check during regular feature request review, not only when the board becomes crowded. Smaller, deliberate merges are easier to reason about than a cleanup of dozens of ambiguous cards.