---

name: notion-manual-import description: 'Notion Manual Import: the Notion step for any module - CSV, property mapping, import steps and verification for the field list the active module confirmed. Use whenever the user picks Notion.' category: business risk: safe source: self source_type: self date_added: "2026-09-28" author: WHOISABHISHEKADHIKARI tags: [notion, csv, import, manual, operations, template, helper] tools: [] source_repo: WHOISABHISHEKADHIKARI/sme-ops-system-builder

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:

CSV column	Notion property	After import
Name	Title	Set as database title
Description	Text	Leave as Text
Status	Select	Convert to Select
Due Date	Date	Convert to Date
Amount	Number	Set number format
Notes	Text	Leave as Text

Use the actual confirmed fields, not this illustration.

Property type rules

Canonical type	Notion property
id	Text to preserve source IDs; separate Unique ID only if requested
title	Title
text	Text
long_text	Text
number	Number
currency	Number with currency format
percentage	Number; convert 0–100 to a fraction before percent formatting
date	Date
datetime	Date
checkbox	Checkbox
select	Select
multi_select	Multi-select
url	URL
email	Email
phone	Phone
person	Person
relation	Relation
files	Files

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.

Relations

A CSV import does not create a working relation. If a field is a relation:

1. import the base database first
2. import the related database
3. convert the field to Relation
4. select the target database
5. verify the linked records by hand

Never pretend a text column became a working relation automatically.

Calculations

Do not place business calculations inside the CSV unless explicitly requested. For a value such as Net Tax Payable, Days to Due, Balance, Variance or Total, decide first whether the source module defines it as an entered value, a formula, or something computed elsewhere, and preserve that. Never invent a formula. If the parent skill says a calculation belongs in accounting or tax software, that rule stands.

Output modes

The user asks for	Emit
the CSV	the CSV alone
the mapping	the mapping alone
instructions	the shortest useful manual setup steps
everything	CSV, mapping, options, import steps, verification checklist

Verification

After the import, ask the user to verify the database name, the field names, the property types, the date and currency formatting, the select and status options, the ID setup and the relations. The imported database is not verified until those match the source schema.

Field Reference

This skill has no Field Reference of its own, and it must not grow one. The active module's Field Reference is the single source: its CSV header, its SQL, its JSON Schema and its Notion mapping are the four artifacts, and this skill reformats the same field list for a manual import rather than defining a fifth.

If the source module's field list is not in front of you, read skills/<slug>/SKILL.md for the module in play. If it is missing or ambiguous, ask which database to prepare and stop - a header built from a guess imports as a wall of Text that the user then has to fix by hand.

See the Input Modules reference for the full guidance.

Select Options

Option lists belong to the source module, not to this skill. Emit them as a starting set to add after import, and never as a confirmed taxonomy. Where the user has supplied their own values, the user's values win.

Relations

Relations are configured after both databases exist, in the order above. In a manual import the target database has to exist first, so a relation column arrives as Text and is converted by hand. Say so rather than promising a working link.

Examples

Prompt

Notion is not connected. I want to build my tax register myself - what do I do?

Answered in one message, no intake needed - the module and the route were both named:

Read skills/tax-register/SKILL.md for the field list, then emit the header-only CSV, the
property mapping and the import steps.

Prompt

I already imported my tax register but every column came in as Text.

Mapping only - correction instructions, no rebuild:

Convert Tax Period Start and Tax Period End to Date, Tax Collected on Sales, Tax Paid on Purchases, Withholding Tax Deducted, Withholding Tax Paid to Us and Net Tax Payable to Number and set the currency format to the currency your business uses, Status and Tax Type to Select, and Tax ID to Unique ID with the prefix from the source schema. Leave Tax Period, Tax Filing Reference and Notes as Text.

Documented shape - a tax register field list, header-only CSV and mapping. The rows below are documentation examples only. Emit empty templates unless the user explicitly requests examples.

Tax Record,Tax Type,Tax Period,Tax Period Start,Tax Period End,Tax Collected on Sales,Tax Paid on Purchases,Withholding Tax Deducted,Withholding Tax Paid to Us,Net Tax Payable,Currency,Tax Filing Due Date,Filed Date,Payment Date,Tax Filing Reference,Prepared By,Reviewed By,Days to Due,Status,Notes,Tax ID

CSV column	Notion property	After import
Tax Record	Title	Use as database title
Tax Type	Select	Add confirmed tax types
Tax Period	Text	Leave as Text
Tax Period Start	Date	Convert to Date
Tax Period End	Date	Convert to Date
Tax Collected on Sales	Number	Set currency format
Tax Paid on Purchases	Number	Set currency format
Withholding Tax Deducted	Number	Set currency format
Withholding Tax Paid to Us	Number	Set currency format
Net Tax Payable	Number	Set currency format
Currency	Text	Leave as Text
Tax Filing Due Date	Date	Convert to Date
Filed Date	Date	Convert to Date
Payment Date	Date	Convert to Date
Tax Filing Reference	Text	Leave as Text
Prepared By	Text	Leave as Text
Reviewed By	Text	Leave as Text
Days to Due	Number	Convert to Number
Status	Select	Add confirmed statuses
Notes	Text	Leave as Text
Tax ID	Unique ID	Prefer automatic ID

See the Best Practices reference for the full guidance.

Limitations

• It formats another module's schema. It never decides the schema, and it does not create the database.
• Everything here is text. Nothing is uploaded, created, converted or connected by this skill, and no claim of a completed Notion action may be made on its behalf.
• Property names in the Notion UI change between versions. The click-path is described by action, and the user verifies the label.
• Relations, rollups, formulas, permissions and sharing are configured by hand afterwards.
• Select options are a starting set, not the business's confirmed taxonomy.
• A currency format is not a currency. The user names the currency.
• Legal, tax and payroll review is still required before the imported database drives real decisions.

See the Security & Safety Notes reference for the full guidance.