How to add external users to Notion AI agents
Learn how to add external users to Notion AI agents, choose guest vs member access, and troubleshoot the most common permission issues.
Build a blog-powered employee directory with a database
Learn how to build a blog employee directory from a database, sync author profiles, expose only safe fields, and show role-specific content blocks on each page.
TABLE OF CONTENTS
If you already have a blog database, you can turn its author system into a blog employee directory by syncing one “People” database into your blog’s author profiles, exposing only the fields you actually want public, then using relations + filtered views so each page shows only the ICPs, solutions, and teammates that match that page.
Why use your blog as the “directory engine”
Most employee directories fail because they’re a standalone page that nobody updates. A blog already has:
- author pages
- navigation (tags, categories, search)
- SEO-friendly page structure
If you treat “Author” as “Team member”, you get a directory that stays current because it’s tied to publishing.
The content model for your blog employee directory: two databases, then sync
Start with 2 databases:
- Employee database (internal source of truth)
- Blog authors database (public profiles)
Your goal is not to publish the employee database. Your goal is to publish the blog author page.
What to sync from Employee → Author
Keep the synced fields minimal:
- Name
- Role / title
- Headshot
- Short bio
- Location (optional)
- Public links (LinkedIn, personal site)
Avoid syncing anything that tends to become sensitive or messy:
- personal email / phone
- compensation, HR fields
- internal notes
If you’re doing this in Notion, make the employee DB your internal workspace database and the author DB your publishing-friendly one.
How to show the right related content on each person’s page
The directory becomes powerful when each person page can show:
- ICPs they support
- solutions they work on
- insights (posts) they authored or contributed to
To do this, use relations from Authors → ICPs and Authors → Solutions, then embed filtered views on the author page.
Pattern: relation → filtered linked database view
Example blocks to embed on an Author page:
- “ICPs this person supports” (filtered where ICPs relation contains this author)
- “Solutions this person works on” (filtered where Solutions relation contains this author)
- “Insights by this person” (filtered where Author = this author)
This is the key principle: keep the relationships in properties, then let the page layout show filtered slices.
The common pitfall: a relation that points to “all website pages”
If your ICPs and Solutions live inside a single “Website Pages” database, a relation like:
Author → Website Pages
will show every page, which makes it easy for editors to pick the wrong thing.
Fix option A (recommended): split ICPs and Solutions into separate databases
Create:
- ICPs database
- Solutions database
Then add:
Author → ICPsAuthor → Solutions
Now each relation picker only shows the right type of page.
Fix option B: keep one database, add a “Type” property + filtered templates
If you must keep a single database:
- Add a
Page Typeselect (ICP, Solution, Service, etc.) - Create separate views: “ICPs only”, “Solutions only”
- In your templates, only surface the view that matches the page you’re editing
This doesn’t change what the relation picker can see, but it reduces the chance of someone wiring the wrong connections.
Segmenting content blocks (ICP/solution/team-member) per page
Once your databases are split, each ICP page can have blocks like:
- related team members (filtered by ICP)
- related clients (filtered by ICP)
- related insights (filtered by ICP)
Same pattern for solution pages.
Implementation checklist (so you don’t paint yourself into a corner)
Keep Employee as the internal source of truth
Sync only “public-safe” fields into Author profiles
Use relations for ICPs and Solutions (avoid a single relation to “everything”)
Build page templates that include linked database views filtered to the current page’s relations
Add at least one navigation link from your main blog hub (e.g., Connex Blog) to your directory entry point
Get help building your Notion content model
Building a blog employee directory from a database usually breaks at the sync layer — deciding which employee fields are safe to expose, how to keep author profiles current without manual updates, and how to wire relations so each page shows the right teammates and solutions. If you’ve hit that wall, book a ZoomFlow session — one of our consultants can map out your content model with you live and ship a clean, scalable structure in the same call.
Related Posts
Notion offboarding: prevent loss of private pages
Notion offboarding checklist: protect private pages, claim shared docs, and avoid data loss. Learn what to do on Business vs Enterprise before deleting a user.
A Lightweight Notion Action Tracker for Founders
Build a lightweight Notion action tracking system for founders: Inbox → This Week → Done workflow, optional Projects link, and weekly review checklist.
