Async OnSave – Processing overlay hides dialog

(0) Share

Report

Posted on by CU11090513-0

I'm using Async OnSave on the Email form. When Email Send (saveMode === 7) is triggered, I want to display a dialog and wait for user input.

The handler follows Microsoft's documented async OnSave pattern:

eventArgs.disableAsyncTimeout();

const result = await Xrm.Navigation.openConfirmDialog({
    title: "Test Dialog",
    text: "Test"
});

if (!result.confirmed) {
    eventArgs.preventDefault();
}

The async behavior works and Dynamics waits for the dialog. However, the native Processing... overlay appears above the dialog, making the dialog impossible to interact with.

We originally used a custom page with:

await Xrm.Navigation.navigateTo(...);

and saw the same behavior. We then tested Xrm.Navigation.openConfirmDialog() to rule out a custom-page issue, but the Processing overlay still appears above it.

Async OnSave is enabled, the registered OnSave handler returns the Promise, and disableAsyncTimeout() is called before the first await.

This occurs when sending an Email from the Timeline using the standard Send action.

Is there a supported way to either hide the native Processing overlay while awaiting the dialog, or ensure the dialog is rendered above it?

Categories:

Building Power Apps

Power Apps Pro Dev & ISV

All responses (3)

Answers (0)

Sort by

Suggested answer

M Bilal Khan 384 on at

Like
a
(0)

Report
Copy link

Link copied!
Hi @CU11090513-0,
Good troubleshooting on your part — ruling out the custom page by falling back to openConfirmDialog() was the right move, and it tells us this isn't a rendering issue with your dialog. The native Processing... overlay sits in its own stacking context above the form, and in the Timeline's "Send Email" flow specifically (saveMode === 7), that overlay appears to get a higher z-index than dialogs opened via Xrm.Navigation while the async OnSave promise is still pending. This is a known layering gap in the Unified Interface — the overlay was really designed to just show "please wait" while nothing is waiting on the user, and Email Send from the Timeline doesn't seem to have been tested with a blocking dialog in the mix. I haven't seen a supported client-side way to change the overlay's z-index or suppress it, since it's platform-owned chrome, not a customizable web resource.

A few things worth trying:

Confirm it's isolated to the Timeline Send action. Try triggering the same OnSave logic from a normal Save button click (not via Send Email) — if the overlay doesn't cover the dialog there, that confirms the bug is specific to the Send pipeline, which is useful ammo for a support case.

2. Sidestep the async-overlay window entirely. Instead of awaiting the dialog inside OnSave while the overlay is showing, try: call eventArgs.preventDefault() immediately (synchronously, no async needed) to stop the Send from proceeding at all, show your dialog after that (outside the save pipeline, so no overlay is present), and then, if confirmed, manually trigger the save yourself (e.g., formContext.data.save() or re-invoke the Send action) instead of letting the original Save button call go through. This keeps your dialog interaction completely outside the window where the Processing overlay exists.

3. Consider a ribbon-level intercept instead of OnSave. If the Send button is customizable via the command bar, you could add a JavaScript function tied to the command's Action/JavaScriptFunction that shows your confirmation dialog before invoking the actual Send, rather than hooking into OnSave at all. This avoids Async OnSave and its overlay entirely.

4. File it as a bug. Since this reproduces with the documented, unmodified openConfirmDialog() pattern and isn't something you can fix from your own code, it's worth opening a support ticket or a bug report through the admin center / Power Platform support channels — overlay stacking issues like this usually need an actual platform fix, and Microsoft can't prioritize what they don't know is broken.

If you get a chance to test #1, post back — knowing whether it's Send-specific or affects all async-OnSave dialogs will help anyone else hitting this.
Suggested answer

11manish 4,819 Super User 2026 Season 2 on at

Like
a
(0)

Report
Copy link

Link copied!

Do not try to fix this with CSS, DOM manipulation, z-index changes, or different dialog APIs. Your testing with both openConfirmDialog() and navigateTo() already demonstrates that the common problem is the native Email Send processing overlay.

The documented Async OnSave mechanism supports waiting for user input, but Microsoft does not provide a supported API to hide or reorder the native Processing overlay. Therefore, for an interactive confirmation, move the confirmation before the standard Send operation, preferably through a custom Send command. If the standard Send button must be retained, this should be reported to Microsoft as a Dynamics 365 Email Send + Async OnSave UI limitation/bug.
Suggested answer

Mohsin Ali 1,111 on at

Like
a
(0)

Report
Copy link

Link copied!
Hello @CU11090513-0 - In your current logic, two different promises are conflicting because of which you are seeing overlay.

To the best of my experience, I would suggest that whenever an Email is sent, the form gets refreshed once, so I would recommend adding your logic at onLoad Event. First check email status, if it is marked as sent then you should trigger your logic. Adding sample code for reference.

async function emailOnLoad(executionContext) { try { const formContext = executionContext.getFormContext(); const statusAttribute = formContext.getAttribute("statuscode"); if (!statusAttribute) { return; } const statusCode = statusAttribute.getValue(); // Email Status Reason: Sent // Verify the option value in your environment. const SENT_STATUS = 3; if (statusCode === SENT_STATUS) { const result = await Xrm.Navigation.openConfirmDialog({ title: "Email Sent", text: "This email has already been sent. Do you want to continue?" }); if (result.confirmed) { // Perform your required action here console.log("User confirmed"); } else { console.log("User cancelled"); } } } catch (error) { var alertStrings = { confirmButtonLabel: "ok", text: error.message, title: "Exception" }; var alertOptions = { height: 120, width: 260 }; Xrm.Navigation.openAlertDialog(alertStrings, alertOptions).then( function (success) { console.log("Alert dialog closed"); }, function (error) { console.log(error.message); } ); } }