Guide to required fields on duplicate

What are required fields on duplicate?

When a participant encounters an issue that's already been reported, they add their voice instead of re-submitting. They either accept a predictive match suggestion during submission or vote on the existing feedback item.

Required fields on duplicate collects form data from those participants too. You choose specific form elements that every matching or voting participant fills out before their occurrence is recorded. Each occurrence then carries real per-participant context: when it happened, on what device, on which build. That's far more useful than a bare +1 to a counter.

Common use cases

• Ask "What time did this happen?" or "Which build are you running?" of every participant who encounters an issue, not just the first one to report it
• Compare environment details (device, OS, configuration) across all occurrences of an issue to spot patterns
• Prioritize with confidence, backed by per-participant data rather than an occurrence count alone

Enabling required fields on duplicate

The setting lives on individual form elements within a feedback type. This means you control exactly which fields participants fill in when they match or vote.

1. Click Management > Project configuration > Feedback types
2. Click the desired feedback type to modify the feedback form
3. Hover over and click Modify on the element you want to collect from every occurrence
4. Check Required on duplicate
5. Click Submit

Repeat for each element you want collected. The option appears only on element types that take participant input. File uploads and AI-generated elements, for example, aren't eligible.

What participants experience

When a participant accepts a predictive match suggestion ("This is a match") or votes on an existing feedback item, a focused window appears. It contains only the required-on-duplicate fields. Normal form behavior carries through: required indicators, default values, and selection limits all work as they do on the full form. Fields with default values come pre-filled.

The participant fills in the fields and submits. The platform records their occurrence as a duplicate of the original feedback, with those values attached.

If the participant cancels instead, no occurrence is recorded. They stay where they were and can vote again later. This is intentional: when you enable this setting, you're saying the context matters, so an occurrence isn't counted without it.

This works the same way across all submission flows, with AI Feedback Submit on or off.

Finding and using the collected data

Occurrence data flows into the duplicate feedback tools you already use:

On the feedback item: Open the original feedback item and click the details icon at the top. Each occurrence is listed there. The comparison view shows every participant's submitted field values side by side with the original submission. 

In feedback views and filters: Add the collected element(s) to a saved View in Feedback Management. For example, if you require a "Build version" field on duplicate, a View including that field lets you scan versions across everything that's been reported and voted on.

Best practices for choosing required fields

• Keep it light: Two or three fields is the sweet spot. Every field you require adds friction to what was a one-click vote.
• Pick objective, fast-to-answer fields: Time of occurrence, build number, device model. Skip long-text fields. You already have the description from the original submission.
• Use default values where they make sense: Defaults pre-fill in the participant's window, so a date/time field with a default costs them nothing.
• Consider your conditionals: A conditional child element can only be flagged if its conditional parent is also flagged. 

Notes

• Occurrences recorded before you enable this setting show blank values for the required-on-duplicate fields in the comparison view.
• A vote records a single occurrence per feedback item. Participants can't undo votes made through this flow.
• A participant who encounters the same issue again with different context can match to the same original feedback item more than once via submission.
• Removing a duplicate relationship doesn't delete the field data the participant submitted.
• New data associated with duplicate occurrences triggers an update to external destinations (such as Jira) like new submissions. This may overwrite the content of existing external tickets or create a new ticket using the newly captured data. [In Development: Slack integration behavior and workflow notification behavior for duplicate occurrences were still being finalized during GoEarly]
• Cloning a project carries these settings over. Cloned feedback respects the destination type's settings.
• Looking for how duplicates work in general? See the Guide to predictive match and the Feedback FAQ.