RapidStart async import and Processing Order

When importing configuration data with RapidStart, the way Business Central applies the package depends on how many rows it contains. This matters for any implementation that relies on tables being applied in a specific order.

Async processing behaviour

• Packages/tables with more than five rows can switch to asynchronous processing. For small data sets Business Central applies the data synchronously, but once a table has more than five rows the apply step can run asynchronously.
• Async processing ignores Processing Order. The Processing Order you set on the package is honoured only for synchronous apply. When the data is applied asynchronously, tables are processed in parallel and the configured Processing Order is not respected.

Troubleshooting note for order-dependent imports

If your implementation depends on tables being applied in a specific sequence — for example, when one table must exist before another can reference it — do not assume Processing Order guarantees that sequence. With more than five rows, the apply can go async and ignore the order, producing errors or missing references that look intermittent.

To keep a strict order:

• apply the order-dependent tables in separate, smaller packages, or
• import and apply them one table at a time, confirming each is applied before the next.

Note: If an import that “worked before” starts failing after the data grew, suspect the async switch: a package that stayed synchronous while small may have crossed the row threshold and started ignoring Processing Order.