Transactions

Transactions represent a batch of documents uploaded for processing. They are the primary unit of work in DocAI Fabric.

Transaction Lifecycle

Created → Queued → Processing → Completed / Failed
                       ↕
                 Awaiting input

1. Created: Transaction exists and documents can be uploaded to it
2. Queued: Processing has been requested and a worker will pick it up
3. Processing: The workflow engine is running activities on the documents
4. Awaiting input: The workflow is paused for something outside itself, most often a human review step
5. Completed: The workflow reached its end
6. Failed: An activity failed and the workflow could not continue

Creating a Transaction

Via the UI

1. Open a project
2. Click New Transaction
3. Upload files using drag-and-drop or the file picker
4. (Optional) If a single file is selected, enable Limit Pages and set the number of pages to process
5. Click Process to start the workflow

Other ways to start

The same dialog offers two alternatives to uploading from your computer. Capture with phone shows a QR code that opens the camera on your phone and sends the photos straight into a new transaction. Copy from another dataset brings transactions that already exist elsewhere in the project (Playground, Work Queue, Memory, or an evaluation dataset) into the one you are working in. Copying is available on Playground, Memory, and Evaluation.

Naming

If your project calls its transactions something else, set Item name in project settings. The button then reads New Invoice, New Port Call, and so on, throughout the app.

Page Limit

When uploading a single file, you can choose to process only the first N pages. The full file is always stored; only the conversion step is limited. This is useful for previewing large documents or testing workflow settings.

Uploading an email

You can drop a saved email onto the same dialog: .eml (most mail clients, and Save as in Outlook on the web) or .msg (dragged out of Outlook for Windows). An email is not treated as a single document. It is opened into the transaction it describes:

What arrives	What it becomes
The message body	The first document, laid out as a PDF with a printed header showing From, Received, To, Cc, Subject and the attachment list
Attachments in a supported format (PDF, TIFF, PNG, JPEG, HEIC)	The remaining documents, in the order they were attached
Sender, recipients, subject, received time, importance	Transaction metadata, available as email_* columns and as field values
The original message file	Kept with the transaction, never processed

Attachments in other formats are ignored, and images embedded in the body (signatures, logos) stay part of the body rather than becoming documents of their own.

Each email always creates its own transaction, even with Upload each file as a separate transaction switched off, because the sender and subject belong to one message. You can drop several emails at once, and mix them with ordinary files: every email gets a transaction, and the other files follow the switch.

This is the same result you get from an email import connector, so it is a good way to try a mailbox's typical message before setting one up.

Using email details in fields

Because the envelope lands in transaction metadata, an extraction field can be filled from it instead of from the page. Set the field's value source to Transaction metadata and pick a key such as email_from or email_received_at.

Via the API

The quickest route is the one-step endpoint, which creates the transaction and starts processing in a single call:

curl -X POST "https://app.docaifabric.com/tenants/{tenant_id}/projects/{project_id}/transactions/process" \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"source_files": [{"filename": "invoice.pdf", "base64_data": "JVBERi0xLjQK..."}]}'

For several files, or to set options before processing starts, create the transaction first and upload to it, then start it. Process Documents via API is the full reference for both routes, including the fields each one takes.

An email file is uploaded the same way and is expanded server-side, exactly as it is in the dialog. Because one file in becomes several out, send it on its own to an empty transaction; the response lists the resulting documents and echoes expanded_from.

curl -X POST "https://app.docaifabric.com/transactions/{transaction_id}/source-files" \
  -H "X-API-Key: your-api-key" \
  -F "files=@invoice_email.eml"

Transaction Contents

Each transaction contains:

Component	Description
Documents	Individual documents detected after splitting
Pages	Individual pages with OCR text and images
Workflow State	Current processing status per activity
Source Files	Original uploaded files

Viewing Results

In the transaction detail view, you can:

• Browse documents: See all documents detected in the upload
• View extractions: See extracted field values with confidence scores
• Inspect pages: View page images with bounding boxes around extracted data
• Check classification: See how each document was classified
• Review & correct: Manually fix any extraction errors

Transaction States

These are the values the API reports in a transaction's status field:

State	Description
created	Created, awaiting files or a start request
queued	Waiting for a worker to pick it up
processing	Actively running the workflow
awaiting_input	Paused for external input, typically human review
completed	All processing finished
failed	An activity failed; the response carries error_message

Individual workflow steps have their own statuses, which are shown in the transaction's Activity Log and are not the same list.

Bulk Operations

You can process multiple transactions at once:

1. Select transactions in the project view
2. Use the bulk action menu to:
   • Process selected transactions
   • Reprocess failed transactions
   • Delete selected transactions

Copying selected transactions to another dataset

The same toolbar can copy the selected transactions into another dataset, so you can take real work and reuse it in design time. Every page offers the destinations it is not itself: Add to Playground (a sandbox copy you can re-run freely), Add to Memory (teach the system from these transactions), and Add to Evaluation (use them as reference data for accuracy testing).

Copying from My Work Queue into Playground or Evaluation requires permission to copy production work into design time, and Add to Memory appears only for users the system is allowed to learn from. When you add work-queue transactions to Memory, they become part of your live production memory right away, not a draft waiting to be published.

The toolbar keeps each page's own actions first (Assign and Priority on My Work Queue, Re-run on Evaluation, Revert on Memory) and groups the copy actions after a divider. On a narrow window the copy actions move into a ... menu so the page's own actions keep their space.