Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Briefly: a standard quick action is a fast, layout-driven way to create or update one record with no logic, and it is the better choice whenever that is all you need. A screen flow gives you multiple steps, branching, queries and calculations, at the cost of building the form and its validation yourself. The practical difference users notice is navigation: a quick action puts a compact modal over the page they were on, and where a flow appears depends entirely on how you surfaced it.

What a standard quick action gives you

Create a Create Record action on an object and you get a modal with fields you chose in an action layout. For free, you also get:

  • Record type selection and field defaults applied the way they are everywhere else.
  • Validation rules, required fields and field-level security enforced by the platform.
  • Predefined field values, including values taken from the record you launched it from.
  • A working mobile experience, because actions appear in the mobile action bar.
  • A layout an admin can change in a minute without opening Flow Builder.

Rebuilding that list in a screen flow is a day of work and it will not be as good. If the requirement is “let people log a related Case from the Account page with the account prefilled”, the standard action is the answer and a flow is over-engineering.

What a screen flow gives you

The moment the requirement contains the word “then” or “if”, a quick action runs out. A flow handles:

  • More than one screen, with a Previous button and conditional paths between them.
  • Touching more than one object in one interaction.
  • Querying and showing related data before the user commits to anything.
  • Calculations, callouts, Apex actions, and anything else the element palette offers.
  • Showing the user a confirmation of what happened.

The trade is that a flow’s Create Records element writes the record directly. Validation rules still fire, which surfaces as a fault rather than as a friendly field error unless you add a fault path and your own message. Required fields are a screen component property you set by hand. Record type defaults are yours to apply.

The navigation difference

This is the part that decides the design more often than the logic does.

A quick action opens a modal over the current page. The page stays where it was, the modal has its own Cancel, and when the action completes the modal closes and the record page refreshes. Context is never lost.

A screen flow surfaced as a Flow quick action behaves the same way, and this is the option people forget exists. Create a quick action of type Flow, point it at your screen flow, add it to the page layout, and the flow’s screens render inside the action modal with the record’s Id passed in automatically when the flow has a variable named recordId. You get flow logic with quick action framing.

A screen flow on a Lightning record page as a Flow component renders inline in a region of the page. It is always visible, it has no modal to cancel out of, and it competes for space with everything else on the page. Good for a persistent guided panel, poor for an occasional task.

A screen flow from a URL, a tab, or an app page takes the user away from where they were. Fine for a standalone process someone starts deliberately, wrong for something they do in the middle of reading a record.

Choosing

  • One record, no logic, fields on a form: standard quick action.
  • One record but with defaults computed from other data: flow, surfaced as a Flow quick action.
  • Several records, several steps, or a decision in the middle: flow.
  • Something the user should see on every visit to the record: flow component on the page.
  • A process not tied to one record: flow on a tab or from the App Launcher.

Do not build a screen flow that recreates a create-record form because you might need logic later. You can replace the action with a Flow action on the same layout position when that day arrives.

Frequently asked

Does a flow quick action get the record Id automatically? Yes, if the flow has a text input variable named recordId marked as available for input. The name matters.

Can a flow close its own modal? Reaching the end of the flow closes it and refreshes the page. To end early, route to an end element rather than trying to navigate away.

Do quick actions work in mobile? Standard actions and flow actions both appear in the mobile action bar. Test screen flows on a phone, because a screen designed at desktop width is often unusable there.