---
title: "Verify Android push opens the intended record"
description: "Validate Android notification routing with a prepared sandbox push, checking record identity, account scope, and behavior after the app is opened."
canonical_url: "https://vostride.com/agent-library/android-flows/push-open-correct-record.md"
md_url: "https://vostride.com/agent-library/android-flows/push-open-correct-record.md"
content_kind: "recipe"
topic: "android-flows"
---

# Verify Android push opens the intended record

Validate Android notification routing with a prepared sandbox push, checking record identity, account scope, and behavior after the app is opened.

## Risk

A notification title is easy to match while routing to the wrong record or workspace. The fixture must establish delivery and payload identity independently so the UI test proves routing rather than merely launching the app.

## Fixtures

- A sandbox Android device with notification permission and delivery channel preconfigured externally; select use.mobile.appState: preserve for the prepared session.
- Two test workspaces containing similarly titled issues with different immutable identifiers, with the device signed into the authorized workspace.
- An externally delivered sandbox notification targeting the second issue; retain its non-secret message identifier and routing payload in the fixture report.

## Steps

1. Verify the external fixture reports the intended notification delivered to this test device and that the app begins outside the destination issue.
2. Open the prepared notification using the available notification surface and verify the app shows the expected workspace and exact issue identifier.
3. Verify the issue description and status match the target fixture, not the similarly titled issue in the other workspace.
4. Navigate back within the app and verify the resulting list belongs to the target workspace with the same issue present.
5. Inspect the project-owned notification receipt oracle and verify the open event references the delivered message and intended record once under the documented receipt policy.

## Expected results

- The destination identifier and workspace match the prepared push payload.
- The other workspace issue is not exposed through the notification route.
- The independent receipt uses the intended message identifier and has the expected multiplicity.

## False-pass traps

- Launching the home screen is not successful deep navigation.
- A familiar issue title can conceal routing to an unauthorized or stale record.

## Cleanup

- Remove the delivered test notification and restore the app navigation baseline through the external fixture.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa mobile testing](/docs/agent-qa/guides/mobile-testing.md)
- [agent-qa test](/docs/agent-qa/configuration/test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)

- [Android application QA recipes](/agent-library/android-flows.md)
- [Software factory QA library](/agent-library.md)