Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Resume Workflows in Waiting State Due to a Deactivated User License

Audience: System Administrators, Support Engineers

Overview

In Dynamics 365, background workflows (classic/async processes) will not run if the workflow owner is disabled or their Microsoft 365 license is removed/expired. Any in-flight jobs owned by that user move into Waiting and remain paused indefinitely.

Recommendation: Assign all Work 365 workflows to a dedicated Service Account or Application User to prevent interruptions.

This guide covers how to (1) reassign workflow ownership and (2) safely resume or recover waiting jobs.

Prerequisites

  • System Administrator (or equivalent) privileges in Dynamics 365.

  • Access to Microsoft 365 Admin Center (if temporarily re-licensing a user).

  • The target Service Account or Application User exists and is enabled.

Step 1 — Reassign the Workflow Owner to a Service Account

  1. Go to Settings → Processes
    (or Advanced Settings → Customizations → Processes).

  2. Locate the affected workflow(s), e.g., Work 365 Start Job, Work 365 Invoice Job.

  3. Open the workflow record → Command bar → Actions → Assign.

  4. Choose one:

    • Assign to me (if signed in as the Service Account), or

    • Assign to another user → pick the Work 365 Service Account/Application User.

  5. If the workflow deactivates after assignment, click Activate.

Result: All new workflow instances will run under the active service account and won’t depend on individual user licenses.

Step 2 — Resume or Recover Existing Waiting Jobs

Existing jobs owned by the deactivated user won’t resume automatically. Use one of the recovery paths below.

Option A — Temporarily Reactivate the Original User (Fastest Recovery)

  1. In Microsoft 365 Admin Center, restore or reassign a license to the original workflow owner.

  2. Wait a few minutes for the license state to sync to Dynamics.

  3. In Dynamics, go to Settings → System Jobs (or open the workflow and use Process Sessions tab).

  4. Filter:

    • Status = Waiting

    • Status Reason = Paused / Waiting / Error (as applicable)

  5. Select affected jobs → More Actions → Resume.

  6. Monitor until they complete.

  7. Confirm new workflow runs are now owned by the Service Account (from Step 1).

  8. Optional: Remove the temporary license if the user is no longer needed.

Option B — Cancel & Re-trigger (When Reactivating the User Isn’t Possible)

  1. Identify impacted records (from System Jobs view or workflow logs).

  2. Cancel the waiting jobs.

  3. Re-run the workflow on-demand against those records or make a benign update that retriggers the same workflow scope.

    • For Work 365 operational jobs, consider using the Work 365 Admin Hub actions (e.g., rerun jobs) where available.

Note: You typically cannot change the owner of existing System Job records; ownership follows the original workflow owner. That’s why temporarily re-licensing or cancel-and-retrigger are the practical recovery options.

Verification Checklist

  • Workflow definition now shows the Service Account/Application User as Owner.

  • New jobs (System Jobs) list the Service Account as Owner and are Succeeded.

  • No remaining Waiting jobs owned by a disabled user (filter System Jobs to confirm).

  • Work 365 batch jobs (e.g., billing, provider sync) are running on schedule.

Best Practices (Prevention)

  • Use an Application User (non-interactive) or dedicated Service Account as the owner of all Work 365 and custom background workflows.

  • Document the owner of each critical workflow and verify during user offboarding.

  • Monitor System Jobs regularly for Waiting/Error statuses.

  • Minimize reliance on user-scoped connections for automation; prefer app registrations where possible.

  • After owner changes, publish/activate workflows and, if applicable, clear Work 365 cache (Admin Hub → Clear Cache).

Notes & Considerations

  • Real-time (synchronous) workflows run in the request pipeline and are not queued System Jobs; ownership issues primarily affect background (async) workflows.

  • If Work 365 includes Power Automate flows in your solution, review flow Connections (service principal vs. user) to avoid similar ownership/licensing issues.

  • Where Work 365 provides job controls (e.g., Work 365 Jobs area), you can Run Now or re-run failed jobs after the owner fix.