| Flow triggered by a platform event |
- Simple to implement
- Asynchronous transaction separate from order creation improves
performance
|
- No parallel execution; orders processed one at a time
- No control of timing
- Asynchronous execution requires complex error handling
|
| Flow triggered by a record change (Order Status: Draft → Activated) |
- Simple to implement
- Allows a multithreaded approach for creating order summaries in parallel with
orders
- A Composite API call can create an order and order summary in the same
transaction, allowing simpler error handling; for example:
- Create the Order record and set its Status to
Draft.
- Create the supporting records, such as order items and order delivery
groups.
- Change the order’s Status to Activated. That
triggers the Create Order Summary flow to run on that order.
|
- When the order and order summary are created in the same transaction, and the
order summary fails, the order also fails
- Large transactions
- Lowest performance method
|
| Apex triggered by a platform event |
- Asynchronous transaction separate from order creation improves
performance
- Allows a multithreaded approach for creating order summaries in parallel with
orders
- Best performance method
|
- No control of timing
- Asynchronous execution requires complex error handling
|
| Scheduled Apex job |
- Allows controlled batch execution
|
- Subject to Apex limits on the number of records processed
- Requires programmatic identification of the orders to process
- Runs even when no orders need processing
|
| Direct calls to API resources |
- Allows external control
- Some clients allow parallel processing
|
- Subject to API call limits
- Requires external app design, authentication, and so on
|
j