What it does

Uploads CSV files that workforce management consumes instead of, or alongside, its own Dynamics data. Three file types: historical workload to train a forecast scenario, a finished forecast from another system to drive a capacity plan, and interval-level overrides for capacity plan parameters. Microsoft renamed this from "Import historical data" in September 2026 when the second and third file types arrived.

Key facts

• Three File Type values, each consumed by a different thing: External historical data for forecast scenario (forecasting model trains on it), External forecast data for capacity planning (skips forecast generation entirely), Capacity plan parameter override (per-interval service-level assumptions).
• Every file type supports Daily (long-term) or Intraday (short-term). The interval has to match the plan — a long-term plan can't consume an intraday file and vice versa. One interval per file; don't mix.
• Prerequisites: the Workforce Management package installed, and the WFM Forecaster or WFM Administrator security role.
• Path is Copilot Service workspace → Workforce Management → Manage External Data → New → name, interval, file type, Save, then attach the CSV and Save again.
• The File field stays locked until the record is saved. Attaching before saving isn't possible, and the message explaining that is easy to skim past.
• Validation runs automatically on save and sets Validation Status. Files only appear in a plan's data source list once validated and only for plans matching their type and interval.
• Format rules across all types: UTF-8 CSV, comma separated, header row matching exactly including capitalisation, yyyy-MM-dd for daily and yyyy-MM-dd HH:mm for intraday, intraday timestamps on 15-minute boundaries, whole numbers only, percentages as whole numbers (85, not 0.85 or 85%).
• DateTime + ChannelId + QueueId must be unique within a file. Extra columns are tolerated; missing required columns or a row with a different column count fails validation.
• Historical file columns: DateTime, ChannelId, ChannelName, QueueId, QueueName, Volume, AHT (seconds). Forecast file swaps the last two for Forecast and ForecastAHT.
• The legacy Interval, MaxVolumeByHour and AgentCount columns are now ignored rather than rejected — old templates still validate but those columns do nothing.
• Parameter override columns: DateTime, ChannelId, QueueId, TargetAnswerTime, ServiceLevel, Shrinkage, Concurrency, Occupancy. Any interval, channel and queue the file doesn't cover falls back to the plan-level values. Forecast handle time can also be overridden here, which changes workload without changing volume.
• Up to two years of workload history, counted back from the date the forecast scenario is created, and it has to be a continuous date range.

When to use / skip

Use the historical file when the volume history lives in a legacy ACD or a third-party WFM tool, or when you want to model a hypothetical — a campaign, a seasonal event — rather than a real past. Use the forecast file when the organisation plans centrally and that forecast is the plan of record; it takes forecast generation out of the picture and turns capacity planning into arithmetic on someone else's number. Use parameter overrides when one shrinkage figure across the whole plan is obviously wrong, which is most operations with training weeks, mixed channels or overnight cover.

Skip all three where the history is already in Dynamics and the assumptions genuinely are uniform. Every file is a thing someone has to maintain.

Configuration decisions

• Which file type actually answers the question. "We have a forecast already" and "we have history" lead to completely different uploads and different plan configuration.
• Interval granularity, decided by the plan it feeds rather than by what the source system exports.
• Stable ChannelId and QueueId values across uploads. These are the source system's IDs, not Dynamics GUIDs, and they have to be consistent between files or trends fragment.
• Whether parameter overrides cover every interval or just the exceptions — partial coverage is supported and usually the right answer, since uncovered rows fall back to the plan.
• Who owns the file going forward. An external forecast that stops being refreshed becomes a stale plan of record without any warning.

Gotchas

• The File field being locked before the first save catches nearly everyone once. Save the record, then attach.
• Validation is strict about the header row, including capitalisation, and about every data row having the same number of values as the header. A trailing comma in one row fails the file.
• Percentages as whole numbers. Entering 0.85 for an 85% service level validates fine and silently produces nonsense staffing.
• Interval mismatch doesn't error — the file simply doesn't appear in the plan's data source list, which reads as a missing upload rather than a wrong interval.
• Concurrency of 1 for voice is easy to forget in an override file. Leave it out and the fallback plan-level value applies, which for a blended operation may well be a chat number.
• Time zone conversion is still yours to handle. Nothing in the template records a time zone, so intervals land wherever the file says they land.
• Queue and channel identity is by ID, not name. A rename in the source system that keeps the ID is fine; a re-keying is not.

Consultant notes

• Establish the ID mapping between the source system and Dynamics queues before anyone exports anything. It's a spreadsheet someone has to own, it never survives being done from memory, and it's the difference between a forecast that reconciles and one that quietly doesn't.
• The parameter override file is the one clients don't know to ask for and the one that most improves plan credibility. Operations managers already know shrinkage is 35% in training weeks and 22% otherwise; until this existed they had to average it and then argue with the output.
• External forecast files change the political shape of the project. If finance owns the forecast, capacity planning stops being a contact centre decision and becomes a downstream calculation — worth surfacing in design rather than discovering at go-live.
• Get a validated file through end to end in a test environment before promising a go-live date. Validation failures are quick to fix individually and slow in aggregate, because each round trip needs the source team.
• Ask for the volume history as a weekly summary report first and sanity-check the peaks and troughs. Bad history trains a bad model, and it's far cheaper to catch in a chart than after a forecast scenario has been built on it.

---

Source last updated: 2026-09-08 | Revisit if Microsoft adds an API-based import or a fourth file type.