Authenticated deep linking — routing customers from web into the app

Context

An institution's public website advertises something — a product, an offer, a feature. A customer taps it. They should land on the right authenticated destination inside the banking app.

Between those two sentences sits most of the problem.

Why it is harder than it sounds

The route depends on state the link cannot see:

• Is the app installed?
• Is the customer already authenticated, and is that session still valid?
• Is this a desktop browser, where there is no app to open at all?
• Does the destination exist for this institution, given each tenant enables a different feature set?
• If authentication is required first, does the intended destination survive the login journey?

Dropping someone at the dashboard after they have authenticated is the most common outcome of a poorly specified deep link. From the customer's side, it reads as the link being broken.

What I produced

Mapped the full flow architecture: every combination of platform, install state and authentication state, and the correct routing for each — including the cases where the correct answer is a graceful fallback rather than the intended destination.

The deliverable was architecture rather than screens. Most of the branches never render anything new; they resolve to an existing screen with different context attached. The design work was deciding which one, and ensuring intent persisted across an authentication boundary.