After migrating to D365 cloud (10.0.40), our lease approval workflows are getting stuck at ‘Pending’ status indefinitely. The workflow submits successfully, but the approval step never completes or moves to the assigned approver’s queue. This is blocking our entire lease activation process.
I’ve checked the workflow configuration and it appears identical to our previous on-premises setup. The workflow history shows the submission event but no subsequent approval assignment. The workflow batch job is running (I can see it in system administration), and there are no error messages in the batch job history. User security roles seem correct - the same users who could approve before migration still have the Lease Manager role assigned.
Has anyone experienced workflow issues specific to lease management after cloud migration? I’m wondering if there’s something different about how workflow batch processing works in the cloud environment, or if the migration process affected workflow configurations in ways that aren’t immediately visible.
Based on your symptoms, this is a classic workflow batch job configuration issue after cloud migration. Here’s the complete solution:
Workflow Batch Job Status:
The ‘Waiting’ status indicates the batch job is scheduled but not actively processing the queue. This happens when:
The batch server group isn’t properly configured in the cloud environment
The workflow infrastructure isn’t fully initialized post-migration
The batch job user context lacks necessary database permissions
Resolution Steps:
Verify Batch Infrastructure:
Go to System Administration > Setup > Batch group
Ensure you have an active batch server group (cloud environments may need manual activation)
Verify the batch server status shows ‘Started’
Reconfigure Workflow Batch Jobs:
Navigate to System Administration > Inquiries > Batch jobs
Find ‘Workflow message processing’ job
Edit the job and change the batch group assignment
Set recurrence to every 1 minute
Ensure ‘Run by’ user is set to a system admin account
Repeat for ‘Workflow due date processing’ job
User Security Roles:
Verify workflow approvers have the complete role assignment:
Lease Manager role (for lease-specific permissions)
System user role (for workflow participation)
Workflow user role (often missing after migration)
The workflow user role is critical - without it, users can’t receive work items even if they have functional permissions.
Workflow Configuration Migration:
Your workflow definitions migrated, but the runtime configuration may need reactivation:
Go to Organization Administration > Workflows > Lease management workflows
Open your lease approval workflow
Click ‘Versions’ and verify the active version is marked correctly
If needed, create a new version and activate it (this reinitializes workflow metadata)
Process Stuck Work Items:
Once batch jobs are properly configured:
The 200+ pending work items should process automatically within 10-15 minutes
Monitor Common > Common > Workflow > Workflow history to watch items clear
If items remain stuck after 30 minutes, you may need to cancel and resubmit those specific leases
Cloud-Specific Considerations:
In cloud deployments, workflow batch jobs require explicit batch server group assignment. The migration process doesn’t always preserve these assignments correctly. Additionally, the workflow infrastructure initialization sequence differs from on-premises - the batch jobs must be restarted AFTER the environment is fully synchronized.
Verification:
After implementing these changes, test with a new lease submission. The workflow should progress from ‘Pending’ to ‘Assigned to [Approver]’ within 1-2 minutes. If you still see delays, check the batch job history for any runtime errors that might indicate permission or connectivity issues.
Let me know if the work items start processing after these changes.
This draft is based on general Microsoft Dynamics 365 knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check if your workflow batch job is actually processing items. Go to System Administration > Inquiries > Batch jobs, find the Workflow message processing job, and verify it’s not showing any warnings. Sometimes the batch frequency gets reset during migration.
Tested this on our D365 F&O cloud-migrated environment — resetting the batch server group assignment in System Administration fixed our stuck lease approval workflows immediately.
The batch job shows as ‘Waiting’ status with no errors. The recurrence is set to run every minute, which is what we had before. Should I try restarting it or is there something else to check?
I had a similar issue post-migration. The problem was that the workflow infrastructure batch jobs weren’t properly configured in the cloud environment. You need to verify that both the Workflow message processing job AND the Workflow due date processing job are active. Also check if your workflow work item queue is building up - go to Common > Common > Workflow > Workflow history and look for unprocessed work items. In cloud environments, the batch job execution context can be different, especially regarding database connections and user context for workflow processing.
Another thing - verify that your workflow users have the correct security roles in the migrated environment. During cloud migration, sometimes the user-role associations don’t migrate cleanly, especially for system accounts used by workflow batch jobs. Check the batch job’s ‘Run by’ user and make sure that account has sufficient privileges.
I found that the workflow work item queue has over 200 pending items that haven’t been processed. The batch job user is set to ‘Admin’ which should have all permissions. How do I force these work items to process?
That queue buildup confirms the batch job isn’t processing correctly. Try this: Stop the Workflow message processing batch job, wait 5 minutes, then restart it with a slightly different recurrence (like every 2 minutes). Sometimes the job gets into a stuck state where it’s technically running but not actually processing the queue. Also verify the batch server group assignment - in cloud deployments, you need to ensure the batch job is assigned to an active batch server group.