Salesforce Just Delivered 5 Long-Awaited IdeaExchange Features

The Salesforce IdeaExchange has been around since 2006, which means some ideas have had plenty of time to become very, very patient. For years, the process was simple: post an idea, gather votes, wait for Salesforce to respond, and hope it eventually made its way into a release. Sometimes that meant a few releases, sometimes several years, and occasionally forever.

That does seem to be changing. Salesforce is putting more focus on Idea Insights, tracking ideas that have shipped, are trending, or have recently received product team updates. In its latest email to the IdeaExchange community, Salesforce highlighted several long-requested ideas that have now been delivered, including some genuinely useful improvements for admins. Here are five worth knowing about.

1. Flow Quick Actions in List Views

• Idea Posted: April, 2019
• Points: 6100
• Delivered: Winter ‘27
• Wait: 7.5 years

Let’s start with the big one. Mass quick actions arrived in Lightning list views back in Spring ’18, but they came with a rather significant limitation: only Create a Record and Update a Record actions were supported.

That meant that if you wanted users to select several records and run them through a screen flow, you needed to get creative. A custom Lightning web component, a Visualforce workaround, or an AppExchange package could all get you there, but none of them were exactly the straightforward admin-friendly solution you probably wanted.

The IdeaExchange request asked for exactly that missing piece: the ability to use Flow-based quick actions as mass actions.

The Flow team eventually picked it up, and it has now arrived in Winter ’27 as Process Multiple Records with Screen Flows from List Views and Related Lists.

Here’s how it works:

• Build the flow: Create a screen flow with a text collection variable called ids (lowercase) and make it available for input. Salesforce will pass the IDs of the records selected by the user into the flow.
• Create the action: On the relevant object, go to Buttons, Links, and Actions and create a new action with the Action Type set to Flow.
• Add it to the list view: Add the action to the object’s List View Button Layout under List View Actions in Lightning Experience.
• Or add it to a related list: Add the same type of action to a Dynamic Related List – Single component in Lightning App Builder.

The interesting part here isn’t just that you can now run a flow against multiple records. It’s that you’re no longer limited to making exactly the same change to every record.

Think bulk reassignment where users need to make decisions about each record, end-of-day opportunity updates where users need to add notes, or any process where a screen flow makes more sense than blindly stamping the same value across a pile of records.

As always, remember that this is Lightning-only, and the usual considerations around screen flows, downstream automation, and governor limits still apply.

2. Share List Views Without Manage Public List Views

• Idea posted: January, 2019
• Points: 35,160
• Delivered: Summer ‘26
• Wait: 7.5 years

If you’ve ever had to decide whether giving a sales manager the ability to share a list view with their team is worth giving them access to every public list view in the org, this one should make you happy.

Previously, sharing a list view required the Manage Public List Views permission. The problem is that this permission is a fairly hefty one. It doesn’t just let someone share their own list views. It lets them create, edit, and change the sharing of public list views across Salesforce.

As we’ve written before, that can be a bit like handing someone the keys to the filing cabinet because they needed to borrow a stapler.

Summer ’26 introduced a much more targeted Manage Shared List Views user permission. This lets users share their own personal list views with roles, groups, and territories they belong to, without giving them the ability to manage every public list view in the org.

There are a few things to know:

• It applies to Lightning Experience in all editions and can be assigned through a permission set or profile.
• Users with the permission can also edit and delete list views that have been shared with them.
• If you want users without the permission to edit list views shared with them, such as changing filters or the name, there is a separate Shared list view editing option in User Interface Settings.

For admins, this is a nice opportunity to tidy up permissions. If you currently have people holding Manage Public List Views purely because they need to share list views with their team, it’s worth checking whether they can now be moved to the narrower permission instead.

3. Inline Editing on List Views With Multiple Record Types

• Idea posted: August, 2011
• Points: 10,640
• Delivered: Winter ‘27
• Wait: 15 years, 2 months

This is one of those Salesforce limitations that you’ve probably had to explain to a user at least once. They open a list view, hover over a field, and look for the little pencil icon. Nothing. The reason? The list view contains more than one record type.

