Notion Manual Import

Notion Manual Import

What it is: the Notion step for every module - a CSV, a property mapping and the click-path to import, for a user who will upload the database themselves. Any module that gets a selected Notion output routes that step here, so the mapping and the import steps exist in exactly one place.

Overview

Prepares a database so the user can upload it into Notion by hand. It handles the confirmed fields, the CSV, the Notion property mapping, select and status options, the manual import steps, and the post-import verification.

This is a helper: it defines no table of its own and renders whatever field list the active module already confirmed, so its CSV and mapping are derived, never re-invented. It is the Notion workflow, not a consolation prize - the module confirms the fields and hands the Notion step to this file.

Manual outputs need no workspace connection. A requested live build uses the shared contract to verify available tools and the destination before making changes.

Layer: n/a. Fits: every stage. Table code: n/a - it renders the active module's table.

When to Use This Skill

• upload this to Notion
• give me a Notion template
• I will upload it manually
• create a CSV for Notion
• give me Notion import instructions
• Notion is not connected
• set this up in Notion
• make this Notion-ready
• show me how to create this database manually

Use it whenever the user selects Notion as an output, whatever module is active. Also use it when another skill produces a database structure but direct Notion creation is unavailable, or whenever the user requests a manual route.

This helper owns the mapping for both manual output and an authorized connected build.

How It Works

Follow the shared execution contract. The module-specific rules below define only domain fields, decisions, calculations, and safety constraints.

Step 1 - Identify intent

Read the request and pick the intent before asking anything.

• "I will upload it myself", "Notion is not connected", "show me how" -> manual setup; go to Step 2.
• "just give me the CSV" -> import file only. Output: CSV alone.
• "I already have the CSV, what do I set" -> mapping only. Output: property mapping alone.
• "it imported but everything is Text" -> fix existing import. Output: correction instructions for the properties that are wrong, and nothing else unless asked.
• "Notion connected" -> verify tool access. Continue a previously requested workspace build only if the required tools and destination are available; otherwise explain the blocker.

Never rebuild everything when a correction is what was asked for.

Step 2 - Ask only what is missing

Skip anything the user already answered, in any earlier message, including answers given to the module skill that owns the field list. Reuse the database name, the field names and types, the select options, the statuses, the relations, the currency fields, the date fields and the IDs. Never ask for information the user has already provided.

Ask one short question per message, and only when the answer changes the output:

Q: Do you want an empty template or example rows?

If it does not materially change the requested output, do not ask, and default to no example rows:

example_rows: false

Step 3 - Hold the internal context

Hold the answers in this shape. It stays internal - it is not shown to the user unless they ask, and it never carries a value the user did not give.

module: notion-manual-import
intent: null              # set in Step 1, one of: manual setup, import file, mapping, fix
source_module: null       # the module whose field list this renders
notion_connected: null    # true | false | unknown - never assumed either way
requested_outputs: []     # csv | mapping | instructions | verification
example_rows: false
confirmed_facts: []       # only what the user actually said
open_questions: []        # the unanswered ones, in the order worth asking

source_module is the only field this skill needs that a module skill does not have. If it is unknown, ask which database to prepare, because a CSV without a confirmed field list is a guess.

Step 4 - Recommend the smallest workflow

Produce an already requested output without asking again. For advice-only requests, give a short recommendation and offer the relevant output.

Recommended approach: One CSV with a header of the exact field names, one property mapping table beside it, and the import click-path. Nothing else is needed to get a working database.

Why this one: a CSV carries no types, so the import is the easy half and the property configuration is the half that silently goes wrong. Doing the mapping up front is the difference between a database that filters and one that is a wall of Text.

Workflow: Field list confirmed -> CSV exported -> Database created -> CSV imported -> Properties converted -> Verified

Never force a connected integration and never force automation. For a requested connected build, use available tools under the shared contract.

Step 5 - Build only on request

Once the user asks, emit only the pieces they requested, as data only. Keep prose outside machine-readable data; provide file links and material limitations separately. Every column name comes from the source module's field list, in the same order, in the CSV and in the mapping.

For a manual request, emit the requested files or mapping directly. For a live request, verify tools and destination, apply this mapping, and report only confirmed changes.

CSV

UTF-8, with a byte order mark so Excel opens the text correctly. The first row holds the exact field names. Do not add fake records.

Field 1,Field 2,Field 3

Example rows only when the user explicitly asked for them, and then obviously fake.

Property mapping

CSV cannot preserve Notion property types, so the mapping is always emitted separately, in this shape:

Use the actual confirmed fields, not this illustration.

Property type rules

Never map money to Text. Never map dates to Text unless the source explicitly requires it. A currency format is a format choice, never a currency assumption: do not pick the currency for the user.

Manual import steps

Give the shortest click-path that works. Notion's labels move between versions, so name the action and say the label may differ rather than claiming a button exists.

1. Use Notion’s CSV import action to create a database from the file.
2. Confirm the destination and imported column mapping; do not first create a duplicate database.
3. For an existing database, use its CSV merge/import action only when intended and check for duplicates.
4. Verify the properties below. For a header-only file that the importer rejects, create the properties manually instead of adding fake business records.

Check Notion’s import guidance for the current UI and supported relation mapping.

Property configuration order

After import, tell the user to convert properties in this order, and only the ones that exist:

Title
→ Dates
→ Numbers
→ Currency
→ Select fields
→ Status fields
→ IDs
→ Relations

Select options

For every select or multi_select field, list only the confirmed options, as suggestions the user adds after import. Do not invent statuses.

IDs

Preserve imported identifiers as Text. A Notion Unique ID is a separate generated property, not a replacement for external IDs or the required Title property. Use it only when requested, and never invent a prefix. Map exactly one suitable existing field to Title; if none is suitable, disclose the technical title field needed for Notion.