--- version: "2026.1.0" language: "en" --- # Await DOM Change and Await Requests in Fusion Blocks ## Overview Fusion blocks ([D365 F\&O](https://docs.leapwork.com/leapwork-flow/latest/working-with-leapwork/d365-fusion-recorder.md)and [Salesforce](https://docs.leapwork.com/leapwork-flow/latest/working-with-leapwork/salesforce-fusion-recorder.md)) now support **Await DOM Change** and **Await Requests** properties at the flow level. These settings help handle synchronization issues in dynamic web applications by waiting for the page to stabilize before executing the next Fusion action. ![image-20260630-110947.png](https://docs.leapwork.com/__attachments/a_f7fa5b7a3e497ed5e66f75845486e440d11afab8583e129a0eb1fc7085e2e8d6/image-20260630-110947.png?cb=51306e879b6cd9036ac64f8ae4fa7bad) ## What Each Setting Does ### Await DOM Change Waits for all DOM changes on the page to settle before proceeding. * Implemented using Chrome DevTools Protocol DOM events. * The extension subscribes to DOM mutation-related events and resets an idle timer whenever relevant DOM activity is detected. * If no relevant DOM changes occur for the configured timeout period, the DOM is treated as settled. * DOM changes within the recorder UI are ignored so that only changes in the target application affect page-idle detection. * If the DOM never settles, the wait eventually times out. ### Await Requests Waits for network activity to become idle before proceeding. * Implemented using Chrome DevTools Protocol network events. * The extension listens for browser network activity and tracks in-flight requests. This wait is limited to **Fetch and XHR request types** it does not represent all possible browser traffic. * The page is considered request-idle when there are no tracked in-flight requests for the configured idle timeout period. * If request activity never settles, the wait times out rather than waiting indefinitely. ![image-20260630-111059.png](https://docs.leapwork.com/__attachments/a_39c0887f76e8dcbaa8e44df68354ee5710cca72399b4adc4ed6719528e730c82/image-20260630-111059.png?cb=fa5d45d76b4109e6573936886b7f17f5) ## When to Use These Settings These settings are useful in scenarios where UI responsiveness depends on background processing. Examples include: * Buttons remaining temporarily disabled due to ongoing backend processing * Processing/loading overlays in Dynamics 365 Finance \& Operations * Delayed rendering of controls after page updates * Grid refreshes (e.g., while filtering) where no row selection takes place until data loads * Dialogs or forms that become interactive only after API/network completion * Cases where UI actions are attempted before the application becomes stable For **D365 F\&O specifically**, Await Requests will generally be the most useful option because asynchronous requests drive many UI state changes. ## How They Work in Fusion (Key Differences from Web Blocks) In Fusion space, Await Requests and Await DOM Change are handled inside the **Chromium extension layer**, not through the classic Web block await implementation. Key behaviors: 1. The await settings are passed when the browser session is started and stored by the extension for later use during Fusion block execution. 2. Before most Fusion actions are executed, the extension checks whether request waiting, DOM waiting, or both are enabled, and performs the relevant pre-execution wait. 3. **Default Timeout** controls the overall Fusion block execution budget. Await Requests and Await DOM Change control the idle-wait behavior **within** that budget. 4. The Default Timeout acts as a hard ceiling for the entire Fusion block execution. If the configured await timeout (Await Requests or Await DOM Change) is longer than the Default Timeout, the block will **fail when the Default Timeout expires**, regardless of whether the await condition has been satisfied. The await operation is cut short, it does not run to completion. 5. Await Requests and Await DOM Change have a **default max wait cap of 25 seconds** in the extension watcher layer. ### Web Blocks vs. Fusion Blocks Comparison | Behavior | Web Blocks | Fusion Blocks | |---------------------------------|-----------------------------------------------------------------------|------------------------------------------------| | Where await runs | Core engine (pre-execution step) | Chromium extension layer | | Relationship to Default Timeout | Separate await phase does not clip Default Timeout and can outlive it | Consumed from within Default Timeout budget | | Configuration level | Block-level supported | Flow-level only (applies to all Fusion blocks) | | Request types monitored | All network requests | Fetch and XHR only | | Await settings available | Block level | Flow level | ## Using Both Settings Together Both settings can be enabled simultaneously. When both are enabled: * The extension starts both watchers and waits until **both** conditions are satisfied request activity must become idle **and** DOM mutation activity must also become idle. This is useful in scenarios where: * Network requests complete, but UI continues rendering afterward * The UI keeps changing even after requests have finished ## Configuration Level Currently, Await Requests and Await DOM Change are supported **only at the flow level** in Fusion and apply globally to all Fusion blocks within the flow. ## Increasing the Maximum Timeout The default maximum timeout for both settings is **25 seconds**. This can be changed in the extension configuration files located at: * `C:\Program Files\Leapwork\Studio\HeadlessRecorder\Extensions\Chrome` * `C:\Program Files\Leapwork\Studio\HeadlessRecorder\Extensions\Edge` Configuration values (in `config.json`) are specified in seconds.: "awaitRequests": 5, "awaitDom": 5 If you increase `awaitRequests` or `awaitDom` to 30 seconds or more, increase the corresponding Default Timeout as well. Otherwise, the Fusion block may time out before the await operation completes. If these values are increased to 30 seconds or higher, the corresponding block timeout / default timeout should also be increased accordingly to avoid block timeout failures.