Skip to main content
Dooap Studio
Browse all guides
All guides

Multi-Action Flow with OCR

Split OCR extraction and downstream processing into separate Actions so each can be reused, tested, and maintained independently.

When to Use This Pattern

  • You want one Action to handle OCR and another to process the extracted text.
  • Multiple downstream Actions need the same OCR output (e.g., different validation or extraction pipelines).
  • You want to keep Actions focused on a single responsibility.

Overview

Action A                          Action B
┌───────────────────┐             ┌───────────────────┐
│  OCR Step         │             │  Load_OCR_Output  │
│  (stores output)  │             │  (loaded auto.)   │
│         ↓         │  triggers   │         ↓         │
│  Trigger Action ──┼────────────→│  LLM / Agent Step │
│  Step             │             │  (uses OCR text)  │
└───────────────────┘             └───────────────────┘

Action A performs OCR and stores the result. A Trigger Action step fires Action B, which loads the OCR output automatically and feeds it to an LLM or Agent step.

Step 1 — Create the OCR Action (Action A)

  1. Create a new Action (or open an existing one).
  2. Add an OCR Step and select an OCR model.
  3. Check "Store OCR output for triggered actions" on the OCR step.
  4. Add a Trigger Action step after the OCR step and point it at the Action you want to trigger (Action B).

The checkbox tells Studio to store the OCR text so it can be retrieved by any Action triggered in the same chain.

Step 2 — Create the Processing Action (Action B)

  1. Create a new Action.
  2. On the step that needs the OCR data, add the Load_OCR_Output input.
  3. No configuration is needed — the input resolves the identifier automatically when the Action is triggered from a chain that stored OCR output.
  4. Optionally fill in fallbackValue (for example OCR result not available) if this Action may also run without stored OCR output. See When the OCR Output May Be Missing.
  5. Use the loaded OCR text in your prompt or agent instructions. The OCR data is available as input context for the step.

How It Works Under the Hood

When the OCR step stores its output, it writes it under two keys: a unique identifier for that specific OCR execution, and the root trace ID shared by the whole Action chain. The unique identifier is recorded in the run as __OcrOutputIdentifier, and the Trigger Action step forwards it (together with __RootTraceId) to the triggered Action. The Load_OCR_Output input looks up the unique identifier first and falls back to {{inputs.__RootTraceId}} — no manual identifier needed.

The unique identifier matters when several runs share one root trace. For example, when Action A loops over the attachments of an email and triggers Action B once per attachment, every Action B run has the same root trace ID. Because each OCR execution also stores under its own identifier, each Action B run loads the OCR output for its own document instead of the output of whichever sibling run finished last. The same applies to loop rounds within a single Action: Load_OCR_Output always resolves the OCR step that ran most recently in that run.

This also works in deeper chains. If Action B triggers Action C, and Action C has Load_OCR_Output, it receives the same identifier that Action B received (or produced), and still falls back to the root trace ID from Action A.

When the OCR Output May Be Missing

By default, Load_OCR_Output fails the step when no stored OCR output can be found — for example when the Action is started manually, is triggered from an Action that has no OCR step, or the stored output has expired. The run then stops with an error that asks you to verify the source OCR step and its Store for triggered actions setting.

If missing OCR output is a normal situation for your Action, set the fallbackValue parameter on the Load_OCR_Output input. When no OCR output is available, the input then succeeds and returns the fallback text as the OCR result instead of failing:

  • ocrResult contains the fallback text (for example OCR result not available), so prompts and {{inputs.Load_OCR_Output.ocrResult}} references keep working.
  • ocrOutputAvailable is false (it is true when real OCR output was loaded), so a Switch step or an Agent can tell the two cases apart.
  • identifier is empty.

The fallback also applies when a custom identifier template cannot be resolved (for example {{inputs.dooapEventPayload.dooapInvoiceId}} in a run that has no Dooap event payload). It does not hide infrastructure errors such as storage being unavailable — those still fail the step. The fallback text may itself contain {{...}} references.

Leave fallbackValue empty when the OCR output is required: a missing output should then stop the run rather than let an LLM step continue without the document.

Testing and Reprocessing the Chain

  • Manual runs use drafts throughout — Run Action A manually and both Action A and the triggered Action B execute their latest saved drafts. You do not need to publish either Action to test the full flow. Automatic triggers keep using published versions.
  • Reprocessing Action B reuses the stored OCR — When you reprocess a run of Action B from the run history, Studio remembers the OCR output identifier and the root trace of the original chain. Load_OCR_Output first looks for the exact OCR output the original run used, then under the reprocessed run's own trace, and finally falls back to the original chain's root trace, so Action A does not have to run again. This works for single and mass reprocessing, and for repeated reprocessing of the same run.

Things to Know

  • 7-day retention — Stored OCR outputs expire after 7 days. Re-run the OCR Action if needed; reprocessing a downstream run after that also requires re-running the OCR Action.
  • Same-action usage — Within the same Action, reference OCR output directly via step outputs (e.g., {{StepName.ocrResult}}). The Store checkbox and Load_OCR_Output are only needed across Actions.
  • Custom identifiers — For advanced scenarios (e.g., keying by invoice ID), you can still set a custom identifier via the Raw Configuration on the OCR step and the identifier parameter of the Load_OCR_Output input.
  • Optional OCR output — Set the fallbackValue parameter when the Action may run without stored OCR output; see When the OCR Output May Be Missing.