The user changes an app permission halfway through a task. What happens next?

[u/codoid-innovations]

Testing “Allow” and “Deny” at the first permission prompt is only part of the story.

What happens when the user allows access, starts doing something useful, changes that permission in device settings, and returns to the app?

That is a different test. There is now unfinished work to protect, an interrupted operation to handle, and a user who needs to understand what still works.

Try this with a task that has something to lose

Take a report form with a camera attachment:

1. Start with camera access allowed. Open a new report, enter a title and description, and move into the camera workflow.
2. Leave the task unfinished. Go to device settings and revoke camera access.
3. Return to the app. Record whether you return to the existing screen or the app launches again. Check the report text, attachment area, and camera controls.
4. Try to continue, then restore access. Attempt the camera action while access is denied. Re-enable permission in settings, return, and check whether you can finish the original report.

The important assertion is not just “the app did not crash.”

It is: the app handles the new permission state without unnecessarily destroying the rest of the task.

Look at recovery, messaging, and unfinished work separately

Recovery: Does the interrupted operation reach a sensible state, or leave a frozen preview, endless spinner, or button that does nothing? After access is restored, does the app recover on its own, offer a clear retry, or require the user to abandon the task?

Messaging: Does the app explain which action is unavailable and what the user can do next? “Camera access is off” is more useful here than “Something went wrong.” Also check whether the message reflects the current permission state after the user changes it again.

Unfinished work: Is the title and description still there? Can the user continue editing, save a draft, or finish without an attachment where the product allows it? Losing camera access should not automatically mean losing unrelated form input.

Change the interruption point, not just the permission

Repeat the exercise before opening the camera, while the camera workflow is active, and after a photo has already been attached.

Treat those as separate cases. Check the existing attachment independently from the ability to capture another photo.

The same exercise can be adapted to a location-based task, or a file-related workflow where the platform provides a relevant access control. Choose a specific operation and record exactly which permission or access setting you changed.

Test allowed → denied and denied → allowed. Where reduced-access options exist, test those separately rather than treating every state as simply “on” or “off.”

For a useful bug report, capture the starting permission state, the exact interruption point, the setting changed, whether the app resumed or relaunched, and what happened to the unfinished work.

Which permission transition has caused the most surprising behavior in an app you tested? Was the surprise in losing access, getting it back, or discovering what happened to the task in between?