## What it does
- External data import allows WFM administrators to bring in historical contact volume data from outside D365 Contact Center, from a legacy ACD, a third-party telephony platform, a spreadsheet, or a data warehouse, to supplement or seed the D365 WFM forecasting model. This is most relevant for organisations that have historical contact data in a non-D365 system and need the WFM forecasts to reflect that history rather than starting from a blank baseline.
+ 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
- - Data is imported via a CSV template that follows a specific schema: date, time interval, queue, channel type, contact volume, handle time
- - The import targets the WFM historical data store used for forecasting: it does not populate the D365 conversation entity in Dataverse
- - Imported data can be used to train the forecasting model alongside native D365 conversation history
- - The CSV schema must match the required format exactly: column names, date formats, and interval granularity (15-minute or 30-minute intervals) are validated on import
- - Import is done by an administrator in the WFM section of Copilot Service Admin Center: there is no automated API-based import; it's a manual upload process
- - Data quality directly affects forecast quality: incomplete, inconsistent, or improperly formatted historical data produces worse forecasts than no historical data
- - One-time import to seed baseline data at go-live is the most common use case; ongoing imports from a parallel legacy system during a transition period are also valid
+ - 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 when the contact centre has meaningful historical contact data in a non-D365 system that predates the D365 deployment. If historical volume patterns are seasonal, event-driven, or have strong day-of-week variation, seeding the WFM model with that history produces significantly better initial forecasts than starting with zero data.
+ 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 if the operation is genuinely new (no historical data exists) or if the historical data quality from the legacy system is poor. Bad historical data is worse than no data, it trains the model on incorrect patterns.
+ 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
- - Obtain historical data from the source system in the required granularity (15 or 30-minute intervals) for at least 12 months, ideally 24 months, to capture seasonal patterns
- - Map source system fields to the D365 WFM import schema: queue names, channel types, and time zones must match the D365 configuration exactly
- - Validate data quality before import: check for gaps (missing periods), spikes (data entry errors), and consistency across channels
- - Decide whether to import to all queues or start with the highest-volume queues: a partial import is better than a failed full import
- - Run the import in a test environment before production to verify the CSV format and spot any field mapping issues
+ - 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 import schema is strict. Column names, date format (ISO 8601), and interval boundaries must match exactly. A CSV that looks correct in Excel but has formatting quirks (trailing commas, BOM characters, inconsistent line endings) will fail import validation.
- - Time zone handling is the most common import failure cause. Source data in local time must be converted to UTC before import, or the WFM model will misalign volume with shift patterns. Verify time zone conversion with a spot-check of known peak hours.
- - Queue name mapping must be exact: the import matches queue names by string. A legacy queue called "Technical Support" and a D365 queue called "Technical Support - Tier 1" are treated as different queues. Create a mapping table before import and verify names carefully.
- - Once imported, historical data cannot be selectively deleted: to correct a bad import, the entire historical dataset for that queue/channel may need to be cleared and re-imported.
- - If the source system handled contacts differently from D365 (different wrap-up definitions, different abandon handling), the handle time data in the import may not be directly comparable. Consider whether to import volume only and let D365 build handle time history from live data.
+ - 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
  
- - Historical data import is a project task that requires coordination between the IT team (who own the legacy ACD data), the WFM module owner (who defines the target schema), and the analytics team (who validate data quality). Assign clear ownership for each part early: this task has a tendency to sit between functions with everyone assuming someone else is handling it.
- - The 12-month minimum is a guideline, not a rule. For operations with strong seasonal patterns (retail with Christmas peaks, tax services with January spikes), 24 months of data captures two full cycles and significantly improves forecast accuracy for those seasonal periods. If the client can provide it, it's worth the import effort.
- - Data quality validation before import is not optional. Ask the source team to provide a simple volume report by week for the last 12 months and sanity-check it: does it show expected peaks and troughs? Are there inexplicable gaps or spikes? Obvious data quality issues caught in this review save failed imports and frustrated WFM administrators.
+ - 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-04-30 | Revisit if Microsoft adds API-based automated import or changes the CSV schema format*
+ *Source last updated: 2026-09-08 | Revisit if Microsoft adds an API-based import or a fourth file type.*