TLDR: After creating a record, navigate straight to it. Don't drop the user back on a list and make them hunt for what they just made.

The Setup

We're building an iOS CRM for an ecommerce business's KOL (Key Opinion Leader, think doctors and wellness influencers they partner with) relationship team.

The app lets you manage contacts, track relationship warmth, log outreach. Standard CRM stuff, native iOS.

When the "Add new KOL" flow was first wired up, it worked like this: fill in the details, tap Save, get sent back to the contact list.

Simple. Fine. Shipped.

The Wall We Hit

Except… the list was stale.

You'd save a new contact, land back on the list, and your new entry wasn't there. The list hadn't refreshed. You'd scroll, second-guess yourself, tap back in, fill it out again — sometimes creating a duplicate.

We fixed the stale list. Forced a refresh on return. Problem solved, right?

Not quite. Because now you're back on a long contact list and your new record is in there somewhere, mixed in with everyone else. You have to go find it.

It wasn't broken anymore. It was just friction. The kind that makes users vaguely distrust a UI without being able to say why.

What Finally Worked

After createKOL() returns the new record from KOLService, skip the list entirely — push straight to the new contact's detail view.

Something like:

let newContact = try await kolService.createKOL(draft)
// push newContact onto the nav stack → detail view opens

The moment the record exists in the database, the app takes you there. Same screen you'd land on if you tapped it in the list. New contact, fully formed, ready to edit. No hunting. No "did that actually save?" No list trauma.

It Spreads Once You See It

I had the same pattern sitting on the web side and hadn't noticed it.

The MatterIntakeForm in a law firm client's practice management app — a CRM-meets-case-tracker I'm building for a small law firm — was doing the exact same thing. Create a matter, return to a list, go find it.

I wired it to redirect straight to /matters/[id] on success instead.

Same two lines, different stack. Same instant improvement.

Why This Matters

The principle is simple: creation should feel like arrival, not abandonment.

When a user hits Save, they aren't done with that record — they're starting with it. They want to add a phone number, link a topic, double-check a field. Dropping them on a list forces a U-turn before they've even begun.

Auto-navigating to the new record is the app saying: here's the thing you made — carry on.

One of those UX details you only notice when it's missing. And once you add it, you can't imagine shipping without it.

P.S. The stale-list anxiety disappears completely too — because you're looking at the result, not wondering if it's somewhere in the list.