Skip to main content

Data management consultant: what you do and where

You move data into and out of Finance and Operations in bulk: you plan a migration, load journals and master data with data management and Lattice's set-based entities, keep data projects and recurring data jobs in source control, and keep recurring imports running. Assign the Integration operator role for this work. The steps marked Integration administrator change integration configuration or open administrator-only pages, so either hold that role as well or hand those steps to your administrator. You also need your standard Finance and Operations data management access to run imports and exports. You will live in the standard Data management workspace and in two Lattice pages: Table data and entity coverage while you plan, and Recurring integration health once recurring jobs run.

Plan the load​

I want to find which entity covers a table​

Where: System administration > Inquiries > Lattice data entities > Table data and entity coverage.

  1. Check Snapshot date and time. The page opens on the most recent coverage snapshot, whichever legal entity it ran in: the covering entities are the same in every legal entity, the row counts are not. If there is no snapshot, or it is older than your last deployment, have a new one taken as in I want to list the tables that hold data but no entity can reach.
  2. Type the table name in the quick filter. It searches Table name.
  3. Read Covering entities for the entity names and Covering entity count for how many there are. Long lists of names are cut off; the count is not.
  4. Set View to Multiple entities to list every table that several entities read, where you must choose one.
  5. Look at the chosen entity's fields as in I want to see the fields and keys of an entity and which fields I can write.

Needs: Integration read-only, Integration operator or Integration administrator. More: Page reference: Table data and entity coverage, Checking table and entity coverage.

I want to list the tables that hold data but no entity can reach​

Where: System administration > Periodic tasks > Lattice data entities > Analyze table data and entity coverage, then System administration > Inquiries > Lattice data entities > Table data and entity coverage.

  1. Run the analysis with Count rows selected. The Data, no entity and Non-empty tables views show only tables with a row count, so a snapshot taken without counting leaves them empty.
  2. Run it in the legal entity whose data you are migrating: a per-company table is counted in the current company only.
  3. Leave Maximum tables at 0 to cover every table. On a large database, expand Run in the background, set Batch processing to Yes and choose OK.
  4. Open Table data and entity coverage and choose Refresh to pick up the new snapshot.
  5. Set View to Data, no entity. Each row is a table that holds data but that no data entity reads: it cannot be moved through data management or OData without a new entity.

Needs: running the analysis needs Integration administrator (privilege "Run the table/entity coverage analysis"); reading the result needs any of the three Lattice integration roles. More: Reading the output for migration planning, Running an analysis.

I want to see the fields and keys of an entity and which fields I can write​

Where: System administration > Inquiries > Lattice > OData > OData entity metadata explorer, or OData metadata in the Lattice group of the Data entities page of the Data management workspace, which opens the explorer on the entity selected there.

  1. The explorer reads a stored catalog. The Catalog status line shows how many entities it holds, not when it was built. If the entity is missing, or entities were deployed since the last refresh, choose Refresh OData metadata, run it in the background, and reopen the page when the job has finished.
  2. Filter on the entity name and select the entity.
  3. On Fields, Mandatory and Key together give the minimum an insert needs, and Allow edit tells you which fields an update may change. Details shows the Primary key and the Entity table.
  4. The explorer lists public OData entities only, and the set-based import entities are not published to OData. For those, and for every other Lattice entity, use the entity reference: each entry gives the key, the mandatory fields and whether the entity is read-only.

Needs: Integration administrator (privilege "OData entity metadata explorer access"). Without it, use the entity reference or a data entity template (I want to give the source system team a template to fill in). More: Page reference: OData entity metadata explorer, Browsing the OData surface.

I want to give the source system team a template to fill in​

Where: the Data entities page of the Data management workspace: select the entity, then Export data entity template in the Lattice group. Or System administration > Periodic tasks > Lattice data entities > Data entity template.

  1. From the Data entities page, Data entity name is filled in from the selected entity. From the menu, type the entity's AOT name, for example MGCLatticeSetBasedInventoryJournalLineEntity. The template covers one entity per run.
  2. Choose the Output format: Excel workbook (.xlsx) for a fill-in template that lists each field with its data type, length, mandatory and key flags and allowed values, or XSD schema (.xsd) to validate data management XML files for the entity.
  3. If the team needs real, correctly shaped values, set Include live sample data to Yes and choose the Number of sample rows. The samples are real records from the current company: do not send them outside your organization from an environment that holds production data.
  4. Choose OK and collect the file from your browser's downloads.

