# What happens when an Adalo deep link opens without the app?

Choose what people see when an Adalo deep link cannot open the installed app, then set up a PWA or device-specific fallback and test both paths.

- Canonical URL: https://adalocado.com/guides/adalo-deep-link-fallbacks
- Verification: Documented from current sources
- Topic: Actions and Logic
- Skill level: Beginner
- Last reviewed: 2026-09-23
- Index status: index-now

## Short answer

A fallback is the backup destination for a deep link. If the app is installed, the link should open the chosen app screen. If it is not installed, Adalo can open the same screen in the browser-based PWA or send the person to a custom iOS or Android URL.

Set the destination screen first, then choose the backup path. Use the PWA when the browser version can still help the person. Use separate iOS and Android URLs when the next step should depend on the device. Most important, test the exact same link with the app installed and uninstalled. That is the only way to confirm both journeys make sense.

## Intended outcome

A deep link with a clear backup path, so people who do not have the app installed still land somewhere useful.

## Requirements

- A published Adalo app with a screen you want to open
- A route name set in that screen's Deep Linking settings
- A browser PWA or final HTTPS fallback URLs for iOS and Android
- At least one real device for the installed and uninstalled tests

## Step by step

1. **Set up the screen link first**

   Select the destination screen's name in the builder, open Deep Linking, give the screen a short route name, and copy the generated URL. Preview links do not support this test.

2. **Decide what the backup should do**

   Choose Redirect to PWA when the browser version of the same screen is useful. Choose Custom Redirect when people should go somewhere else, such as the correct app-store page.

3. **Add the fallback**

   In Deep Linking Settings, open Redirection and Fallback. Select Redirect to PWA, or select Custom Redirect and enter the complete HTTPS URLs for iOS and Android.

4. **Save the screen settings**

   Save the deep-link configuration, then use the copied screen URL wherever people will open or share it.

5. **Test both real-world paths**

   Open the same link once on a device that has the app and once on a device that does not. Confirm the first reaches the app screen and the second reaches the intended backup.

## Why it works

- A deep link has two possible journeys. The installed path tries to open a screen inside the native app. The fallback path takes over when that native app cannot open.
- Redirect to PWA keeps the person in the same experience by opening the browser version. Custom Redirect gives you control over the destination for each mobile platform.
- The fallback does not fix a wrong screen route, missing record data, or permission problem. Those issues must be tested separately.

## Data model

| Collection | Properties | Relationships |
| --- | --- | --- |
| Optional linked record | The record ID or other value carried in the link | Must already be Available Data on the destination screen; no new collection is needed for a screen-only link |

## Common failures

### The link only opens a browser page

Confirm the app is installed on that device and that you are testing the published deep link, not an Adalo Preview link. Then check the screen route and published app setup.

### The fallback opens the wrong store or website

Recheck the full iOS and Android URLs. Test each one directly in the matching device browser before testing the deep link again.

### The right screen opens but the record is missing

Check that the destination screen has the record as Available Data and that the link includes the expected query parameter or record value.

### The PWA asks the person to log in

Treat sign-in as part of the fallback journey. After login, verify that the user can still reach the intended screen and is allowed to read its data.

## Testing checklist

- [ ] The link opens the intended screen when the app is installed on a supported device.
- [ ] The same link reaches the chosen fallback when the app is not installed.
- [ ] The iOS fallback opens the intended iOS destination on a real iPhone or iPad.
- [ ] The Android fallback opens the intended Android destination on a real Android device.
- [ ] The screen route is short, stable, and spelled correctly
- [ ] The fallback choice matches the experience you want
- [ ] Both custom URLs use HTTPS and open directly
- [ ] Installed and uninstalled cases have been tested separately
- [ ] A data-based link uses a real record the test user can access

## Limitations

- Adalo Preview links do not support deep linking, so a Preview-tab test cannot prove the final behavior.
- This guide is based on current public documentation and screenshots, not a complete test across every browser, device, and app-store state.
- A deep link can only show record data that the destination screen already has available and that the user is allowed to access.
## Sources

- [Adalo: Deep Linking Redirection and Fallbacks](https://help.adalo.com/component-basics/inserting-and-editing-screens/deep-linking/deep-linking-redirection-and-fallbacks)
- [Adalo: Set Up Deep Linking](https://help.adalo.com/component-basics/inserting-and-editing-screens/deep-linking/setup-deep-linking)
- [Adalo: Deep Linking With Data](https://help.adalo.com/component-basics/inserting-and-editing-screens/deep-linking/deep-linking-with-data)

Markdown version: https://adalocado.com/guides/adalo-deep-link-fallbacks.md