Permanently approve a trusted account
Sign-in security checks exist to keep bad actors out. Every so often they flag someone who's perfectly legitimate, and until now the only fix was a password reset. That unlocked the account right up until the next sign-in locked it again. Not a great loop.
Administrators with the Moderate Users community role can now permanently approve an account from the user's summary page. Once approved, that person won't be locked out or signed out because a sign-in looked suspicious. If they're already locked for suspicious activity, approving them clears the lock on the spot. No password reset needed.
- Open the community user summary for the person you want to approve.
- In the User account actions menu, click Permanently approve this account.
- Read the confirmation message, then click Approve.
- Check that the Sign-in risk detail now reads "Approved by [your name] on [today's date]." 🎉
Approval switches off exactly one thing. Every sign-in is still checked and recorded, so you keep full visibility into sign-in activity. Too many wrong passwords will still lock the account, and approving won't clear that kind of lock.
To help you tell the two apart, the user summary now names the cause of a lock. A suspicious-activity lock reads Account locked due to suspicious activity, and failed-password locks look the same as before. The sign-in message changed too. Someone locked for suspicious activity now gets a message asking them to contact support, instead of being told they made too many sign-in attempts.
Important note: Approval is permanent and can't be removed from the user summary. Treat it as a deliberate decision, not a toggle.
Product Versions & Releases
Publishing releases in big communities works again
What we fixed: In larger communities, the ones with lots of team members and a long history of content views, the Version/Release Preview page could fail with an error. Sometimes the page never loaded at all. When it did load, clicking Publish or Publish and Notify could still fail, so the release never went out. We tracked it down, and the Preview page now loads reliably and publishing finishes, no matter how big your community has grown.
See it in action:
- Head to Product Versions in your project's admin area, then open an existing Version or create a new one and fill in the required fields.
- Click Preview. The page should load without complaint, even in your busiest community.
- Click Publish or Publish and Notify and watch your release go live. No more error pages standing between your participants and the new build. 🎉
Good to know: Nothing about the release itself caused this. It depended entirely on the size and history of the community, which is why smaller communities probably never saw it. If you'd been retrying publishes over and over, you can go ahead normally now.
See it in action:
One catch worth knowing: it has to be a single send to that one person. The bulk email button at the bottom of the pool, the one that goes to everyone matching your filter, does not restart anyone's allowance, because it doesn't record who it reached individually. Sending from the pool never uses up a candidate's own allowance either, so you can send as freely as you like. It can only help them.
The Project Home has always rendered its sections in a fixed sequence we chose. That worked fine until it didn't. A hardware program that ships units wants Activities up top to drive completion. A research team wants Feedback first, because collecting it is the whole point. A project that briefs participants before anything else wants Content leading. One order was never going to serve all three.
One saved order applies to everyone in the project, and the same order drives desktop and mobile. Each participant still sees only the sections they're entitled to, arranged the way you set them. Sections with nothing in them keep hiding themselves exactly as they do today, and they hold their configured position for whenever they do have content. You'll never end up with an empty placeholder just because you moved something.
Product Verification isn't one of the reorderable sections. It's pinned, and as of this release it's pinned to the top of Project Home rather than sitting below Feedback. If your project uses Product Verification, this is the one thing that looks different on release day without anyone touching a setting. If your project doesn't use it, nothing moves.
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.