Needs: any of the three Lattice integration roles (privilege "Export data entity template"), and read access to the entity in data management. More: Exporting a data entity template.

Load data in bulk​

I want to import a large journal file as ready-to-post journals​

Where: Workspaces > Data management, the Import tile, with a set-based entity such as Inventory journal lines (set-based).

  1. Pick the entity for your journal type from the list of set-based entities. On the Data entities page, check that its Set-based processing is selected. It is by default; turned off, the import refuses every row.
  2. Make sure the journal names (with their number sequences) and the items, accounts and dimension values the lines name exist. The import refuses the lines that name one that does not.
  3. Build the file with the entity's field names as the header. JournalNumber is an existing open journal to add the line to, or a grouping key of your own: each distinct key (per journal name) becomes one new journal. JournalNameId is the journal name for new journals. LineNumber is greater than zero, unique within the journal and stable, so sending the same file twice is refused line by line instead of duplicating it.
  4. Create an import project, add the entity with your source format, upload the file and choose Import in batch.
  5. Read the result. The execution succeeds when every row was written, partially succeeds when some rows were refused, and fails when none were. The journals are created open, not posted.

An integration can run the same import through the data management package REST API (GetAzureWriteUrl, ImportFromPackage, GetExecutionSummaryStatus), naming the entity by its data management name.

