> ## Documentation Index
> Fetch the complete documentation index at: https://docs.attensira.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Notion blog

> Connect a Notion database as your blog: approved articles arrive as draft rows, updates to existing posts wait for your yes, and nothing is ever deleted.

If your blog lives in a Notion database, Attensira can deliver articles into it and propose updates to posts that are already there.

## Connecting

<Steps>
  <Step title="Connect Notion">
    Connect Notion from the workspace's integrations and grant access to the page that holds your blog database.
  </Step>

  <Step title="Pick the blog database">
    Choose the database your posts live in.
  </Step>

  <Step title="Map the columns">
    Tell Attensira which property holds what:

    | Field          | Required | What to map                                                                                 |
    | -------------- | -------- | ------------------------------------------------------------------------------------------- |
    | Title          | Yes      | The title property                                                                          |
    | Slug           | No       | A text property holding the post's slug                                                     |
    | Status         | No       | A status, select or checkbox property, plus its **draft** value and its **published** value |
    | Body           | No       | Empty means the page content. A text property is limited to 2,000 characters                |
    | Published date | No       | A date property                                                                             |

    The mapping is checked against the database's columns when you save it, so a property that does not exist or has the wrong type is refused then, not at the first delivery.
  </Step>
</Steps>

## How an article is delivered

When the agent writes an article that targets Notion, it waits in [Work](/agent/inbox#written-for-you) for your approval like every article does. Approving it (**Send to Notion**) creates a **new row** in the database, in its draft state.

* **Ask or draft mode:** the row stays a draft for your team to publish in Notion.
* **Act mode:** the row is set to published, and its published date to today, **only if** the mapping has a published value. Without one it stays a draft.

A post whose title already exists in the database is not duplicated. The item comes back to you with a link to the existing post.

## How updates work

The agent can list and read the posts in your mapped blog, and propose an update to one as a before/after in Work.

* Updates **always wait for your approval**, in every mode, act included.
* Approving replaces that post's content in Notion. The old blocks are archived, not deleted, so Notion's own history still has them.
* An update never changes the post's status.
* We never delete a Notion post.

The three agent tools behind this, `list_blog_posts`, `read_blog_post` and `propose_blog_update`, are offered only when a Notion blog database is mapped. See [The agent's tools](/agent/agent-tools).

## After it ships

Publishing through Notion starts the [before-and-after re-reads](/measure/before-and-after) for the tracked prompts attached to the article, the same as a merged pull request.

## Settings

The mapping is stored in project settings as `notion_blog`, with `database_id`, `database_title`, `title_property`, `slug_property`, `status_property`, `status_kind`, `draft_value`, `published_value`, `body_property` and `published_date_property`. Changes show in the settings log as `notion blog: X → Y`.