Override New, Don't Add a Custom Create Case Button

How to route Case record types through one entry point without breaking standard UX.

You've got ten Case record types. A few need multi-screen wizards that collect context, apply business rules, and route to the right queue at creation. The rest are fine with the standard creation page. And someone suggests: "Let's add a custom 'Create Case' button that launches a flow."

Problem: adding a second custom button creates competing entry points, user errors, and avoidable training/support overhead.

Now you have two doors to the same room.

Users see the standard "New" button on the Cases tab, on related lists, in global actions, everywhere Salesforce puts it. And they see your custom button... somewhere else. Which one do they click? What happens if they pick the wrong one? Who maintains the training doc that explains the difference?

Two Doors Is a UX Problem

Override the door that already exists

The better pattern: override the standard "New" button so every entry point runs through a single router. Same button, same placement, same muscle memory. The behaviour behind it just gets smarter.

Here's the shape of it:

Standard "New" button (overridden)
  -> Aura wrapper (passes context - Account ID, origin, etc.)
    -> Router Screen Flow
      -> Apex action: get accessible record types for running user
      -> Screen: pick a record type
      -> Decision:
          Guided types -> subflows (per record type)
          Default      -> standard creation page + navigate

The Aura wrapper exists because you can't override a standard button with a flow directly, you need the thin Lightning component layer to capture context and launch the flow. It's boilerplate. A few lines that never change.

The router flow is where the logic lives, and it's readable. An admin can open it, see the Decision element, and understand the full branching picture in thirty seconds.

Why this pattern holds up

One button, everywhere. The override applies to every surface where the standard "New" appears - Cases tab, Account's related list, global actions, quick actions. You don't chase button placements across page layouts.

Guided where needed, standard where not. Record types that need intake logic get subflows with screens, field defaults, queue assignment, validation. Record types that don't need any of that fall through to the standard creation page. No flow overhead for simple types.

The Apex action respects profiles. By querying which record types the running user can actually access, you never show options a user can't use. The record type picker screen only displays what's relevant. This is something the standard record type selector already does - you're just preserving that behavior inside your flow.

Adding a new standard record type costs nothing. If someone creates a new record type that needs no guided flow, it falls into the default branch automatically. Zero changes to the router. Zero changes to anything.

Adding a new guided record type costs one subflow and one Decision branch. Build the subflow with its screens, field defaults, and assignment logic. Add a branch to the Decision element. Done. The router stays thin; the complexity lives in the subflows where it belongs.

Admins can read it. The router flow is the map. Open it and you can see every record type that gets special treatment and what happens for each one. No hunting through multiple components or custom buttons to reconstruct the picture.

Where this gets real

The Apex action is the only code in the whole pattern. It returns a list of RecordTypeInfo objects filtered by isAvailable() - the method that checks the running user's profile. Everything else is declarative: flow screens, Decision elements, subflow calls, navigation.

The subflows are self-contained. Each one owns its record type's creation experience end-to-end: which fields to show, what defaults to set, which queue to assign, whether to redirect to the new record or back to the list. You can modify one guided type's behavior without touching anything else.

The default branch uses a standard NavigateToNewRecord action. Users who pick a non-guided record type land on the exact same page they'd see without the override. They don't know they went through a flow. That's the point.

When not to use this pattern

Use a simpler approach if:

• All record types can use standard creation with minor field/page layout differences.
• You only have one special guided path and it does not need to replace every "New" entry point.
• Your team cannot support the small Apex action needed for profile-aware record type filtering.

Build it

If you want to implement this pattern step by step, the companion guide walks through the full stack: Build a Record Type Router Flow.

The principle

When you need to change how a door works, don't add a second door. Override the one that's already there.

The best systems work like the ones they replace - same button, same place, just smarter behind it.