The fallback has to be stated, not implied

What it is

Right after a denial, people need to know what they can do now: type an address instead of locating, check the app instead of waiting for a push, pick a file instead of shooting live. If the fallback exists only in code and the UI stalls on a permission error or a blank, "the feature is broken" and "I turned a permission off" get mixed. This entry is about naming the alternate path and pointing to it. It is not about whether an alternate must exist, and not about voiding the denial with the next dialog.

Why it happens

Denial is a state change. If the default layout still assumes a grant, empty lists, greyed buttons, and a spinner that dies explain nothing. People infer cause from visible effect: a map that does not move looks like Location Services is down; missing updates look like an account fault. Explicit notice reconnects cause—"location is off, type an address instead"—and places the next step in the same view: a field, a file picker, a jump to settings. When notice fails, engineering degradation is interactively equivalent to none; people retry the original action or debug the wrong system outside the app.

Where it stops holding

When there is no alternate, the notice should say "this step needs the camera and cannot finish here," and offer a way out of the step—not pretend a fallback exists. A full-screen wall on every visit becomes another interruption; a stable banner or in-place empty state is usually enough. On child or managed devices the person cannot change the permission, so "open Settings to enable" is a dead end; say that an administrator controls it.

Applying it

• At the failure point of that feature, write three things: which permission is currently off, what can be used instead right now, and where to turn the original capability back on if they still want it.
• Put the alternate action in the same view: address field, file picker, in-app inbox entry—not a lone "feature limited" sentence.
• After denial, do not use the system permission dialog as the "notice." Notice is in-app, dismissible, and must not call the authorization API.
• Verify by turning the permission off and entering the feature with no designer present: can the person say within ten seconds where to tap next. Missing the alternate control, or calling the state a crash, means the notice failed.

Related

• Within the group: H4.03.1 After a denial, the rest of the product must still work · H4.03.3 Repeated permission dialogs are a dark pattern
• Adjacent: H4.10 Visibility of Permission State · H3.02 Three Elements of Error Messages · H4.04 Revocable Permissions
• Search terms: permission fallback · denial copy · capability alternative