New/Edit Lightning Action Overrides should behave like native new/edit actions - Ideas - Salesforce Trailblazer Community
Trailblazer Community

All Ideas

Idea Details

Post an Idea
4,540  Points
Idea has been posted. Give it an upvote or downvote.

New/Edit Lightning Action Overrides should behave like native new/edit actions

Customization & App Building

In the developer documentaton for lightning:actionOverride, it states:
In Lightning Experience, the standard Tab and View actions display as a page, while the standard New and Edit actions display in an overlaid panel. When used as action overrides, Lightning components that implement the lightning:actionOverride interface replace the standard behavior completely. However, overridden actions always display as a page, not as a panel. Your component displays without controls, except for the main Lightning Experience navigation bar. Your component is expected to provide a complete user interface for the action, including navigation or actions beyond the navigation bar.

The native new/edit actions appear in a modal, so having the Lightning override take over the full page means that the end user gets a different experience. This is inconsistent UX; the underlying technology should not change the behaviour of the interaction.

With Lightning quick actions, the quick action appears in the modal exactly like other actions. Please make New and Edit override actions behave the same way, so users continue to get a consistent experience in Lightning.

Merge Idea · Flag

Latest Comment from Salesforce

  • Xander Mitman - 1 year ago

    Some of the reason for the "interesting" UX was due to various platform constraints at the time we shipped support for Visualforce overrides in Lightning Console in Winter '19.

    Since then we've made various improvements that do open up more options - but now we have change management to consider.

    I'd say three general priorities/constraints of the platform are:

    a) The underlying technology should *ideally* be decoupled (or at least decouple-able) from the user experience
    b) The out-of-the-box/standard UX should not change from one release to the next unless there is a VERY good reason and/or thoughtful change management process (e.g. opt-in via a CRUC)
    c) Different customers have different thresholds, opinions, and productivity estimates on different UX scenarios and therefore enabling configuration by the customer is valuable.

    TBD if/when/how we will tackle this idea but it has been a discussion point among various PMs here on the Lightning Platform team. Please keep the feedback coming!

    Xander Mitman
    Director, Product Management | Navigation Experience
  • Upvotes
  • Downvotes



from AppExchange


No results found.

Help us to keep IdeaExchange clean by pointing out overlapping ideas. We'll investigate your suggestion and merge the ideas if it makes sense.



Thanks for your merge suggestion. We will review it shortly and merge the ideas if applicable.

Salesforce takes abuse situations very seriously. Examples of abuse include but are not limited to posting of offensive language or fraudulent statements. To help us process your request as quickly as possible, please fill out the form below describing the situation. For privacy and security reasons, the final outcome of an abuse case may not be revealed to the person who reported it.


Thank you for your feedback. We take abuse seriously and will investigate this issue and take appropriate action.