How Flowo Schedules Reminders: A Ledger and a 64-Alert Budget

When we ask for permission

Flowo asks for notification permission during onboarding, after the first task has been created and its schedule applied. At that point reminders describe something the person can already see on screen.

The screen before the system prompt has one button, and that button opens the prompt. It has no skip button, because declining the system prompt is how a person says no. Onboarding continues with either answer.

The operating system shows its prompt once. After a refusal, later requests return the earlier decision without any dialog. Every entry point in Flowo therefore goes through one helper that checks the current state, makes the request, and if the answer is still no, offers a dialog that opens the app's page in system Settings.

Three categories and what each may interrupt

Flowo sends notifications in three categories, and each maps to a different interruption level on iOS and a separate channel on Android.

• Reminder: the notice ahead of a scheduled block. Android high importance, iOS active.
• Loud: the final reminder at five minutes or less before a start. Android maximum importance with the alarm category and vibration, iOS time-sensitive.
• Recap: the quiet category, used today for the reminder that a subscription pause has ended. Android default importance, iOS passive.

On Android the channels are named Task Reminders, Deadlines & Overdue and Evening Recap. A person can turn one of them off in system settings and keep the other two.

We built a fourth tier that used iOS Critical Alerts. Apple declined the entitlement on 15 September 2026 because it is reserved for medical, security and public safety apps, and Flowo is a planning tool. We removed the tier, and the app deletes the retired Android channel from devices that had it. No category requests a full-screen intent.

How a schedule change reaches the queue

Every schedule mutation in Flowo publishes a reason on a single event bus, and notification reconciliation listens to that bus. A change to the plan and the change to its reminders travel as one event.

The bus coalesces. An operation runs inside a zone-scoped scope, every reason published inside it is collected into a set, and one event is emitted when the scope closes. Each event carries a revision number that increases by one. An operation that throws emits nothing.

A post-commit orchestrator subscribes to the bus and keeps a single pending slot. While one reconcile pass is running, newer events overwrite that slot. When the pass finishes, the orchestrator runs once more for the latest revision. A burst of edits during a slow pass costs one extra pass.

How the reconciler decides what to schedule

The reconciler compares a list of desired reminders with a ledger of what it has already handed to the operating system, and it changes only the difference.

1. 1.Each scheduled block yields up to two intents, a first and a second reminder, each a number of minutes before the start that is stored on the task.
2. 2.Each intent has a stable key built from the task, the block's position and the reminder role, and a SHA-256 fingerprint over its time, title, body, payload and category.
3. 3.Intents outside the next 48 hours are dropped.
4. 4.The rest are sorted: loud first, ordinary reminders next, and last the reminders for a block that starts within 15 minutes of a different task ending. Ties go to task priority and then to the earlier time.
5. 5.The budget is 64 minus any pending notifications the ledger does not own. Only that many intents are kept.
6. 6.An intent is sent to the operating system when its fingerprint differs from the applied one or when the system no longer holds its id. The second case is counted as a repair.
7. 7.Ledger records with no desired intent are cancelled.

Notification ids come from an FNV-1a hash of the stable key, with a step forward on collision. The ledger is written before the first change and after each one, so an interrupted pass resumes from a known state.

What the background top-up does

The background top-up is a best-effort repair for people who have not opened Flowo for a while. It is a periodic task registered once a day with a battery-not-low constraint. The same top-up also runs when the app starts and each time it returns to the foreground.

The worker first reads a lease file. The running app stamps that file every 2 minutes, and a stamp counts as held for 10 minutes. If the lease is held or unreadable, the worker exits before opening any storage. Two isolates opening one Hive box can truncate the file, and a late reminder costs less than lost tasks.

The worker never calls the planner or the AI backend. It builds intents from stored tasks and blocks and takes the text from a cache that expires after 7 days. When the cache has no entry, the reminder uses the task title and a localized line such as the number of minutes until the start.

What Flowo does not send

A block produces no reminder once it is done, dismissed or skipped, or once its task is completed or archived. A future block marked skipped means the person took it off the schedule, and a reminder for it would undo that choice.

Nothing in the notification code refers to streaks. Flowo has no alert that warns about a count that is about to end.