Beginner second brain mistakes that nearly broke my business

Ever since I started building a second brain inside Notion and Obsidian, I’ve accidentally wrecked my own system at least four times. The latest one was… genuinely spectacular. It began when a synced block in Notion stopped syncing. Like, completely. It just became a normal block, and no one in my team noticed until we realized our weekly client prompts were three weeks out of date 🙃

I’ll walk you through the specific things that broke when I reused old settings, rebuilt automations with half-finished logic, or forgot how something even worked in the first place. If you’re an entrepreneur building a digital brain for the first time — probably trying to mix task management, content planning, and a little life admin — this is for you.

1. Connecting Notion to Zapier and forgetting database filters

The first real pain point happened when I cloned an old Zap that listened to new database entries in Notion and sent a Slack message. It worked like a charm for my content reminders back in 2022. But when I reused it for my new team tracking dashboard, it started triggering… randomly. Sometimes when nothing changed. Other times, it wouldn’t trigger at all.

Turns out: I forgot the original version had very specific database filters, and the new database structure didn’t support them. But Zapier didn’t say anything about the filters failing — it just silently skipped the trigger or used a fallback that made no sense.

What I learned:
– Use the Zapier built-in Zaps History (under the Zap run details) to see what filters are silently failing
– Even if you duplicate a working Zap, double check that your database IDs and property conditions still make sense

What’s worse: if a Notion database relation field was blank, the Zap filter would sometimes treat it as a null value, and other times as a failed match — depending on the property type 😑

2. Using templates that look helpful but silently reset your settings

So someone shared a beautiful Content Calendar template in Notion that tracked stages, publishing platforms, thumbnails, and team assignments. I imported it. Everything looked fine.

Except: when I tried to reuse my existing automations (like the PublishDate field triggering an email to the editor), they all broke. The date property looked identical, but under the hood, it wasn’t the same. Not only was the property name slightly different (it used emojis, which I didn’t notice), the format had also changed from full timestamp to date-only.

The kicker? Zapier didn’t tell me that the mapped fields had changed. Every time I opened the Zap trigger condition, it just showed “This field is missing” — but no explanation of why or what changed. I spent a good two hours manually comparing field names between the template and my original.

Lesson learned:
– Set your core data properties **first**, then paste in any templates — not the other way around.
– Watch for emoji-labeled fields that don’t copy/paste well across integrations
– If Zapier says “field is missing” and you KNOW it exists, it might just be formatted differently

I’ve started labeling fields with a suffix like `_zap` just to keep track of which ones are wired into automations. Not pretty, but it works.

3. When synced blocks in Notion become dumb text for no reason

This one actually broke a client workflow — and I didn’t find out until someone asked why the next Tuesday promo still had April’s quote. I had originally created a synced block with all our rotating call-to-action text. The idea: edit it once, and it updates across the board.

Except Notion had quietly converted some of our synced blocks into local blocks. I didn’t click “unlink” or anything. But I suspect it broke when someone duplicated a page that contained synced blocks. Once duplicated, the blocks lost their sync reference. Again, Notion didn’t show any notification.

Real convo with a team member:
“Wait… I thought the signup text would auto-update?”
“Yeah, it should.”
“But this still says ‘Product Launch April 17.’ That was weeks ago.”
“WTF.”

Here’s how I catch it now:
– When duplicating a page, always test the synced block AFTER — click into it and look for the “Synced block” tag.
– Syncing still works if you copy/paste the block, but not if you duplicate the page that contains it
– Trust no duplicated synced block unless you verify it manually 🙂

4. Obsidian daily notes messed up by filepath reuse

I switched to Obsidian for my personal notes and reflections, but now I’m using it for task triage and meeting logs. One dumb bug tripped me up hard: back when I first set it up, I used the Daily Notes plugin to generate markdown pages at `Inbox/2024-MM-DD`. Worked great all year.

Then I moved them to a new folder called `Tasks/Dailies`, updated the plugin settings, and thought all was fine.

Except the note that opens on startup still pointed to the original `Inbox` path. So every day it would open an old version — sometimes even creating more than one note for the same date in different paths.

On April 7, I accidentally took meeting notes for two calls in two completely separate daily notes… both called “2024-04-07.”

It also confused my Tasks plugin, because it was set to query the `Tasks/Dailies` folder, so any TODOs in the old one never showed up anymore.

What fixed it:
– Open Command Palette → “Open today’s daily note” to confirm the actual path it uses
– Fix startup behavior by resetting Workspace or removing the auto-load plugin that pointed to the old file
– Run a file search in Obsidian for all daily note filenames across all folders — there might be duplicates you forgot about

Things feel more stable now, but I still have one ghost file floating around in the `Inbox` folder that refuses to die ¯\_(ツ)_/¯

5. Reusing Make scenarios that depended on outdated Notion views

Oh boy. The Make.com Notion integration doesn’t support filtered views — but at one point, it semi-did, if you used the preview tables in public databases (I know, it was weird). I built some scenarios that relied on a specific view showing only ready-to-send newsletters.

Well, the view changed.

I didn’t notice, because the database still existed, and the model opened fine in the Make editor. But the filtered view no longer included any rows, so my scenario quietly returned “0 results.” Every Sunday.

The worst part? The modules didn’t error — they ran successfully, but with null data. So my send-to-mailer module eventually tried to send a blank newsletter.

What finally tipped me off:
– The Airtable backup (thank god I had one) showed blank issues for two weeks straight
– The log messages said “NewsletterTitle: undefined” but didn’t throw a proper error

Takeaways:
– Do NOT rely on database views when building in Make — just use raw filters in the module
– If a scenario step depends on a specific content flag, validate it with a fallback filter like “Published is true AND Title is not empty”
– Set up an alert route when row count is zero — even a failed log to Slack is better than silence

I also started adding a manual summary to each weekly run in Slack: “✅ Issue Y sent (785 words)” — just to visually confirm it worked.

6. Shared calendar failed when syncing fields got renamed

We were syncing a shared content calendar from Notion into Google Calendar via Zapier. It worked fine… until I renamed one field from `EventDateTime` to `GoLiveDate` to make it sound clearer. Calendar stopped updating new entries completely.

Why? Because although the Zap still existed and looked fine, the input field in the Zap step now said “This input is no longer available.” But Zapier didn’t mark the Zap as broken — it said “ON,” and ran without triggering any errors.

I didn’t notice until someone said, “Is there no content this week?” and we looked at a completely blank team calendar.

Eventually found the issue after digging through the run history and seeing:
`Create Google Calendar Event → input [StartTime] → value: null`

Tips from this painful lesson:
– Once your Zaps are stable, avoid renaming fields in Notion that are mapped to automated triggers
– If you *must* rename, duplicate the property and phase it in manually — then update the Zap step once
– Consider putting field names in hover text or comment fields so you don’t forget which ones are automated

I’ve started keeping a living doc that maps which Notion fields are wired into which Zaps, just to avoid these silent breaks.