A Settings fix, explained to the people who use it.
On 9 September 2026, we fixed jumping Settings tabs and improved Members & roles. Here is how those changes can become a short announcement your users understand.
These are editorial examples written from our shipped Settings release. They demonstrate the result to aim for; they are not an unedited AI output or a customer testimonial.
The release fixes page movement when changing Settings sections and makes team controls easier to read and use.
Customer announcementWorkspace owners and admins
Settings now stays in place
Switch between Settings sections without the page jumping down. Members & roles also has a clearer layout, with role descriptions beside each choice and menus you can navigate using your keyboard. Open Settings to see the changes next time you manage your workspace.
Open Settings
Internal briefSupport and product
Settings navigation and team controls updated
The Settings tab-jump fix is live. Members & roles now uses aligned cards and custom workspace and role menus. The role menu explains Viewer, Member and Approver access. The deployment was checked in a signed-in session: switching Destinations and Email sender kept the page heading in place, and keyboard role selection worked. When helping a user, ask them to reload an already-open Settings page first.
FROM IMPLEMENTATION TO USER BENEFIT
What the source actually supports
Shipped change
Implementation fact
What the user needs to know
Section navigation
Tab clicks update the selected section and URL without native anchor scrolling.
The page stays in place when you switch Settings sections.
Role selection
The custom role menu includes a description for each role and keyboard controls.
Read what each role can do before choosing it.
Team layout
Member and invitation cards share a responsive content column with consistent spacing.
Find members, roles and pending invitations in an aligned layout.
A code change alone does not prove availability. The release behind this example was deployed and checked before the customer wording described it as live.
THE EDITORIAL DECISIONS
Why the announcement is short
01
Lead with the interrupted task
The original problem was losing your place while managing Settings. Starting with that experience helps an existing user recognize the fix immediately. The implementation details remain available as evidence rather than becoming the headline.
02
Explain the role menu at the point of choice
The useful improvement is seeing what a role allows before selecting it. Naming the menu technology adds little for a workspace owner. Keyboard support is worth mentioning because it changes how someone can operate the control.
03
Give the reader one next step
Opening Settings is enough for this release. There is no migration to schedule or new integration to install. A separate sales pitch would distract an existing user from the improvement they can already use.
What this example does not claim
It does not claim a measured reduction in support tickets, editing time or customer churn. We have not established those outcomes for this release.
It does not describe new role permissions or invitation delivery behavior. This release changed the interface, not who is entitled to access a workspace.
It is not a receipt for an email sent to customers. These messages are published here as examples; choosing an audience and approving customer publication are separate actions.
Try this with your own change
What should I choose for my first Update?
Start with a merged feature or fix that changes something your users can do. A dependency update may be important engineering work but offer little to announce. You choose the change before generating your first draft.
Do I need to connect email or Slack first?
You can begin with GitHub and review a release-note draft before setting up a publishing channel. Customer emails and channel delivery need the corresponding destination configuration; this example does not bypass that setup.
Can I change the wording before customers see it?
Yes. Review the facts, edit the draft and approve the customer-facing version before publishing. Internal communication follows the policy configured in your workspace. A draft is a starting point for your judgment.