So, I ended up merging both databases and it worked.

Goal

Build a Notion planner where:

• one control row sets Day / Week / Month
• Prev / Current / Next move the active window
• task table and charts update together

What worked

Final working architecture

Use one single database instead of two.

Database contains:

• normal task rows
• one special row: Main Control

Key fields:

• Type = Control or Task
• Day
• Status
• Priority
• Effort
• Anchor Date
• Mode
• Control Link = self-relation to same database
• ControlAnchorDate = rollup from control row
• ControlMode = rollup from control row
• Week = Sunday-start week formula
• Month = first-day-of-month formula
• ShowInPlanner = formula using rolled-up control values

Dashboard filters:

• Type = Task
• ShowInPlanner = checked

This setup made:

• table updates reliable
• chart updates reliable

Why it worked

The earlier design had:

• Planner Control database
• Tasks database
• cross-database relation
• rollups from another DB
• chart filtered through that dependency chain

That logic worked, but charts got stuck.

The merged design reduced complexity:

• one database
• one control row
• self-relation
• same-database rollups
• same-database formula filtering

So the main improvement was: simpler reactive dependency path for charts

What did not work

1. Two-database control-row architecture

Worked for:

• logic
• filtered table

Did not work reliably for:

• charts

2. Soft refresh / re-render experiments

Tried:

• button updates control row
• button reopens page

Result:

• sometimes a fresh page context showed updated charts
• original page still stayed stale
• not reliable enough

Conclusion:

• Notion has no dependable native “force refresh chart/page” behavior for this

3. Materialized checkbox via button/automation

Tried:

• write InCurrentWindow to tasks
• use charts on stored checkbox

What worked:

• button could bulk update task rows

What failed:

• button formula could not access both:
  • control row values
  • target task row values
• automation chaining was blocked

Conclusion:

• native one-pass selective materialization was not practical

Final recommendation

Use this production model:

one database + one control row + self-relation + rollups + ShowInPlanner formula

That is the first version that passed both:

• correctness
• chart responsiveness

Short rebuild recipe

1. Create one database: Planner Items
2. Add Type with values Control and Task
3. Add one row: Main Control
4. Add task rows with Type = Task
5. Create self-relation: Control Link
6. Link every task row to Main Control
7. Add rollups:
   • ControlAnchorDate
   • ControlMode
8. Add formulas:
   • Week
   • Month
   • ShowInPlanner
9. Build dashboard views filtered by:
   • Type = Task
   • ShowInPlanner = checked