Notifications
Format the custom message in notification emails
What's new: When you announce or remind people about a survey, task, content item, or release, or notify users after changing a phase's dates, the Use custom message box used to be plain text. Even your line breaks got lost, so a three-paragraph note arrived as one block. Now it's a simple formatting editor, and your note arrives looking the way you wrote it.
See it in action:
- From your Surveys, Tasks, Content, or Releases list, use the Notify users action on an item (or edit a phase, change a date, and tick Notify users).
- Choose Use custom message. You'll see a formatting toolbar with bold, italic, strikethrough, numbered and bulleted lists, left, center, and right alignment, and links.
- Write your note, add some formatting, and send. Recipients see it with your formatting and line breaks intact, centered by default inside the standard email layout. Fancy! 🎉
Good to know:
- This needs System Email Customization. Communities without it don't get the custom message option, same as before.
- Dynamic tags aren't available in these notes. Anything typed in tag format is sent as plain text.
- A note that's empty, or only spaces or blank lines, is rejected with the usual "custom message required" error.
- Quick Invite, external user source invitations, and the admin password reset email still use a plain text box.
- The standard email template editor gets a small facelift too: its bottom corners are now rounded, and links keep their email blue when you hover over them.
Onboarding/Recruiting
Your project name shows up right in invitation emails
What we fixed: If your project or community name had a special character in it, like a "+", "&", or an apostrophe, invitation emails showed a jumble of code in the sender name instead. So "Acme+ Beta" arrived as Acme+ Beta, which looked a little like spam. The subject line and the email itself were fine, so only the From line gave it away. We fixed the sender name so it shows your name exactly as you typed it, matching everything else in the email. Accented letters (like "Café") are fixed too!
See it in action:
- Open a project whose name includes a +, &, or ' (or rename one under Project settings).
- Click Invite to project, add an email address, choose a team, and open Preview invitation. Hover the help icon next to "Users will receive this email" to see the From line just as you typed it.
- Send the invitation, then check the inbox. The sender name reads exactly like your project name. No more mystery codes! 🎉
Good to know: This covers Quick Invite at both the project and community level, plus recruitment and referral invitations whose email template doesn't set its own sender name. Any invitations already queued before the update keep their old sender name.
User Interface & Experience
Landing page titles are readable on phones again
What we fixed: On a phone, communities whose theme uses light text for outer pages had a white-on-white problem. The page title on landing pages, and the "Interested in participating?" heading above open opportunities, basically disappeared. We switched those headings to a dark text color on mobile, so they're easy to read whatever the theme. While we were there, we tidied up the section dividers too: one clean, even line between sections instead of doubled or uneven ones.
See it in action:
- On your phone, sign out (or open a private window) and visit your community's welcome page.
- Check the page title and, if you have open opportunities, the "Interested in participating?" heading. Both are crisp and readable.
- Open an opportunity's landing page from a key link. Same readable title, same tidy dividers. Much better on the eyes! 🎉
Good to know: This is a mobile-only change. On desktop, both headings still use your theme's outer page text color. If a landing page uses its own Custom CSS to recolor these two headings, that styling may no longer take effect on mobile.
See it in action:
Report elements take real work to get right. You pick the data, build the filter, choose the style, and maybe write an AI prompt worth keeping. Once you've done all that, you shouldn't have to do it twice. Report element cloning gives you two ways to reuse what you've already built.
Duplicate in place. Want a few variations of the same chart in one report? Hover any element on the Modify this report page and click the clone control next to remove. A copy drops in directly below the original, and everything beneath it moves down one spot. The copy keeps the original's name exactly. We didn't add "(2)" or "Copy of" to the name, because those labels pile up fast once you've made a few copies. Rename it whatever makes sense.
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.