Why does Salesforce maintain separate Button and Action frameworks when their behavior/UI can overlap? For example, why is Account Edit a Standard Button despite performing a record-level operation similar to a Quick Action?

Hey Renuka, 

A record page's actions are a combination of Quick Actions, standard buttons (Edit, Delete, Clone), Chatter actions, and productivity actions, all rendered together in the page-level action menu, but they trace back to different generations of the platform. 

Standard buttons like Edit predate Quick Actions entirely, they're core CRUD operations baked into Salesforce since Classic, tied directly to page layouts and standard controllers. Quick Actions came later (Lightning-era) as a more flexible, declarative framework built for things standard buttons couldn't do well: creating related records, logging calls, launching Flows/LWCs, all without needing a full page navigation. 

Salesforce never migrated Edit/Delete/Clone into the Quick Action framework because they're fundamental object-level behaviors tied to page layout metadata and permissions, not something layered on top. Rebuilding them as Quick Actions would be redundant and risk breaking backward compatibility across every existing org. 

So the short answer: it's not that they overlap by design, it's that Standard Buttons are older, layout-level plumbing, and Quick Actions are a newer, more flexible layer built alongside them, not a replacement for them. 

Reference: