Capture-first imports

Most import tools start with a spreadsheet and ask users to make the columns fit your system. Mildport is designed for a broader reality: customers also have PDFs, photos, scanned forms, meeting notes, copied emails, and other messy inputs.

The capture-first model keeps those inputs understandable and safe:

Capture → Understand → Verify → Apply

Your product decides what can be created. Mildport helps identify useful facts, proposes records, and asks the user to confirm before anything is applied.

The simple idea

Imagine a customer uploads a meeting note:

Met Anna Müller from ACME.
She wants a valuation next week.
Call her Friday.
Budget around 850k.

An ideal import experience should not force this into one spreadsheet row immediately. It should first ask what the note contains.

Mildport can present a reviewed plan:

• Contact — Anna Müller
• Organization — ACME
• Lead — valuation request
• Task — call Friday

The user can confirm, remove, edit, or add records before the result reaches your CRM, ERP, property system, or internal tool.

Your product defines the targets

Mildport does not globally hardcode record types such as “Lead” or “Contact.” The host application provides the catalog of things that make sense in that product, tenant, or workflow.

For example, a CRM might expose:

targets: [
  {
    id: 'contact',
    label: 'Contact',
    fields: [
      /* your fields */
    ],
  },
  {
    id: 'organization',
    label: 'Organization',
    fields: [
      /* your fields */
    ],
  },
  {
    id: 'lead',
    label: 'Lead',
    fields: [
      /* your fields */
    ],
  },
  {
    id: 'task',
    label: 'Task',
    fields: [
      /* your fields */
    ],
  },
];

A property platform, finance tool, or field-service app can expose a different catalog. The workflow stays the same, but the target records are yours.

Declare fields once on targets

Pass rich target fields — types, validators, and matcher aliases live on each field. Mildport derives the internal column schema automatically:

targets: [
  {
    id: 'contact',
    label: 'Contact',
    fields: [
      {
        key: 'contact.email',
        label: 'Email',
        columnType: 'email',
        required: true,
        alternativeMatches: ['e-mail'],
      },
      { key: 'contact.name', label: 'Name' },
    ],
  },
];

Spreadsheet imports use the same catalog — often with one target for a single record type, or several targets when a file maps to multiple entities.

Recommended: mountImportFlow()

TypeScript hosts can bundle targets, upload flags, apply mode, and mapping memory:

import { mountImportFlow } from '@capitality-io/import-suite-ng';

mountImportFlow(
  mildportElement,
  {
    id: 'crm-meeting-note',
    version: 'v1',
    targets: [
      {
        id: 'contact',
        label: 'Contact',
        fields: [
          { key: 'contact.email', label: 'Email', columnType: 'email', required: true },
          { key: 'contact.name', label: 'Name' },
        ],
      },
    ],
    input: { acceptedFormats: ['pdf', 'image', 'text'], pdfImportMode: 'fact-map' },
    delivery: { mode: 'webhook' },
  },
  { cleaningHook: myCleaningHook },
);

The helper applies targets, hostConfig flags, applyMode, and mappingIdentifier (id@version). Non-serializable hooks merge via the third argument.

Neutral facts come before field mapping

Before anything is mapped to your schema, Mildport works with a neutral fact layer.

Neutral facts are portable observations from the input:

• a name;
• an email address;
• a phone number;
• a company name;
• an amount;
• a date;
• a task-like instruction;
• a document reference.

They are not yet CRM fields. That separation matters because the same fact can be useful in many products.

For example:

facts: [
  {
    kind: 'person.name',
    value: 'Anna Müller',
    confidence: 0.91,
    evidence: 'Met Anna Müller from ACME',
  },
  {
    kind: 'organization.name',
    value: 'ACME',
    confidence: 0.88,
    evidence: 'from ACME',
  },
  {
    kind: 'task.intent',
    value: 'Call Friday',
    confidence: 0.74,
    evidence: 'Call her Friday',
  },
];

In the product UI, this becomes easier to read:

We found possible facts

Name: Anna Müller
Company: ACME
Next action: Call Friday
Budget: 850k

From facts to proposed records

Once neutral facts exist, Mildport can compare them to the host target catalog and propose records:

We found possible records

[x] Contact
    Anna Müller
    Evidence: "Met Anna Müller from ACME"

[x] Organization
    ACME
    Evidence: "from ACME"

[x] Lead
    Valuation request
    Evidence: "wants a valuation next week"

[x] Task
    Call Friday
    Evidence: "Call her Friday"

For mixed documents, the result can be a small graph instead of a single flat row:

Organization: ACME
Contact: Anna Müller → belongs to ACME
Lead: Valuation request → linked to Anna Müller and ACME
Task: Call Friday → linked to the lead

The user remains in control. Mildport proposes; the operator confirms.

Confidence without a black box

Confidence is not a promise that the system is always right. It is a signal that helps decide what needs review.

Mildport can combine signals such as:

• whether the text was clearly readable;
• whether the value matches an expected pattern, such as an email or amount;
• whether the value is grounded in visible source evidence;
• whether rules and optional AI assistance agree;
• whether a human has confirmed the value.

Customer-facing behavior should stay simple:

• high-confidence facts can be presented first;
• uncertain facts are marked for review;
• critical values such as names, dates, amounts, addresses, and handwritten text require human confirmation before apply.

Optional AI assist

Mildport is deterministic by default. Optional AI assist can help in three levels:

1. Rules only — identify obvious facts such as emails, phone numbers, dates, and table headers.
2. Rules + AI judge — rules make candidates; AI helps label ambiguous facts or suggest record relationships, with human review.
3. Full AI assist — AI proposes a fuller record plan for messy notes, photos, emails, or voice transcripts. This is the most flexible mode and should be reviewed carefully.

The safest default for most customers is rules + AI judge: deterministic extraction remains the floor, and AI is used where interpretation helps.

Handwriting and low-quality scans

Handwritten input and poor-quality photos should be treated as lower-trust by default.

In a good capture workflow, Mildport should:

• attempt to read the text;
• show the original evidence near the extracted value;
• mark uncertain values as needing review;
• avoid applying critical handwritten fields automatically;
• let the user correct the value quickly.

The goal is not to pretend handwriting is perfect. The goal is to make it faster and safer for a human to turn real-world information into clean system data.

What the user sees

The ideal user experience is direct:

1. Capture
   Upload a file, take a photo, paste text, or provide a note.

2. Understand
   Mildport shows useful facts it found.

3. Propose
   Mildport suggests records based on your target catalog.

4. Verify
   The user confirms, edits, removes, or adds records.

5. Apply
   Approved records are delivered to your product.

Why this matters

Capture-first imports make Mildport useful beyond traditional spreadsheet import:

• a sales team can turn meeting notes into contacts, leads, and follow-up tasks;
• a field team can turn a photo into a task or expense draft;
• a property team can turn a scanned document into reviewed property or invoice fields;
• an operations team can turn pasted emails or PDFs into structured records.

The important boundary stays the same: Mildport prepares and explains; your users approve; your product receives the final records.

Next

• How it works — the core upload-to-apply flow.
• Configure the widget — how hosts provide schemas and behavior.
• AI transparency — how optional AI assist is controlled.