Most people default to processing records one by one.

Picture this: 50 Inspection Assignment records need to be posted to an external API — one call per assignment.

⏳ Inspection Assignment 1 → API → wait → Assignment 2 → API → wait → ...

It works. But it's slow, and it doesn't scale.

⚡ A simpler pattern: ODC Events

Submit → Loop through records → Fire an Event per record → Don't wait

Each Event independently:

• 📥 Fetches the Inspection Assignment data
• 🌐 Calls the external API
• 📨 Captures the response
• ✅ Stores success/failure status

The Submit action doesn't wait. Multiple assignments process concurrently, each through its own independent event execution.

Once done, the app aggregates the outcome:

📊 Total: 50 · ✅ Successful: 47 · ❌ Failed: 3

Why this matters: for any ODC app pushing a batch of records through an external API, this event-driven pattern trades a slow sequential wait for fast, asynchronous processing.

⚠️ But it's not free — a few trade-offs to know

• 🚦 Rate limits — 50 simultaneous calls can get you throttled (429s) by the external API faster than you'd expect
• 🔁 Duplicate submissions — a retried or re-triggered event can resubmit the same Inspection Assignment twice if you don't guard for it
• 🕵️ Harder to debug — failures happen in isolated, parallel executions, not one linear trace — you need solid logging to see what went wrong and where
• 🗄️ Database contention — many events writing status at once can cause lock contention if updates aren't scoped tightly
• 🧮 No built-in "all done" signal — nothing tells you automatically when every assignment has finished; you have to build that check yourself
• 🎛️ Concurrency isn't unlimited — the ODC runtime and the external API both cap how much can truly run at once