Service | Customer Service, Contact Center, Fie...

WFM Forecasting External Data Forecast Failed

(0) Share

Report

Posted on by 34SF

Hello,

I am facing an issue with Workforce Management (WFM) Forecasting using External Data in Dynamics 365 Customer Service / Contact Center,

i created the historical CSV file as Microsoft guide saying: Import historical data, next i Created a new Managed External Data record (Validation Status = Successful)

finally created a new Forecast Scenario using the external data as the data source then click on Create new snapshot.
the system show only this message without details:

here is an example on the excel file data:

DateTime	ChannelId	ChannelName	QueueId	QueueName	Volume	AHT	Interval	MaxVolumeByHour	AgentCount
2025-01-01 00:00:00	5c453d47-e1c9-e911-a826-000d3a1f0599	Live chat	87e15852-1c9f-f111-b8dd-6045bd597a3c	CSR	195	10	Daily	17	4
2025-01-02 00:00:00	5c453d47-e1c9-e911-a826-000d3a1f0599	Live chat	87e15852-1c9f-f111-b8dd-6045bd597a3c	CSR	819	9	Daily	70	13
2025-01-03 00:00:00	5c453d47-e1c9-e911-a826-000d3a1f0599	Live chat	87e15852-1c9f-f111-b8dd-6045bd597a3c	CSR	767	8	Daily	66	11
2025-01-04 00:00:00	5c453d47-e1c9-e911-a826-000d3a1f0599	Live chat	87e15852-1c9f-f111-b8dd-6045bd597a3c	CSR	397	7	Daily	34	5
2025-01-05 00:00:00	5c453d47-e1c9-e911-a826-000d3a1f0599	Live chat	87e15852-1c9f-f111-b8dd-6045bd597a3c	CSR	446	10	Daily	38	8

Thank you

Categories:

Dynamics 365 Contact Center

Dynamics 365 Customer Service

Dynamics 365 Field Service

All responses (4)

Answers (0)

Sort by

Suggested answer

Syed Aqib Raza 138 on at

Like (0)

Report
Copy link

Link copied!
Since the Managed External Data validation is successful, I would focus on the forecast scenario configuration and the actual CSV values rather than the upload itself.
From your sample, the column structure looks correct — Microsoft currently expects DateTime, ChannelId, ChannelName, QueueId, QueueName, Volume, AHT, Interval, MaxVolumeByHour, AgentCount for external forecast data. For daily data, Interval should be Daily; for short-term/intraday forecasting, the data must be in 15-minute intervals. DateTime should also follow the required date/time format.
A few things I would verify:
Forecast Scenario type vs CSV interval — make sure a Long-term/Daily scenario is being used with Daily data, or a Short-term scenario with 15-minute data.
DateTime values — make sure there are no invalid dates, blank values, duplicate/inconsistent intervals, or unexpected date formats.
Numeric columns — Volume, AHT, MaxVolumeByHour, and AgentCount should contain valid whole-number values.
Channel and Queue mapping — verify that the channels and queues selected in the Forecast Scenario correspond to the ChannelId/ChannelName and QueueId/QueueName values in the CSV.
Historical date range — make sure the selected historical start date actually covers the data being supplied.
Check View Job History after creating the snapshot. Microsoft specifically recommends Job History for checking whether the forecast execution completed or failed and for diagnosing missing forecast output.
One important point: a successful Managed External Data validation does not necessarily mean the forecasting model can successfully process the dataset. The snapshot generation runs as a background job, so the failure can occur during forecast processing.
If possible, I would also test with a very small CSV containing only a few days of clean historical data for one queue and one channel. If that succeeds, gradually add the remaining queues/channels to identify whether a particular dataset is causing the forecast job to fail.
34SF 28 on at

Like (0)

Report
Copy link

Link copied!

Hi, @Syed Aqib Raza thank you for your interaction, i verified what you mentioned, from 1-4 already verified, regarding Historical data range i updated to be one day before the historical data rang (earlier it was at the same date). the same issue is persist,

in the system job i found only these two job have relation with the forecast action, and they completed successfully
Suggested answer

ParthPatel249 156 on at

Like (0)

Report
Copy link

Link copied!

This is a frustrating one because the failure message gives you nothing to work with. Based on what you've shared, here are the most likely causes to check.
Data format issues in the CSV
Even though validation passed, the forecast engine is stricter. A few things to double check in your file:
The Interval column is set to Daily but WFM forecasting typically expects 15min or 30min intervals, not daily. This is very likely your main problem. Try changing the interval to 15min or 30min and adjust your DateTime and volume data accordingly.
The DateTime format must be exactly yyyy-MM-dd HH:mm:ss in UTC, which yours looks correct on.
Make sure there are no blank rows, extra columns, or BOM characters in the CSV if you saved it from Excel, saving as CSV UTF-8 without BOM is safer.
Queue and Channel IDs
Even though validation passed, double check that the QueueId and ChannelId GUIDs actually exist and are active in your environment. A mismatch here can cause the forecast run itself to fail silently.
Minimum data requirement
Microsoft requires at least 8 weeks of historical data for the forecasting model to run properly. If your data is shorter than that the job can fail without a clear error message.
To get more details on the failure
Go to the WEM Schedule Job record and check if there are any related error logs. Also check the Power Automate flows tied to WFM in your environment, sometimes the detailed error surfaces there rather than in the UI.
The interval issue is the most likely culprit given what's shown in your sample data.
Suggested answer

Syed Aqib Raza 138 on at

Like (0)

Report
Copy link

Link copied!
@34SF
Thanks for confirming. Since items 1–4 have already been verified, the historical start date was adjusted, and the related system jobs are completing successfully, I would focus next on the forecast scenario run itself rather than the external-data validation or the Dataverse system jobs.
The important distinction here is that a successful Managed External Data validation only confirms that the uploaded data can be accepted as an external data source. The actual forecast generation is a separate asynchronous process. Microsoft documents that running a forecast starts a background job, and the forecast output is generated after that job completes.
Since your screenshot shows the Forecast Scenario itself in Failed status while the related system jobs are Completed, I would check the following next:
Open Job History for the failed Forecast scenario run and select View details. If there is an error message, correlation ID, or additional execution information there, please share that.
Check whether the failure occurs with a minimal external CSV. I would create a test file with only:
1 Channel
1 Queue
5–10 consecutive days
Interval = Daily
valid numeric values for Volume, AHT, MaxVolumeByHour and AgentCount
Microsoft currently documents the required Daily external-data columns as DateTime, ChannelId, ChannelName, QueueId, QueueName, Volume, AHT, Interval, MaxVolumeByHour, AgentCount.
If the minimal dataset succeeds, gradually add the remaining queues/channels. This would help determine whether the issue is caused by a particular queue/channel combination or by the size/content of the external dataset.
Also verify that the Forecast Entity, Channel, Queue, Forecast Type and Interval are consistent. Your screenshot shows a Long-term / Linear scenario, so the external data should be Daily. Microsoft describes Long-term forecasting as daily forecasting, while Short-term forecasting uses 15-minute intervals.
If even the minimal one-queue/one-channel dataset fails with the same Forecast scenario run – Failed status, then I would consider this less likely to be a CSV-data issue and more likely to require investigation of the WFM forecasting service/backend. At that point, the Job History details and the exact timestamp of the failed run would be useful for a Microsoft support ticket.
The fact that the two related System Jobs completed successfully does not necessarily prove that the forecast generation itself succeeded, because the forecast run is an asynchronous process with its own execution status.
If you can post the View details output from the failed Forecast scenario run, that would be the next useful piece of information to identify the actual failure.