Summer's here, and so is a release we've been looking forward to. The headliner is Required on Duplicate, graduating to live servers after its run on GoEarly. Duplicates used to be a mechanism for exclusively adding weight to existing feedback. Now they can carry real context forward into your views, reporting, and exports. Over on GoEarly, we're previewing Centralized Jira Integration, which lets you set up your Jira connections once at the community level and share them across projects. Before we get into the features, though, here's a change behind the scenes that we're genuinely excited about.
An exciting change in how we ship
We've changed how we build and deliver Centercode behind the scenes, and it's a change we're excited about, because you're the one who benefits. What it means for you: we can get new capabilities into your hands sooner, react faster when you need something adjusted, and roll out improvements without interrupting your work. It's the kind of thing you'll feel more and more as we go.
β¨ New Features β¨
Required on Duplicate
When a participant runs into something another participant already reported, they have two quick ways to say "me too": voting on an existing issue, or matching a predictive suggestion as they submit. Both paths used to do the same thing behind the scenes. They added one to a counter. You knew more people hit the issue, but not what was different about each encounter: their device, their build, the time it happened, the steps that led there.
Required on Duplicate closes that gap. You can now flag specific form elements as required on duplicate, so that when a participant claims an existing issue, they're prompted to fill in just those fields before the duplicate is recorded. A focused popup appears with only the fields you've marked, nothing else, so it stays quick for the participant while capturing what your team actually needs to triage.
That captured context travels with the duplicate. Each "me too" now creates a real duplicate submission, linked to the original, with the participant's data attached. From there it flows into your comparison view, reporting, and exports, the same as any other feedback. You're triaging from what people actually reported, not from a count and a guess.
Setting it up is per element and entirely up to you. Inside a feedback type, open the form element you want to collect on a duplicate and turn on required on duplicate. Good candidates are short, high-signal fields like time, device, build, and steps to reproduce. Eligible field types include text inputs, date and time pickers, single and multi-select drop-downs, and rating elements. File uploads, AI-enhanced fields, and read-only elements stay out of the duplicate flow to keep the popup fast. If a participant cancels the popup, no duplicate is recorded, so only complete submissions count.
A few things worth knowing. Duplicates collected before you turned the setting on will show blanks for those fields, since the data wasn't requested at the time. The same participant can log more than one occurrence on the same issue, which is intentional. And if you ever remove a duplicate relationship, the context you collected stays put. Read more here!
π‘ GoEarly Features π‘
Centralized Jira Integration
If you run Jira integrations across more than a couple of projects, you know the drill. Every project, every feedback type, the same credentials maintained by hand. When an access token expires, you go update them one at a time, and there's no single place to see which projects share a connection or whether a key still has access.
Centralized Jira Integration, now previewing on GoEarly, lets you manage your Jira connections once at the community level instead of project by project. Set up a connection a single time, with its name, base URL, authentication type, and credentials, and share it everywhere it's needed. Each connection shows which projects rely on it and when it was last edited, so you finally have a clear picture of what's connected to what.
Project-level destinations gain a connection-source choice. Point a destination at a shared community connection, or keep using project-specific credentials exactly as you do today. Nothing about your existing setups changes unless you decide to move them, and your credentials are preserved through every step: switching to a shared connection, having one removed, and recovering.
Our favorite part is the built-in Test action. It checks a connection and shows you which Jira projects it can actually reach, which catches the most common snag we see in support: a key that connects just fine but quietly lacks access to the project you're aiming at. Instead of guessing, you get a straight answer.
Want a first look? Sign up for GoEarly now!
A completed phase can now be reopened with one action. The new reopen control on closed phases flips the phase's status back to active and reactivates its surveys and activities, so participants can submit data again. Every submission, response, and attachment from the prior window stays intact. The reopened phase resumes its identity rather than starting over. If you've ever spun up new artifacts to run a follow-up round (and lost the historical thread doing it), this one's for you.
Date edits on past phases let you fix what was wrong without rewriting history. Deactivated phases now show the same date-edit controls as active and pending ones. Correcting a typo, retroactively labeling a phase to match what really happened, or aligning a phase to an external timeline is now a self-service edit. Changing a deactivated phase's dates doesn't reactivate it. The phase stays deactivated unless you also choose to reopen it.
Single-day phases finally just work. Set the start date to match the end date, and the platform accepts it cleanly. The timeline view renders the phase visibly rather than as a zero-width sliver, so single-day events stay recognizable next to multi-day ones. Useful for one-day kickoffs, focused field tests, or pinpoint survey distributions that didn't quite belong in a longer window.
Becomes:
---
---



