Form Engine & Custom Surveys
Completed surveys now show the answer you actually picked
What we fixed: On the review screen for a completed survey, a Choices question set to the vertical radio button style could show the first option as the selected answer, no matter which one was picked. The trigger was oddly specific: it only happened when one of the answer choices had the word "checked" somewhere in its text, like "They matched all the times that I checked today." The review screen was working out which option was selected by scanning for that word, so a choice containing it matched itself and won every time. We've rebuilt how the review screen decides, so it reads the answer that was actually stored.
See it in action:
- Open a survey with a Choices question using the vertical radio button response style, where at least one choice has the word "checked" in its text.
- Take the survey and select any option other than the first one.
- Submit the survey, then view the completed survey review screen.
- The option you selected is the one looking back at you. π
Good to know: This only ever affected how the review screen displayed the answer. The Data Engine, reporting, and the response edit view had the correct answer the whole time, so nothing you've already collected needs a second look. Horizontal radio buttons had the same quirk, and they're fixed too.
Conditional questions now stay hidden until the matrix question is answered
What we fixed: When a matrix question included N/A as one of its answer choices, any conditional question tied to that row would show up immediately, before anyone had answered a thing. The row looked untouched, but the conditional logic was reading that untouched row as an N/A selection and firing on page load. We've taught it the difference between a row nobody has answered yet and a real, deliberate N/A.
See it in action:
- Build a matrix question that includes N/A among its answer choices, such as a 1-5 scale plus N/A.
- Add a conditional question triggered by N/A on a specific matrix row.
- Preview or take the survey and leave the matrix question unanswered. The conditional stays out of sight where it belongs.
- Select N/A on that row and the follow-up appears right on cue. Pick a real score instead and it tucks itself away again. π
Good to know: Reopening a submission that was saved with N/A still shows the conditional on load, which is exactly what should happen: that N/A is a genuine answer. Conditionals on standard choice questions, drop-down lists, and checkboxes all behave the way they always have.
Each connection stores an instance name, a base URL, an authentication scheme (basic with a username and API token, or bearer with a personal access token), and the credentials themselves, encrypted at rest. You can set up as many instances as you need, so an engineering Jira and a support Jira can happily coexist.
Every connection card has a Test button. Select it and we call Jira, then show you the list of Jira projects those credentials can actually reach, 30 at a time. It's a quick confirmation rather than a project browser, and it catches the situation that generates the most support tickets today: a token that authenticates perfectly well but lacks the access the sync needs downstream. A successful test shows a green Connected badge. A failure shows a red Connection unsuccessful with the reason in plain language, like Token expired or Could not reach Jira at this URL. Save credentials without testing them and the card sits at Untested until you do.
In a project, the authentication fields on the Jira external destination are replaced by a Connection source drop-down. It lists your community's connections alphabetically, with Project-specific connection at the bottom. Choose a community connection and the instance details display read-only, so you go straight to the JSON mapping without hunting down a token. For a one-off integration, like a contractor's Jira account, choose Project-specific connection and enter the base URL, authentication scheme, and credentials the way you do today.
Switching between the two is safe in both directions. When you move a project from its own credentials to a community connection, the original credentials stay put behind the scenes, obfuscated. If that community connection later disappears, flip back to Project-specific connection and everything you entered is still there waiting.
The old inline drop-down for inserting dynamic tags into the JSON editor is retired. The dynamic tag button now opens the same search modal you already use elsewhere in the platform. Park your cursor in the JSON, open the modal, add the tags you need, close it, then move them where they belong.
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.
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:
---
---