Needs: Integration operator or Integration administrator (the entity's import privilege, for example "Import inventory journal lines (set-based)", in duty "Data Entities Maintain"), plus your standard data management access. More: Scenario: Import journals in bulk, Set-based imports.

I want to see why lines were refused and resend only those​

Where: the import project's execution in the Data management workspace: View staging data > Validation errors. Through the package API: GetExecutionErrors.

  1. Open the execution and choose View staging data. After a run that wrote data, every row is Completed or Error.
  2. Open Validation errors for each refused row's message. A row that breaks several rules is reported for the first one.
  3. Fix those rows in your source and send only them again. The other rows were written and are never written twice.
  4. The message "The journal already has a line with this line number." means the file, or the same lines, were sent twice. There is nothing to undo; use new line numbers only for new lines.
  5. If the execution failed with no row message and the rows are still Not started, the whole transfer was rolled back. Fix the cause shown in the execution log and run the import again.

Needs: as for the import. More: Scenario: Import journals in bulk, when it goes wrong, A staging row's status.

I want to post the journals I imported​

Where: the journal page of the journal type, for example Inventory management > Journal entries > Items > Movement. From your own system: the Lattice journal posting service, /api/services/MGCLatticeJournalPostingServiceGroup/MGCLatticeJournalPostingService/<operation>.

  1. Find the new journal numbers in the staging data: each grouping key in JournalNumber is replaced by the journal its lines went to.
  2. Review the journal on its page and choose Post, or use the standard batch posting of the journal type.
  3. From your system, call the operation for the journal family with RequestId, LegalEntityId and the journal number: postLedgerJournal (JournalNum); postInventoryJournal, postProjectJournal or postProductionJournal (JournalId); postTradeAgreementJournal (JournalNum). Each posts as the page's Post does, completely or not at all.
  4. Post many journals in one call with the ...Batch variants. Queue a very large ledger journal with submitAsyncOperation: the standard posts a ledger journal above the ledger journal line limit only in batch.

Needs: on the journal page, your standard rights for that journal. Through Lattice: Integration operator or Integration administrator (privilege "Journal posting - post existing journals"), plus every Lattice operation that would post the journal's content. More: Scenario: Post a journal that already exists in D365.

I want to bring legacy keys across with the records​

Where: System administration > Setup > Lattice > External systems, the Cross references tab of the module's parameters page, and the record kind's cross-reference entity in a data project (for example Customer cross references, LatticeCustomerCrossReferences).

  1. On External systems, add the legacy system, for example LEGACYERP, with Active selected.
  2. Optional: on the module's parameters page (for example Accounts receivable parameters), open Cross references and add a row per record kind. Key kind Historical keeps the old number for reference only; Alternate key lets integrations find the record by it. Visible on forms shows the key on the record. Enforce unique cannot be turned on while duplicates exist. Without a row, keys load as alternate keys that are not unique and not shown on forms.
  3. Load the keys with the record kind's cross-reference entity: the record's business key, ExternalSystem and ExternalKey. A business key that names no record is refused, and an empty ExternalKey clears the key.
  4. If you set Visible on forms, spot-check a few records with their Cross references button or FactBox.
  5. Later files can name records by an alternate key: some writable Lattice entities, such as the sales order and purchase order line entities, accept ExternalSystem plus an ...ExternalKey field in place of a lookup value.

Needs: maintaining external systems and writing keys needs Integration administrator (duty "Maintain cross references"), or the privilege "Maintain external systems" plus the module's Maintain privilege, for example "Maintain Accounts receivable cross references". Integration operator and Integration read-only can read the keys. More: Cross-reference keys: setting it up, Cross-reference data entities, Scenario: Send your own system's keys instead of D365 ids.

Check the result​

I want to read data back to reconcile a migration​

Where: OData (https://<your-environment>/data/<entity set>), or an export project in the Data management workspace (the Export tile), with Lattice's read-only entities such as LatticeGeneralLedgerEntries, LatticeCustomerTransactions, LatticeVendorTransactions and LatticeInventoryOnHands.

  1. Pick the entities in the entity reference summary, which lists every Lattice entity with its entity set, whether it is read-only, and whether data management can export it.
  2. Over OData, read a company-specific entity with cross-company=true and a dataAreaId filter, for example /data/LatticeCustomerTransactions?cross-company=true&$filter=dataAreaId eq 'usmf'. Without cross-company=true the read runs in your default company and returns nothing for another legal entity.
  3. For large volumes, add the entity to an export project instead and compare the exported file with your source extract.
  4. For row counts across many tables, run the coverage analysis with Count rows selected and read Row count on Table data and entity coverage (per-company tables are counted in the current company only). The page shows the latest run whichever legal entity it ran in and does not name it, so take your own snapshot in the company you are migrating before you read Row count.

Needs: any of the three Lattice integration roles (duty "Data Entities View") for Lattice entities; standard Finance and Operations security for standard entities. More: Scenario: Follow a document and read data back, Data entity reference.

I want to export every field of an entity to Excel​

Where: the Data entities page of the Data management workspace: select the entity, then Export entity data to Excel (wide) in the Lattice group.

  1. Select one entity. Data entity name is filled in.
  2. Optionally list field names in Fields (optional), separated by semicolons. Blank exports every field.
  3. Optionally set Maximum rows (optional). 0 exports every record, up to the Excel worksheet limit.
  4. Choose OK and collect the workbook from your browser's downloads. It holds real records from the current company; handle it like any other data extract.

Use it for an entity with more than 255 fields, which the standard Export to Excel cannot handle.

Needs: Integration operator or Integration administrator (privilege "Export data entity to Excel (wide)"), and read access to the entity in data management. More: Exporting entity data to Excel (wide).

Run recurring data jobs​

I want to create a data project and a recurring data job by hand​

Where: Workspaces > Data management, the Import or Export tile.

  1. Name the project in Group name (Name in the standard view).
  2. Add each entity with its Source data format and Entity name: on an import project, Add file and then Upload and add for a sample file; on an export project, Add entity and then Add. In the standard view these fields are under Job details, with Upload for an import.
  3. Choose View map on each entity to check its mapping, then save the project.
  4. Choose Create recurring data job. Enter a Name without { or } and a Description. On Setup authorization policy, add the client application's Application ID and select Enabled. For an import, choose the Supported data source type (File or Data package) on Advanced options.
  5. Choose Set processing recurrence (the monitoring job runs hourly unless you change it with Set monitoring recurrence), then OK, and confirm the prompt to enable the job. OK is refused until the job has a processing recurrence and an enabled Application ID.
  6. To change the job later, choose Manage recurring data jobs on the project's Manage tab. Check it on Recurring integration health, and keep it in source control as in I want to capture a data project and its recurring data jobs as a file.

Needs: your standard data management access: the Lattice roles do not grant these standard pages. More: Setting up a recurring data job from an integration, Watching recurring integrations.

I want to set up a recurring data job and its client application through Lattice entities​

Where: the OData entities LatticeRecurringDataJobs and LatticeRecurringDataJobClients, or a data project with the entities Recurring data job and Recurring data job client.

  1. Make sure the data project exists, created as in I want to create a data project and a recurring data job by hand. Neither entity creates one, and a job that names a missing project is refused.
  2. The client application that submits or collects the files calls Finance and Operations like any integration: register it on System administration > Setup > Microsoft Entra ID applications (standard page).
  3. Create the job with Name, DataProjectName, Direction and its schedule (RecurrenceUnit, RecurrenceInterval, RecurrenceStartDateTime in UTC). Create it without State: a job cannot be created active, because it has no enabled client application yet. Keep { and } out of the name: such a job cannot be activated.
  4. Authorize the client with a LatticeRecurringDataJobClients row: JobName, ClientId and IsEnabled set to Yes.
  5. Activate the job: call the Activate action (POST /data/LatticeRecurringDataJobs(Name='<job>')/Microsoft.Dynamics.DataEntities.Activate), set State to Active (PATCH the job over OData), or import it again. Activation is refused, naming the reason, when the job has no schedule or no enabled client application. Deactivate stops the job the same way.
  6. Through data management, the job and the client are two separate imports. Keep Set-based processing off for these two entities (it is off by default). Check the result on Recurring integration health.

Needs: Integration administrator (privileges "Maintain recurring data jobs" and "Maintain recurring data job clients"). Integration operator and Integration read-only can read both entities. More: Setting up a recurring data job from an integration, Recurring data job entity, Scenario: Connect an integration client.

I want to check that my recurring data jobs are healthy​

Where: System administration > Inquiries > Lattice > Integration operations > Recurring integration health, or the Recurring jobs failing or broken, Recurring jobs with a backlog and Silent recurring jobs tiles of the Integration operations workspace, which open the page filtered.

  1. Select Needs attention only to hide the healthy and inactive jobs.
  2. Read Health and Reasons. Broken: the job cannot run as configured (a batch job is missing or stopped, an active import job has no enabled client application, or the data project has mapping errors). Failing: messages failed in the failure window. Warning: a backlog, messages processed with failed rows, a stuck message, or no message within the silence period.
  3. The list shows the last evaluation, which runs every 15 minutes. Choose Refresh health for the selected jobs or Refresh all to evaluate every job now.
  4. For mapping errors, check the project as in I want to validate the field mappings of my data projects before a release.
  5. Choose Recurring integration details, or the job's name, for its schedule, Next runs, messages and client applications.

Needs: any of the three Lattice integration roles (privilege "View recurring integration health"). An integration can read the same health from the LatticeRecurringJobHealths entity. More: Watching recurring integrations, Recurring data job health states, Page reference: Recurring integration health.

I want to find the staging row that failed in a recurring import​

Where: Recurring integration health, select the job, then Recurring integration details.

  1. On Messages, select Failed messages only. Widen Period (days) if needed: it is 7 when the page opens, and 0 shows every message.
  2. Select the failed message. Executions shows each entity's staging and target status and its new, updated and error counts.
  3. Select the execution. Row errors lists the failed rows by entity, column and error message, and Staging row gives the key fields and values of each failed staging row.
  4. Choose View staging data for the standard staging page, Execution details for the standard execution page, or Download file for the file the client application submitted. The file can be downloaded only while data management's temporary storage still holds it.
  5. Fix the data or the mapping, then have the client application submit the file again. The page does not resubmit, skip or delete a message.

Needs: any of the three Lattice integration roles (privilege "View recurring integration health"); the standard pages it opens follow their own security. Over OData, LatticeRecurringJobMessages gives each message's ExecutionId for GetExecutionErrors. More: Page reference: Recurring integration details.

I want to start, stop or repair a recurring data job​

Where: System administration > Inquiries > Lattice > Integration operations > Recurring integration health (the same buttons are on Recurring integration details).

  1. Select one or more jobs.
  2. Activate schedules the job and its monitoring job. It is refused when the job has no schedule or no enabled client application.
  3. Deactivate, after a confirmation, puts the job's batch jobs on hold. Waiting messages are processed only after the job is activated again.
  4. Repair, after a confirmation, deactivates and activates an active job whose batch jobs are on hold, in error, ended or canceled. It cannot bring back a deleted batch job: create the job again, for example by applying its configuration specification.
  5. To change the schedule or the mapping, use Manage recurring data job (the standard Manage scheduled data jobs page) or the data project. A running job's schedule cannot be changed: deactivate it first.

Needs: Integration administrator (privilege "Manage recurring integrations"); other users do not see these buttons. Through the entity, changing State needs "Maintain recurring data jobs". More: Page reference: Recurring integration health, Setting up a recurring data job from an integration.

I want to be told when a recurring data job changes health​

Where: the Health thresholds FastTab of Recurring integration details, or the LatticeRecurringJobHealths entity; then System administration > Setup > Business events > Business events catalog (standard page).

  1. Where the defaults do not fit the job, set Failure window (hours), Backlog age (minutes), Silence period (minutes) (for example 90 for a job that must receive a file every hour), Stuck after (minutes) and Failure threshold. 0 uses the default, except for the silence period, which has no default: the silence check is off unless you set it.
  2. Set Alerts enabled to Yes and save. Saving evaluates the job again with the new values.
  3. In the business events catalog, activate Recurring data job health changed, for all legal entities to receive every job.
  4. The event is raised once each time the job's health changes, not for its current health.

Needs: on the page, Integration administrator (privilege "Manage recurring integrations"). Through LatticeRecurringJobHealths, Integration operator can change the thresholds and AlertsEnabled too (privilege "Maintain recurring data job health thresholds"). The entity is enabled for data management, so thresholds can travel between environments in a data project. More: Recurring data job health alerts, Recurring data job health entity.

Keep configuration in source control​

I want to capture a data project and its recurring data jobs as a file​

Where: POST https://<your-environment>/api/services/MGCLatticeDataManagementServiceGroup/MGCLatticeDmfConfigService/captureSpec, with an OAuth 2.0 bearer token.

  1. Send { "_projectNamePattern": "Cust*", "_jobNamePattern": "Cust*" }, or blank patterns for everything.
  2. Save the response as a JSON file in your repository.
  3. Remove what is specific to the environment: client IDs (supply them from the pipeline instead) and any file paths that came from a data package.
  4. Commit the file. From then on, it defines the integration.
  5. If the integration already exists as a data package, send the contents of its Manifest.xml to specFromPackageManifest instead: { "_manifestXml": "...", "_projectName": "" }.

While a capture runs you may see a temporary data project named MGCLatticeMapDefault-... in the data project list; it is removed again, and one left behind is safe to delete.

Needs: Integration operator or Integration administrator (privilege "Capture a data management configuration specification"). More: Keeping integration configuration in source control, API reference: the specification, From a data package.

I want to keep field mappings in the specification​

Where: the Mapping member of each entity line in the specification file.

  1. Leave Mapping out to use the mapping data management generates, which keeps following the entity when fields are added to it.
  2. Set Mode to DefaultWithOverrides to keep the generated mapping and replace only the rows of the staging fields named in Overrides, or to Explicit to make Overrides the whole mapping.
  3. For a recurring import whose sender sends its own columns, list those columns in order in SourceFields, or map the line Explicit: data management reads a delimited file by position.
  4. captureSpec writes each mapping the shortest way that reads back exactly, so a captured file already carries the mapping changes you made.
  5. Default values, value conversions and transforms are captured and compared, but applySpec does not write them: it fails a line that would need one and names it. Set those on the target environment's mapping page.
  6. Capture, compare and apply in legal entities of the same country or region: the generated mapping follows the company the call runs in.

Needs: as for capturing and applying the specification. More: API reference: field mappings.

I want to see how an environment differs from the specification​

Where: POST https://<your-environment>/api/services/MGCLatticeDataManagementServiceGroup/MGCLatticeDmfConfigService/diffSpec.

  1. Send the committed file as { "_request": { "Spec": { ... }, "PruneMissing": false } }.
  2. Differences 0 means the environment matches. Each item names the Kind and Name of what differs, the Member, the EnvironmentValue and the SpecificationValue.
  3. An item with CanApply false is one applySpec cannot remove, such as a default value or a value conversion. Set it on the target environment's mapping page and the difference disappears.
  4. Set PruneMissing to true to also list the entity lines and client authorizations the file does not describe.
  5. Use it as the plan in a pull request or as a drift report: it changes nothing, and it uses the same comparison as applySpec with ValidateOnly, so the two always agree.

Needs: Integration operator or Integration administrator (privilege "Capture a data management configuration specification"). More: API reference: Comparing (diffSpec), Comparing a configuration specification with an environment.

I want to apply the specification to another environment​

Where: POST https://<your-environment>/api/services/MGCLatticeDataManagementServiceGroup/MGCLatticeDmfConfigService/applySpec, usually from a deployment pipeline.

  1. Send { "_request": { "Spec": { ... }, "ValidateOnly": true, "PruneMissing": false } } and read the plan in Items.
  2. Send it again with ValidateOnly false. Items apply in dependency order (projects, entity lines, jobs, clients, activation), so a file applies to an empty environment in one call.
  3. Check that Success is true and every item is Created, Updated or Unchanged. A failed item says why: fix the file and apply again.
  4. Run it on every deployment. Against an environment that already matches, every item reports Unchanged, so any other count means drift. A running job is stopped before its schedule changes and started again.
  5. Supply ClientId values from the pipeline, not from the committed file.

Needs: Integration administrator (privilege "Apply a data management configuration specification"); a pipeline needs it for the user its application signs in as. More: In a deployment pipeline, API reference: applying.

I want to restore integration configuration after a database copy​

Where: System administration > Inquiries > Lattice > Integration operations > Recurring integration health, then applySpec.

  1. Before anything else, check Job state of the jobs that came with the copied database, and Deactivate any that should not run in this environment.
  2. Apply this environment's specification with ValidateOnly true and read the plan. On a freshly restored environment it normally shows changes to schedules and client authorizations.
  3. Apply it for real. Set PruneMissing to true if the file is the whole truth for this environment: it removes entity lines and client authorizations the file does not describe, which takes production's client IDs off a sandbox.
  4. Check that every item is Created, Updated or Unchanged and Success is true.

Needs: Integration administrator (privileges "Manage recurring integrations" and "Apply a data management configuration specification"). More: After a database movement.

Before and after an update​

I want to make data management see new entity fields after a deployment​

Where: Workspaces > Data management, Framework parameters, the Entity settings tab.

  1. After the database synchronization, choose Refresh entity list and wait for it to finish. New entities, such as Lattice's cross-reference entities, then become available to data projects.
  2. Until a project's mapping knows the new fields, imports and exports skip them. To add them while keeping every mapping you changed, refresh the project as in I want to refresh mappings after an update without losing my own.
  3. Or regenerate the mapping by hand: in the data project, choose View map on the entity's row, then Generate source mapping, confirm, and save.
  4. Ask your integration administrator to choose Refresh OData metadata on the OData entity metadata explorer, so the explorer describes the new entities too.

Needs: your standard data management access. More: After an upgrade that changes staging tables, Keeping the picture current.

I want to validate the field mappings of my data projects before a release​

Where: POST https://<your-environment>/api/services/MGCLatticeDataManagementServiceGroup/MGCLatticeDmfMappingService/validateMappings, as a step in your deployment pipeline.

  1. Refresh the entity list first, so the check compares with the entities as they now are.
  2. Send { "_request": { "DataProjectNamePattern": "Cust*", "RecurringDataJobName": "" } }: a project name pattern (* for every project), a recurring data job whose project to check, or both.
  3. Stop the release when Success is false: there is at least one error, and an import would fail. Warnings leave Success true; they are drift to review.
  4. Act on each finding's Check and SuggestedFix. A refresh fixes FieldNotMapped (a field added to the entity) and StagingFieldMissing (a field removed from it), and a refresh that regenerates the staging-to-target mapping fixes TargetMappingStale. SourceFieldMissing is fixed on the entity's mapping page.
  5. A pattern that matches no project is refused rather than reported clean, so a typo cannot pass the gate.

Needs: Integration operator or Integration administrator (privilege "Validate data management field mappings"). It changes nothing. More: Scenario: Validate and refresh data project mappings, API reference: validateMappings, Keeping data project mappings in step.

I want to refresh mappings after an update without losing my own​

Where: POST https://<your-environment>/api/services/MGCLatticeDataManagementServiceGroup/MGCLatticeDmfMappingService/refreshMappings.

  1. Preview first: { "_request": { "DataProjectName": "CustomerImport", "EntityName": "", "RegenerateTargetMapping": false, "ValidateOnly": true } }. Changes lists exactly what the real run will do. Leave EntityName blank for every enabled entity of the project, or give one entity's data management name.
  2. Send the same request with ValidateOnly false. Every existing mapping stays as it is (custom source fields, default values, auto-generated fields, text qualifier and blank-value settings), each staging field with no mapping gets the standard one, and mappings to fields that no longer exist are removed. Each entity changes completely or not at all.
  3. Only when validateMappings reported TargetMappingStale, refresh with RegenerateTargetMapping true, previewing first. That mapping is shared by every project that uses the entity, so the change reaches all of them. Run the refresh once more afterwards.
  4. Run validateMappings again. A second refresh changes nothing.
  5. A refresh cannot map a source column to a different field or write a default value or a value conversion. Do that on the entity's mapping page (View map in the data project).

Needs: Integration administrator (privilege "Refresh data management field mappings"). More: Scenario: Validate and refresh data project mappings, API reference: refreshMappings.