> For the complete documentation index, see [llms.txt](https://developer.emporix.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.emporix.io/document-intake-cockpit/document-intake-process.md).

# Document Intake Process

See how email attachments and direct uploads can become documents of configured types for review in the Document Intake Cockpit.

An attachment from email or direct upload can become a document for review. The Document Intake Cockpit provides the configuration and review workspace for the parts of the flow that your tenant enables.

Email intake requires a mailbox and a value stream set up outside the cockpit. The value stream receives mailbox events and stores inbox items. Direct upload does not need this email setup. In the cockpit, define document types in [Document Configuration](/document-intake-cockpit/configuration/document-configuration.md) and email categories and routing in [Email Configuration](/document-intake-cockpit/configuration/email-configuration.md). Matching, rules, layouts, and lifecycle settings determine how document processing works after intake.

## Main flow

```mermaid
---
config:
  theme: base
  look: classic
  themeVariables:
    background: transparent
    lineColor: "#9CBBE3"
    arrowheadColor: "#9CBBE3"
    edgeLabelBackground: "#FFC128"
    edgeLabelTextColor: "#4C5359"
---
flowchart TB
    A("Receive an email")
    B("Upload documents directly")
    C("Store the inbox item and attachments")
    D("Process each attachment")
    E{"Was a document created?"}
    F("Create and link the document")
    G("Show "No draft"")
    H("Show "Failed"")
    I("Retry attachment processing")
    J("Categorize and route the inbox item")
    K("Run enabled downstream automation")
    L("Review the document in the cockpit")

    A --> C
    B --> C
    C --> D
    D --> E
    E -->|Yes| F
    E -->|No document created| G
    E -->|Processing error| H
    G -->|Retry| I
    H -->|Retry| I
    F --> J
    G --> J
    F --> K
    K --> L

    classDef process fill:#F2F6FA,stroke:#4C5359,stroke-width:1px
    classDef decision fill:#A1BDDC,stroke:#4C5359,stroke-width:1px
    classDef outcome fill:#DDE6EE,stroke:#4C5359,stroke-width:1px

    class A,B,L outcome
    class C,D,F,G,H,I,J,K process
    class E decision
```

Documents can enter the process through a configured email mailbox or by direct upload. Each accepted inbound email creates an inbox item. A direct-upload batch creates one inbox item for all successfully uploaded attachments and opens it in **Email Detail**.

Each attachment is evaluated separately. Intake extracts values and determines whether to create a document of a configured type. When it creates one, the cockpit links it to the inbox item. The processing outcome for each attachment updates automatically. If processing does not create a document or ends with an error, you can run another attempt. A linked document opens it for review.

For a created document, the extracted values determine the applicable [document type and sub-type](/document-intake-cockpit/configuration/document-configuration.md). These, in turn, define the [form layout](/document-intake-cockpit/configuration/form-layouts.md), [Auto Matching](/document-intake-cockpit/configuration/auto-matching.md), and [Business Rules](/document-intake-cockpit/configuration/business-rules.md). Once the document is classified, the configured matching, rules, [lifecycle transitions](/document-intake-cockpit/configuration/state-transition.md), and other downstream automation can run. The capabilities that are enabled and the order in which they run depend on the tenant configuration.

Email classification is separate from document creation. After an attachment reaches a completed **Draft created** or **No draft** outcome, configured classification can categorize and route the inbox item. With multiple attachments, each completed attachment can start classification. A later classification can override the category and folder assigned by an earlier classification. As a result, the values displayed on the inbox item are determined by the last classification to complete. A failed attachment does not, by itself, trigger this classification step.

## Attachment outcomes

Open the inbox item in [Email Inbox](/document-intake-cockpit/cockpit-views/email-inbox.md) and use the status shown for each attachment:

* **Processing** – Processing continues, and **Email Detail** refreshes the result automatically.
* **Draft created** or the document's configured workflow status, such as **Start** – The linked document below the attachment list opens the document for review.
* **No draft** – Processing completed without creating a document. Displayed reasoning remains until you retry after the underlying cause changes, for example, after an administrator updates the document configuration.
* **Failed** – Processing did not complete. **Retry** runs the attachment again.

If **No draft** or **Failed** appears again after a retry, report the filename and any displayed reasoning to your tenant administrator. The administrator can use this information to check the document configuration and the external orchestration before you retry again.

## Document lifecycle

Open a document from a document-type list under **Documents**, a configured queue, or a linked document on an inbox item. In [Managing Documents](/document-intake-cockpit/cockpit-views/managing-a-document.md), compare the source file with extracted values and use the actions configured for that document.

### Transform document

Use **Transform document** when the action is available and the document was created with the wrong type. It creates a replacement of the target type.

{% stepper %}
{% step %}

#### Transform the document

Save your corrections before transforming because the action uses the current saved values. After you select a target type, it creates a replacement by mapping the saved type-specific values, including nested fields and line items, to fields in the target schema. AI determines the mapping, so not every field necessarily carries over. The replacement keeps the source attachment and email reference.
{% endstep %}

{% step %}

#### Review the replacement

The cockpit opens the replacement with the initial status `START`. Transformation resets the assignee, histories, validation, matching, approval results, and other processing metadata. It attempts to update the email link before removing the original document. If original-document cleanup fails, both documents remain. If the email-link update fails, transformation can still complete, but the inbox link might remain stale. Report either outcome to your tenant administrator.

Review the mapped fields in the replacement, then use its configured actions to continue processing.
{% endstep %}
{% endstepper %}

Transformation does not rerun the original parsing, Auto Matching, Business Rules, validation, state transitions, or approval, and it does not advance the replacement from `START` on its own. If no configured action starts the processing your workflow requires, contact your tenant administrator. Any later automation depends on tenant-specific external orchestration.

{% hint style="info" %}
See the [Order Intake Example](/document-intake-cockpit/configuration-examples/order-intake.md) for a worked tenant configuration in this cockpit.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://developer.emporix.io/document-intake-cockpit/document-intake-process.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.