How can I combine sequential and concurrent work in one async function?

Make the dependencies visible in the order of the code: await setup first; start the independent requests together; await both results; then do the save. Only the middle operations run concurrently, and only if neither needs the other's result. Microsoft’s Azure Functions guidance recommends Promise.all() for independent asynchronous operations and illustrates awaiting prerequisite data before starting operations that use it [S1].

Here’s a plain JavaScript example. Assume the functions shown already exist and return promises; their implementations and failure policy depend on your app:

async function buildReport(accountId) {
  try {
    // Sequential prerequisite: later work needs this account data.
    const account = await loadAccount(accountId);

    // Both tasks use account, but neither uses the other's result.
    const [orders, preferences] = await Promise.all([
      loadOrders(account.id),
      loadPreferences(account.id),
    ]);

    // Dependent completion: needs both concurrent results.
    return await saveReport({ account, orders, preferences });
  } catch (error) {
    // Handle here, or rethrow for the caller to handle.
    throw error;
  }
}

The try/catch marks one possible boundary, not a required policy. Replace the rethrow with the handling your app needs, or let the caller own the catch. Use Promise.all() here because the middle tasks are independent; it does not make dependent tasks safe to run together [S1].

Ask whether either operation needs the other’s output, or whether their order changes the result. If one needs the other’s result, keep that dependency sequential. If both only need the completed setup value and can proceed without coordinating, they are candidates for the concurrent group.

For example, loading orders and loading preferences both use account.id; neither receives the other’s result. But if preferences must use a value returned by the orders request, await the orders first, then start the preferences request. A simple dependency sketch helps: account → orders and account → preferences can branch; orders → preferences means there is another dependency to respect.

Choose deliberately what the workflow should do when a task in the group fails: fail the overall operation, report an error, or use a different strategy if partial results are acceptable. Microsoft recommends proper error handling but does not prescribe one universal failure policy [S1].

A failure does not automatically cancel sibling work. Cancellation is relevant only when the operations accept and honor an abort signal. The Azure SDK documentation describes passing such a signal to supported operations and aborting later; it does not claim that a failure automatically cancels other tasks [S2]. If your functions do not support cancellation, handle the group’s failure without assuming the other operation has stopped.

Put the catch where you have enough context to make the intended decision. If this function should handle the failure locally, perform that handling in its catch. If the caller should decide what happens, rethrow the error, as in the example. Avoid catching an error only to ignore it; make the chosen boundary clear to whoever calls the function.

The example uses a catch around the whole workflow, so it covers setup, the concurrent group, and the final save. You could instead put handling around a narrower step if only that step has a distinct policy. Whatever boundary you choose, keep the prerequisite, independent group, and dependent completion in their dependency order.