Memory & Blockers
Memory is org-level context attached to your app. Blocker rules dismiss popups automatically, with no step in any script.
Memory is org-level context attached to a registered app. Blocker rules are its main content — a condition and one recovery action, written once, applied to every run.
Platforms
Android · iOS
Scope
The app, org-wide. Every test everyone runs against that package
Linked to
A registered app. Multiple package names can map to one entry
Hard limit
One action per rule. A rule cannot do X then Y
Watch out
A rule that dismisses something a test is meant to check will hide a real bug
Prerequisites
Drizz desktop app installed and signed in
An app registered through the web app
The exact on-screen text of the popup being dismissed
Copy this
Blocker rules for ShopEase. Each is a condition and a single recovery action.
blocker: A promotional or upsell bottom sheet is visible unexpectedly.
recovery: Tap the Close ("X") CTA.
blocker: "Your internet is a little wonky" with a Retry button.
recovery: Tap on Retry
blocker: Permission prompt for location or notifications is visible.
recovery: Tap "While using the app"
blocker: "Rate ShopEase" bottom sheet is visible over the home or order screen.
recovery: Tap "Not Now".
blocker: First time user experience flow with a "Continue to [section]" button (e.g. "Continue to Deals").
recovery: Tap on the "Continue to [section]" buttonWith those five in Memory, no ShopEase test needs an IF block for any of them.
What Memory holds
Memory holds context about an app that makes Vision AI more accurate on it: blocker rules, plus app-specific hints.
Scope
An app, not a test. Everything in it applies to every run against that package
Link
A registered app — one uploaded through the web app
Package mapping
Multiple package names can map to one entry, which covers debug, staging and production builds with different IDs
Sharing
Shared across the whole organization. Every member's tests get it
Lifetime
Until it is changed
Memory v/s Variables
Memory (this page)
Org-level context about an app — blocker rules and hints
The Memory area, attached to a registered app
Until you change it
Variables (Store / SET)
Values a test captures or assigns while it runs
Inside one test run
That run only
These docs say Memory for the app context and variables for the other. Store the Order Total as total belongs to Store & SET.
Blocker rules
Each rule is a condition and a single recovery action. Drizz applies it during any run, with no step in any script.
A rule fires only when Drizz decides the screen is blocked. It isn't a background clicker — a matching popup that isn't in the way is left alone.
Constraints on a rule
One action per rule
Hard limit. A rule cannot do X and then Y. Recovery that needs two steps belongs in an IF block in the script
Appending a wait
The one accepted extension of a single action: recovery: Tap "Add separately" CTA and wait for 2 seconds.
Exact text
Quote the exact on-screen text in the condition. Vague conditions over-match and dismiss things they shouldn't
Nothing under test
A rule that closes a dialog a test validates — "Payment failed" — turns a real bug into a green run
Org-wide effect
A rule affects every test the whole organization runs against that package. A popup that appears in one flow only belongs in an IF block
No duplication
A blocker in Memory must not also be an IF block in scripts. One fires, the other's condition is false, and the script reads as if Memory isn't working
Generic over specific
One pattern rule replaces five near-identical rules
blocker: a popup is visible
blocker: "Rate ShopEase" bottom sheet is visible over the home screen.
blocker: an error appears
blocker: "Your internet is a little wonky" with a Retry button.
A generic pattern rule:
Memory rule v/s IF block
Use when the popup can appear in any test, at any point.
Written in
The Memory area, against a registered app
Applies to
Every test in the organization that runs against that package
Actions allowed
One
Steps in the script
None
Use when the state is tied to one screen or one scenario.
Written in
The test script
Applies to
That test only
Actions allowed
Any number
Steps in the script
One block per popup, per test
The maximise button block belongs in every test that runs on tablets. Parallel runs can reset orientation to portrait.
Common mistakes
recovery: Tap Close then tap Continue
Two actions. One action per rule — this is a hard limit
blocker: a bottom sheet is visible
Over-matches. It starts dismissing sheets your tests need
A rule that closes the "Payment failed" dialog
The test that checks for that error passes forever
The same popup in Memory and in an IF block
Confusing to read, and hides whether Memory is working
A rule for a popup only your one test sees
Every test in the org now pays for a check it doesn't need
Expecting Memory to fix a flaky tap
Memory dismisses blockers. It doesn't improve targeting — fix the description
Confusing Memory with Store
Different features, same word. See the table above
Next
Last updated: 6 August 2026
Last updated
Was this helpful?