Salesforce has required users to filter down to a single record type before they could inline edit, which is particularly unhelpful in orgs where Accounts, Cases, or Opportunities are split across several record types.

And this isn’t a new annoyance. The single-record-type workaround was being documented back in 2012.

Winter ’27 finally removes the restriction with a new User Interface Settings option: Make inline edits in list views with multiple record types.

Once enabled, users can inline edit records across multiple record types without having to create a separate list view for each one. Winter ’27 also adds another option allowing users to inline edit fields that aren’t on the page layout. There are a few caveats in the considerations:

• The setting is off by default, so nothing changes until an admin enables it.
• Person Accounts are still a little awkward. The list view must either contain only Person Accounts or exclude them entirely.
• Inline editing still isn’t supported in split view.

Because this is an org-wide setting, I’d test it in a sandbox before switching it on in production. Picklist values, validation rules, and required fields can differ between record types, so editing a mixed list could expose users to errors they weren’t previously encountering.

4. Field History Tracking for Users

• Idea posted: March, 2008
• Points: 39,240
• Delivered: Winter ‘27
• Wait: 18 years, 7 months

This one appears under “Recently updated” in Salesforce’s IdeaExchange email rather than “Recently delivered”, but don’t let that put you off. It is generally available in Winter ’27, and given how long admins have been asking for it, it absolutely deserves a place here.

The User object has always been a bit of a blind spot. You could track field history on Accounts, Cases, and custom objects, but if someone’s profile, role, or manager changed, you often ended up digging through the Setup Audit Trail or building your own automation to keep a record of what happened.

That isn’t particularly helpful when you’re trying to answer a simple question such as: Who changed this user’s access, and when?

Winter ’27 lets you track up to 20 fields on the User object, including old and new values, timestamps, and who made the change. It’s also auto-enabled. To set it up, go to Object Manager, open the User object, select Set History Tracking, and choose the fields you want to monitor, just as you would for other objects. As with other objects, history is retained for up to 18 months in the UI.

If your org has audit or access-review requirements, this is worth setting up before you need it. Profile, role, manager, and active status would be sensible places to start, but the right fields will depend on what you actually need to keep an eye on.

5. Restart Your Superbadge Progress

• Idea posted: July, 2019
• Points: 8,070
• Delivered: Summer ‘26
• Wait: 7 years

This one is less about your Salesforce org and more about your own Salesforce learning journey, but it’s going to be useful for plenty of Trailblazers.

If you’ve ever started a superbadge, got halfway through, realised your Trailhead Playground was now a complete disaster, and wished you could just start again, you’ve probably encountered this particular frustration. There have been Trailhead Community threads asking how to restart superbadges for years.

The redesigned superbadge experience now addresses this. Salesforce’s Superbadge Overview confirms that you can take a superbadge again after completing it, whether you’re reinforcing your skills, trying a different approach, or simply revisiting a topic.

This is probably the least exciting feature on this list from an admin perspective, but I actually like the change. Salesforce is increasingly positioning superbadges as practical, hands-on exercises rather than credentials you complete once and never touch again. Being able to repeat them makes much more sense if the goal is genuinely to practise a skill.

What Else Is on the Move?

The five features above aren’t the only IdeaExchange requests getting attention.

Salesforce’s latest email also highlighted several long-standing ideas that have recently received updates from product teams. An update obviously isn’t the same thing as a delivery date, so I wouldn’t start planning your next sprint around these just yet, but they’re worth keeping an eye on if they affect your org:

• Expand “Where is this used?” to standard fields: The button currently works for custom fields, but standard fields are excluded, which makes impact analysis and org clean-up more difficult than it needs to be. 
• Lightning Night Mode: Dark mode has been one of the most requested UX ideas for years. Dark Mode is now available in beta across all editions on SLDS 2.
• Restriction Rules for the Opportunity object: Potentially a big one for sales orgs that need to restrict access to particular opportunities without completely reworking their sharing model. This is officially on the roadmap, and you can catch up with the news on Salesforce+ from TDX ’26. 
• Increase the row-level formula limit in reports: Previously, report builders were limited to one row-level formula per report, despite this being a long-standing request. From Summer ‘26, the limit has increased to two row-level formulas.