Build With Me: A Family Tree In Notion

A practical Notion setup for building a searchable family tree hinges on modeling people as pages, then wiring parent-child relationships into a timeline and a location “atlas.” Instead of treating genealogy as a static chart, the system uses relational properties so each person can automatically connect to birth/death years, places, and historical context—turning a family line into a living database.

The build starts with a “timeline” database organized by broad date ranges (e.g., 1850–1899, 1900–1949) and finer “decade cards” within each range. A separate “atlas” database classifies places using select properties for country, U.S. state, and city/region. People then get linked to this atlas through location fields: where someone was born, where they lived (residents), and where they died (buried/died). Those location relations feed into filtered views like “deaths from family tree” and “births from family tree,” enabling map-style exploration (including optional Google Maps embeds).

The family tree itself is structured around parent-child relations and generation tracking. A “generation” property uses multi-select values to label where someone sits in the direct line (for example, 32a/32b moving toward the present). Spouse relationships are created by relating the people table to itself, with the important nuance that spouses are added as marriage partners (not as part of the ancestral generation chain). Children are handled through a second self-relation: a “children” property syncs both ways, and a “parents” property is derived so that when children are added, their parents populate automatically.

To connect people to the timeline, the system introduces a “lifespan” date property plus separate “year born” and “year died” relations that point into the decade cards. This allows births and deaths to appear in the correct decade buckets. The transcript also details a formula-driven “age” field that produces different outputs depending on what’s known: “unknown” when both birth and death are missing; “age” when only a birth date exists (treating the person as still alive); “age died” when a death date exists; and an “approximate age died” mode when only years are available. Special handling is included for cases like “year died = unknown,” so the formula doesn’t mislabel living people.

Finally, the design emphasizes keeping the database manageable by limiting generation tags to the direct line. Star emojis mark the main ancestral path, while siblings and collateral relatives can be included without cluttering the generation views. There’s also an open problem: generating a clean “siblings” list via rollups is tricky because rolling up through parents can mix children from both mother and father; a workable approach likely requires separating parent roles by mother vs. father or adding more structure. Overall, the system matters because it turns genealogy into a queryable dataset—one that can be filtered by decade, place, and lineage rather than locked into a single diagram.