Setting up Data Entities for bulk vendor master imports

A step-by-step walkthrough of configuring a custom data entity, mapping staging tables, and running recurring integrations for high-volume vendor onboarding.

FINANCE & OPERATIONS

6/14/20264 min read

Configuring Custom Data Entities for High-Volume Vendor Onboarding in D365 Finance & Operations

If your organization onboards vendors in bulk — say, during an acquisition, a new supplier program, or a system migration — manually keying in vendor records simply isn't realistic. D365 Finance & Operations gives you a powerful toolset to automate this: custom data entities, staging tables, and recurring integrations.

This guide walks through the entire process step by step, written in plain language so anyone on your functional or technical team can follow along.

Why Custom Data Entities Matter for Vendor Onboarding

Out-of-the-box, D365 already ships with a Vendor entity. But real-world vendor onboarding rarely fits the standard mold. You might need to:

  • Bring in extra fields from a source system (legacy ERP, vendor portal, procurement tool)

  • Apply custom validation rules before records hit production tables

  • Map external codes (currency, payment terms, tax groups) to internal D365 values

A custom data entity lets you tailor the import experience to exactly what your vendor data looks like, without forcing a square peg into a round hole.

Step 1: Create the Custom Data Entity

Start in Visual Studio with the D365 development tools, or extend an existing entity if your changes are additive.

  1. Identify the target tables — typically VendTable, VendBankAccount, and any custom tables holding vendor attributes.

  2. Create a new data entity project and define the entity name, public collection name, and public entity name.

  3. Set the Entity Category to "Master" since vendors are master data.

  4. Choose which fields to expose, and organize them into field groups: Mandatory, Recommended, and Optional. This makes the import templates much easier for business users to understand.

  5. Set "Staging table required" to Yes so D365 auto-generates a staging table alongside your entity.

Step 2: Configure the Staging Table

Once the entity is built and the staging table is generated, review it carefully:

  • Confirm validation fields like batch ID, error status, and execution ID are present (D365 adds these automatically).

  • Add any custom fields you need for transformation logic — for example, a raw "source vendor group" field that needs translation before it reaches the target table.

  • Decide on data types carefully. Mismatched types here are one of the most common causes of failed imports later.

Step 3: Map Staging Fields to Target Tables

This is where most of the real work happens.

  • For straightforward 1:1 fields (vendor name, address line, phone number), the default mapping usually works fine.

  • For fields requiring lookups or translations — like converting a vendor's external payment term code to your internal D365 payment term ID — you'll need custom mapping logic in the entity's data provider class (typically by overriding insert or using a custom business logic extension).

  • For fields that may arrive blank from the source file, define sensible default values in the mapping so records don't fail validation unnecessarily.

  • Pay special attention to foreign key fields (currency, vendor group, tax group, payment method). These are the fields most likely to cause errors if the source data uses different codes than your D365 configuration.

Step 4: Set Up the Data Management Import Project

With the entity and mappings ready, create an import project in the Data Management workspace:

  1. Create a new project of type Import.

  2. Add your custom entity to the project.

  3. Choose your source file format — CSV, Excel, and XML are the most common for vendor files.

  4. Upload a sample file and walk through the field mapping screen, matching source columns to entity fields.

  5. Save the mapping as a reusable template so future vendor batches don't require remapping from scratch.

Step 5: Validate Before You Go Live

Never run a high-volume vendor import straight into production tables on the first try.

  • Run the import in "staging only" mode first. This loads data into the staging table without pushing it into VendTable, letting you inspect results safely.

  • Review the staging table for errors. Common issues include:

    • Missing mandatory fields

    • Invalid or unmapped foreign key codes

    • Duplicate vendor account numbers

  • Fix mapping rules or source data, then re-run until the error rate is acceptable.

  • Once staging data looks clean, re-run with "staging only" turned off to commit records to production tables.

Step 6: Set Up Recurring Integrations

For ongoing vendor onboarding (rather than a one-time migration), configure a recurring data job:

  1. In Data Management, go to Recurring Data Jobs (or Recurring Integrations, depending on your version).

  2. Define the inbound endpoint — this could be a file share, SFTP location, or an API endpoint exposed to your vendor portal.

  3. Set up authentication, typically using Azure AD app registrations and OAuth for API-based connections.

  4. Configure the polling frequency (e.g., every 30 minutes, hourly, nightly) based on how often new vendor files arrive.

  5. Link the recurring job to your saved import project and field mapping template from Step 4.

Step 7: Tune for High-Volume Performance

If you're processing thousands of vendor records per batch, a few settings make a big difference:

  • Enable parallel processing in the import project settings — this splits large files across multiple threads.

  • Adjust batch size to balance speed against database lock contention. Smaller batches reduce lock conflicts but increase overhead; larger batches are faster but riskier if something fails mid-run.

  • Make sure you have enough batch server capacity allocated, especially if other scheduled jobs run during the same window.

Step 8: Monitor and Get Alerted on Failures

Set up:

  • Execution history retention so you can audit past runs and troubleshoot recurring issues.

  • Email alerts for job failures or partial successes, sent to whoever owns vendor data quality.

  • A simple dashboard (Power BI works well) tracking record counts processed, error rates over time, and average processing duration — this helps you spot degrading data quality from a source system before it becomes a bigger problem.

Step 9: Final Checklist Before Go-Live

  • Run a full end-to-end test using production-volume sample data, not just a handful of test records.

  • Check downstream impacts — does this affect AP workflows, payment runs, or vendor self-service portals?

  • Document your field mappings and create a simple error-resolution runbook so your support team can handle common issues without escalating every time.

Final Thoughts

Custom data entities, well-mapped staging tables, and recurring integrations turn vendor onboarding from a manual headache into a repeatable, low-touch process. The upfront setup takes some care, but once it's running, new vendors flow into D365 cleanly and consistently — saving your team hours every week.

If you're setting this up for SAP, Business Central, NetSuite, or another platform, the core concepts are similar, though the specific tools and screens will differ. Let us know in the comments if you'd like a walkthrough for your specific platform.