How I Actually Use Microsoft To Do for Scheduled Reminders
1. Missed reminders caused by default list not being selected
This one wasted half a day. I had a whole Zap built to generate reminders from Slack messages, and it looked like everything was working — task names, due dates, priority, all pushed into Microsoft To Do just fine. But the notifications? Silent. Nothing landed on my Today view unless I manually opened the Tasks list, where everything was hiding.
Turns out Microsoft To Do doesn’t always default to your active list for scheduled reminders. If no specific list is set via automation or rule, the task drops into the first synced list alphabetically. Reminders attached to those tasks don’t surface unless that specific list is flagged as showing in My Day or you search manually. No error. No failed Zap. Just a void.
Fix was just adding a direct list ID reference in the Zap action. You get those from the URL inside To Do (copy and paste that long mess after /task/…). Weirdly, even using list name alone sometimes fails silently if it can’t resolve the account connection properly. List ID works every time.
2. Recurring reminders fail if task is created via API
Setting up recurring reminders is easy in the UI — set something for Monday, hit repeat every week, done. But when you hook into Microsoft To Do through Zapier or Power Automate or even direct API — recurring tasks become a black pit of inconsistency.
I set up a recurring bill checklist using a database in Airtable, and everything flowed perfectly… until I noticed that tasks created via API lacked an actual recurrence engine. They were one-offs. Even when passing the expected recurrence pattern JSON, the system just ignored it.
Posting `recurrence: { pattern: { type: daily } }` does not generate any actual behavior in To Do unless all required recurrence fields are populated — including dueDateTime and a startDateTime. You get 200 OK, but it’s a dead-end task.
This isn’t obvious from the interface because tasks appear with the correct due date… just no repeat setting. And without that, reminders behave like single-use landmines. Zero context—a team member assumes it’s a stream of duplicates, not re-generated recurring items.
3. Cortana integration creates phantom tasks that confuse automation
I found this out after thinking one of my Zaps was duplicating entries mysteriously. We had a calendar-to-task workflow pushing meeting prep notes into Microsoft To Do ahead of events. It worked fine until suddenly there were phantom tasks showing up a few hours earlier than the original events — same names, but without any of the notes or structure.
After nuking the Zap and rebuilding from scratch, same problem. These weren’t duplicates from the Zap… they were from Cortana. Somehow, my Microsoft account was still authorized to sync Outlook calendar entries with Cortana, which silently feeds them into the Tasks app under a hidden label. These entries aren’t exposed to Zapier or Make at all — but they show up in To Do’s interface. You can’t filter them out unless you unsubscribe Cortana directly from the connected services settings buried under cloudflare.com.
It’s not obvious they’re coming from Cortana at first glance unless you open the task details. There’s a note underneath saying “created from Cortana” but it’s easy to miss among the timestamps. If your reminder count feels off, check for these phantoms.
4. Fixing weird time zone behavior with due times on mobile
I was on vacation (not that I ever actually stop working), and a reminder popped up six hours late for a client call. Microsoft To Do on Android decided to politely ignore the device time zone and stick with whatever the account’s default was — which still thought I was drinking coffee at home instead of already into round two of tapas somewhere else.
This mostly happens when creating tasks through third-party integrations or scripts — To Do’s mobile app doesn’t always re-sync dueDateTime settings properly after initial sync if the due time is set in UTC via API. Instead of recalculating for the new local time, it just… doesn’t. The task triggers locally on some kind of outdated offset once you’re in another zone.
The only fix I found was to open the task directly on the mobile app and toggle the reminder off/on. Doing this forced the scheduler to reapply the time offset based on phone location. An annoying manual patch, but at least it gave the correct behavior. I tried triggering a sync from inside settings, but that doesn’t reset existing task reminders.
Also worth noting: assigning a time to a task that only has a due date (not dueDateTime) will silently assume 8am device time — this isn’t documented anywhere, but I confirmed it by dropping timestamps into task notes, running triggers, and checking logs.
5. Zapier and To Do have brittle authentication reconnect behavior
There’s a weird fragility between Microsoft To Do’s OAuth tokens and Zapier’s app connection. If you refresh your Microsoft password, or your session expires after inactivity, the token expires silently and starts failing in Zapier — but failing subtly. Nothing shows in “Task History.” Zaps don’t error. They just don’t run.
The catch
If that To Do action isn’t the first step in a Zap, earlier steps might still fire (like sending a confirmation to Slack), making it look like everything ran top to bottom. I had a daily planner build that texted my tasks to me every morning. It started missing one or two entries per day, only some of which came from To Do.
It took me a full week to realize the connection had quietly expired after a vacation login change.
There’s no notification for this, either. Token expiration just invalidates your connection silently.
- Log into Zapier and open “+ My Apps” — make sure Microsoft account still shows “Connected”
- Click “Test Connection” even if it says Connected
- If you get a warning, reconnect immediately. If not, you’re fine — for now.
- Recheck all your Zaps where To Do isn’t the first or only step, especially ones that create tasks conditionally
- Put a dummy text step after your To Do action just to verify it ran correctly — you’ll spot failures mid-Zap
Honestly, this one could’ve been avoided if Zapier logged token errors more visibly. Or if Microsoft’s token expiry wasn’t so randomly fatal.
6. My Day tasks don’t persist without manual pinning or reflagging
This isn’t a bug, but it is a confusing UX behavior that screws up most My Day workflows. Let’s say you have a Zap that sends priority tasks to Microsoft To Do, and you flag them as important for surfacing. You assume they’ll stick to the My Day view because — well, it’s literally called “My Day.” But nope.
Microsoft auto-clears My Day every 24 hours. Unless a task is pinned or re-added manually each morning, even the most crucial items disappear from view. They still exist in other lists, but out of sight, they’re basically gone.
I missed an internal deadline because I built a morning triage Zap that populated My Day automatically… once. All future rebalance drafts went to the back office list, and I never saw them. I later learned that Microsoft doesn’t expose the isInMyDay flag through Zapier natively — so you can’t re-add it that way. You have to go through Graph API or use PowerShell.
The only way around it inside Zapier is indirectly — recreate the task with a new title + flag it again, which resets its visibility. It’s ugly, but it works.
Still haven’t figured out how to persist My Day across device syncs without opening the app first thing each day. It seems to be a design choice, not a bug.
7. Shared lists behave differently than personal lists in automation
Had a project manager create a shared list for dev sprints. Works great in the UI: everyone sees the same tasks, all real-time, all expected. But you go and try to inject tasks into that shared list via automation? Totally different ruleset.
Microsoft To Do treats shared lists as group objects under the hood — and that means they surface under a different internal ID in automation tools. You can’t use the visible name if the list was created by someone ELSE. You need their list ID and access to their MS tenant permission, or the Zap just errors out saying the list doesn’t exist.
Even after manually fetching the list ID from my colleague’s export, I had to create the Zap under their Microsoft login — not mine. No way to push into someone else’s shared list unless your account was the original list creator or has full tenant-level graph permissions via Azure.
Not ideal when 5 people are collaborating and everyone just wants their app to work without involving IT. It’d help if these limitations were flagged somewhere in the Zap builder, but they’re not. You only learn when it quietly fails mid-deploy.