Integration operations - Operator Guide

Integration operations is the service surface of Lattice: the inbound service surface (REST operations and OData), the file-ingestion pipeline that feeds it, and the pages you use to watch both and to recover what fails. This guide is the day-to-day companion for the person who runs that surface inside Finance and Operations - what to check, how to tell healthy from unhealthy, how to recover a failure, and which actions are deliberately restricted.

It assumes you know F&O navigation, batch jobs, and your own integration's business meaning. It does not assume you know anything about how Lattice is built. Where a topic has a deeper reference this guide links into it rather than repeating it.

---

Before you start

The role you need

Every page below is granted through a Lattice role. Ask your security administrator which one you hold; the answer decides what this guide lets you do.

Role	What it covers	Can it recover failures?
Integration read-only (MGCLatticeIntegrationReadOnlyRole)	Viewing the operations console, service call statistics, the service metadata explorer (without its refresh) and the business event catalog	No - read only
Integration operator (MGCLatticeIntegrationOperatorRole)	The same monitoring surface	No - the recovery actions sit in the high-risk duty
Integration administrator (MGCLatticeIntegrationAdministratorRole)	Everything in this guide: recovery actions, the service test console, file ingestion setup, APIM, policy setup	Yes
Database access administrator (MGCLatticeDatabaseAccessAdministrator)	Just-in-time database access grants only	n/a - see the warning in that task

The recovery actions on the operations console re-check your permission in code every time you click them, not just when the page opens. If Retry now, Hold, Release or Discard raises a "not authorized" error, you hold a monitoring role rather than the administrator role: those four actions, and the dead-letter retry sweep, are granted only by the high-risk duty. View payload works for anyone who can open the console. Full privilege, duty and role detail is in Security model; the assignment steps are in Assigning a Lattice role to a user.

The jobs that must be running

Most of what you monitor is produced by Lattice's background processes, which the process automation framework runs by themselves after every deployment: there is no batch job to create. If a queue looks frozen, check its process before you touch the data, on System administration > Setup > Process automations > Background processes (process automation must be initialized in the environment).

Background process	Job class	Runs	Why you care
Lattice dead-letter retry	MGCLatticeIntegrationDlqRetryBatch	Every 5 minutes, when an item is due	Replays every dead-letter item that is Retrying and due, closes re-queued file ingestion items whose record has been processed, and recovers asynchronous operations left processing by a stopped task. Nothing retries automatically without it.
Lattice idempotency reconciliation	MGCLatticeIdempotencyReconciliationSweep	Hourly, when a claim has been processing for over 60 minutes	Resolves create-then-post claims stranded in Processing.
Lattice business event reconciliation	MGCLatticeBusinessEventReconciliationSweep	Hourly, when a failed event is 15 minutes old	Re-publishes outbound business events that failed, up to 5 attempts each.
Lattice workflow stalled or failed alerts	MGCLatticeWorkflowStalledAlertBatch	Hourly	Raises Workflow stalled or failed for faulted workflows and work items pending over 24 hours.
Lattice service call statistics rollup	MGCLatticeServiceCallStatisticsRollup	Daily	Builds the daily rows behind Service call statistics. Without it that page stays empty.
Lattice integration log cleanup	MGCLatticeServiceLogCleanup	Daily	Purges aged call-log, statistics, idempotency, async tracking, dead-letter, refresh-log, ingestion-log and business event log rows.
Lattice file ingestion cleanup	MGCLatticeFileIngestCleanup	Daily	Deletes processed file ingestion bundles past their connection's retention.
Lattice sales price effectivity events	MGCLatticeTradeAgreementPriceEffectivityBatch	Daily	Sends the Effective / Expired sales price agreement events.
Lattice recurring data job health alerts	MGCLatticeRecurringJobHealthAlerts	Every 15 minutes, when recurring data jobs exist	Keeps Recurring integration health and its workspace tiles current, and raises Recurring data job health changed for the jobs with alerts on whose health changed. It has no menu item: Refresh all on Recurring integration health evaluates on demand.
Lattice Async Operation Processor	MGCLatticeAsyncOperationProcessor	Every minute	Drains asynchronous service submissions.

Two jobs are not background processes:

Job	Class	Cadence	Why you care
Metadata refresh	MGCLatticeServiceMetadataRefreshBatch, MGCLatticeODataMetadataRefreshBatch	Run both after every deployment (from the explorers or as batch jobs), and whenever an explorer looks out of date; nothing schedules them automatically	Populates the service and OData explorers. The service test console cannot run an operation whose metadata has never been refreshed. The service metadata refresh is started from the Refresh metadata button of the Service metadata explorer and needs the integration administrator role; other roles see the explorer without that button.
Inbound order policy evaluation	MGCLatticeInboundOrderPolicyEvaluationBatch	Schedule it every few minutes once the policy is enabled	Holds and auto-confirms inbound sales orders under the guardrail policy.

Each job also has a menu item on System administration > Periodic tasks > Lattice (the async operation processor as Process async operations), which runs it now, with other values where its dialog has any; the same submenu holds the inbound order policy evaluation and Process file ingestion segments, the file ingestion segment processor that sends each ingested record to its target. Each needs the integration administrator role, most of them through its batch maintenance duty (MGCLatticeBatchMaintenanceDuty). The same submenu also holds Run database access expiry sweep, which needs the database access administrator role instead (see Granting and revoking just-in-time database access). To change how often a background process runs, see Changing a background process.

The dead-letter retry and the backoff. A failed item waits 60 seconds before its first retry, then double each attempt up to a one-hour ceiling, and is parked after 5 attempts. The process looks for due items every 5 minutes; a longer interval simply delays each retry further.

---

The daily check

Five minutes, in this order. Everything here is read-only.

Click path - four stops, in this order.

1. Open the integration operations workspace. Open Integration operations from the default dashboard or the navigation pane's Workspaces list, or go to System administration > Inquiries > Lattice > Integration operations > Integration operations. On the Summary section, read the nine count tiles:

Tile	Healthy	If it is not
Dead letters awaiting action	Zero, or a small number that is falling	Anything that is not falling is the rest of this guide. Open the tile - it lands on the operations console filtered to items that are retrying, parked or held.
Failed service calls (24 h)	Zero, or the background rate you know	Open the tile - it lands on the service call log filtered to the failures; the Error code and Message columns say why.
Inbound orders on hold	Zero, or orders someone is already working	Open the tile - it lands on the policy state list; Hold reason says which guardrail fired.
Stale idempotency claims	Zero	A claim still processing after an hour means a call died mid-flight. Close the claim with Mark succeeded or Release claim on Service idempotency log, and check that the reconciliation sweep is scheduled.
Claims needing manual reconciliation	Zero	The sweep parked these for a person. Triage them per the runbook.
Unresolved business event errors	Zero, or a number that is falling	Open the tile - it lands on the business event log filtered to the errors; Status details carries the delivery error.
Recurring jobs failing or broken	Zero	Open the tile: it lands on Recurring integration health filtered to those jobs. See Watching recurring integrations.
Recurring jobs with a backlog	Zero, or jobs whose messages are about to be processed	Messages are waiting. A backlog that does not shrink between checks means the job is not processing; open the tile and read Reasons.
Silent recurring jobs	Zero	A job with a silence period has received no message for longer than that period: check the sending system first.

2. Skim recent activity. Stay on the workspace and expand the Recent activity section. Click through its tabs - Dead-letter queue, Recent service calls, Idempotency claims, Business event log and Inbound order policy state - each newest-first. Recent Succeeded calls with normal durations, and claims moving to Succeeded, mean the services are healthy.

3. Check the file ingestion pipeline. Open File ingestion operations (from the dashboard, the Workspaces list, the Links section of the integration workspace, or System administration > Inquiries > Lattice > File ingestion). Read the Active connections tile - a drop means someone disabled a connection - then expand Pipeline activity and click through Recent bundles, Segments and Ingestion log. A healthy pipeline shows recent Received timestamps and segment State values moving to Processed. Segments stuck in Queued usually mean the segment processor batch job is not running, not that the data is bad: start or schedule Process file ingestion segments from System administration > Periodic tasks > Lattice.

4. Read the queue status and the daily rollup. From the integration workspace's Links section open Integration operations console and read the Queue status line beside the filter: it gives the counts of items that are retrying, parked and reprocessed, plus how many hours old the oldest parked item is. A growing parked count, or an oldest-parked age that keeps climbing, is the signal that something needs a person. Then open Service call statistics and read yesterday's rollup per operation: Calls, Successes, Failures and the duration columns. A Failures count that is suddenly non-zero, or an Average duration (ms) that has jumped, points at the operation to investigate; the page is empty until the rollup job has run.

---

Recovering a failed integration message

Goal. Get a message that failed back through the pipeline, or take it out of the queue deliberately.

Click path

1. Go to System administration > Inquiries > Lattice > Integration operations > Integration operations console.
2. Select the row you want to work in the list. Use the quick filter above the list to find it by service name if the queue is long.
3. Click View payload and read the failure message in the infolog before you decide anything.
4. Click the action that matches your diagnosis, from the table below.
5. Click Yes if a confirmation prompt appears.
6. Click Refresh to re-read the list and recompute Queue status.

The action in step 4:

Action	Use it when	What it does
Retry now	The cause was transient and is now fixed (the target came back, a lock cleared)	Sets the item to retrying and makes it due immediately, so the retry sweep picks it up on its next run. It does not replay in front of you.
Hold	You know it will keep failing and you do not want it retried while you investigate	Marks the item held; the retry sweep only selects retrying items, so it is skipped until released.
Release	Your investigation is done and the item should rejoin the normal lifecycle	Returns a held item to retrying, due immediately.
Discard	The message must never be processed - a duplicate, a test file, a business decision	Marks it discarded. It leaves the retry sweep and the active counts. This is the end of the line for that item.
View payload	Before any of the above, to see what actually failed	Shows the original payload and the failure message in the infolog.

Step 3 matters: the failure message usually tells you whether the problem is the payload or the environment, which is what decides between Retry now and Fix and resubmit.

How to verify. After Retry now or Release the Status becomes retrying and Next retry is now; after the sweep runs the row is either reprocessed or its Attempts has increased.

When it does not work.

• Only an item that is currently retrying or parked can be held; Retry now also accepts a held item. An item that is already reprocessed or discarded is terminal, and a requeued item is waiting for its record to be processed; the page tells you so.
• Every action records you in Last actioned by, and the item's modified date and user record the change.
• Release applies only to a held item.
• Discard refuses an item that has already been reprocessed - that one succeeded.
• Replay always reuses the original request identifier, so a retry of something that in fact posted will not post it twice. That is the idempotency guarantee, not a reason to retry blindly.

View payload is audited. Who viewed which dead-letter item is recorded. The payload itself is never written to telemetry or any persistent log - it is shown to you, once, in the infolog.

A failure that never reached the queue. If writing a failed item to the dead-letter queue itself fails, the item is not on this page. Lattice then records the exception Lattice.Dlq.EnqueueFailed in Application Insights, and Lattice.Dlq.ParkAlertFailed when the alert for a newly parked item could not be raised. Both carry ids and names only - the source and its tracking or segment id, the service and operation, and the request id or dead-letter id - never the payload or the failure message. They reach Application Insights only when the environment's monitoring and telemetry is set up to send there.

---

Fixing a bad payload and resubmitting it

Goal. The message failed because the payload was wrong, and you can correct it.

This page is granted only by the administrator role.

Click path

1. Go to System administration > Inquiries > Lattice > Integration operations > Dead-letter fix and resubmit.
2. Select the item in the list. The header shows Status, Service, Operation, Error category, Error code, Attempts and the Failure message.
3. On the Payload tab, read Original payload - it is read-only, so the evidence of what arrived is preserved.
4. Type the corrected payload into Edited payload.
5. Click Fix and resubmit.
6. Click Yes on the confirmation prompt. It runs the operation in front of you, using the edited payload when one is present and the original otherwise.

File ingestion items. The payload of a file ingestion item is the record as it was received (a record of an XML file as XML). Resubmitting it does not run the operation in front of you: the edited payload, when there is one, replaces the segment's stored record (with no edit, the original record is used), and the segment is re-queued, so the segment processor transforms and dispatches it on its next run. Original payload keeps what arrived.

How to verify. On success the item's Status becomes reprocessed and the infolog confirms it. On failure the item is parked for review and Attempts has gone up by one. A file ingestion item becomes Requeued: the dead-letter retry sweep closes it as reprocessed once the File ingestion monitor shows its record Processed, and it is parked again if the record fails again.

Only a retrying, parked or held item can be resubmitted; a reprocessed, discarded or requeued item is refused.

When it does not work. A parked result means the corrected payload still failed - read the new failure message before editing again. The resubmit reuses the original request identifier, so if the original call actually did post, idempotency prevents a second posting.

---

Tracing an inbound message end to end

Goal. Answer "what happened to the file/message the partner sent?".

Click path

1. Go to System administration > Inquiries > Lattice > Integration operations > Inbound message inquiry.
2. On the Bundles tab, find the file by Source file name and note its Bundle ID. Click Download bundle payload if you need the original file content.
3. Open the Segments tab and find the rows whose Bundle ID matches. Read State and, for a failure, Error message. Click Download segment payload for the content of one record as it was received; a record of an XML file is shown as XML, although the Liquid template received it converted to JSON.
4. If the call was submitted asynchronously, open the Async operations tab and match on Service and Operation; read Status, Submitted time and Completed time. Click Download request payload for what was sent.
5. If a segment failed, open the Dead letter tab and read Status, Error category and Attempts. Click Download dead-letter payload for the failed request.

The four tabs, one per stage:

Tab	What it holds	Key columns
Bundles	The ingested files	Bundle ID, Source file name, Connection ID, Segments, Received
Segments	One row per record inside a bundle	State, Processing attempts, Max attempts, Error message
Async operations	Service calls submitted asynchronously	Tracking ID, Status, Submitted time, Completed time
Dead letter	What failed and is now in the queue	Status, Error category, Attempts, First failed

Each tab's download action gives you the original content of the selected row, to compare against what the partner believes they sent.

For bundle-level detail with the log alongside it, go to System administration > Inquiries > Lattice > File ingestion > File ingestion monitor, select the bundle, and read the Segments and Log tabs. That page can also put a single failed segment on Hold or Release it: select the segment on the Segments tab and click Hold or Release on the action pane.

---

Watching recurring integrations

Goal. Notice when a data management recurring integration (a recurring data job) fails, backs up, goes silent or loses its batch job, and find the rows that failed, without waiting for the business to report it.

Lattice evaluates the health of every recurring data job every 15 minutes and stores it. Each job gets a health state and the reasons for it; Recurring data job health under Reading the states says what each state means.

Click path

1. Open Integration operations and read the recurring job tiles: Recurring jobs failing or broken, Recurring jobs with a backlog and Silent recurring jobs. Each opens Recurring integration health filtered to those jobs. You can also open the page from System administration > Inquiries > Lattice > Integration operations > Recurring integration health.
2. Read Reasons for each unhealthy job. Select Needs attention only to hide the healthy and inactive jobs. The list shows the last evaluation; choose Refresh all to evaluate every job now, or Refresh health for the selected jobs.
3. Broken because a batch job is on hold, in error, ended or canceled: select the job and choose Repair, then confirm. The job is deactivated and activated again, and its batch jobs wait for their next run with the job's current schedule.
4. Broken because no client application is enabled: open the details (Recurring integration details) and, on Client applications, enable the client application or choose Add client application.
5. Broken because of mapping errors in the data project: check and refresh the mappings as described in Keeping data project mappings in step.
6. Failing, or a warning about partially processed messages: open the details and select the failed message on Messages (Failed messages only narrows the list). Executions shows each entity's staging and target counts, and Row errors names the entity, the column, the error message and the key of each failed staging row. Use View staging data or Execution details for the standard pages, and Download file to get the file the client application submitted. Fix the data or the mapping, then let the client application submit the file again.
7. To change what counts as unhealthy for one job, set its Health thresholds on the details page and save: for example a Silence period (minutes) of 90 for a job that must receive a file every hour. A value of 0 uses the default, and saving evaluates the job again.

Activate, Deactivate, Repair, the client application actions and the thresholds need the integration administrator role. The operator and read-only roles see both pages and can refresh the health.

What the pages cannot do

• They do not resubmit, skip or delete a failed message. The fix is always at the source: correct the data or the mapping and submit again.
• Download file works only while data management still holds the file in its temporary file storage, which expires. After that the page says the file is no longer in storage.
• Repair cannot recreate a batch job that was deleted, and refuses the job. Delete the recurring data job and create it again, for example by applying its configuration specification (see Comparing a configuration specification with an environment).

Get told instead of looking. Switch Alerts enabled on in a job's Health thresholds and activate the Recurring data job health changed business event: Lattice then raises it once each time that job's health changes. See the business events operator guide.

How to verify. After a Repair, Job state is Active, the health is no longer Broken, and Processing batch job on the details page opens a batch job that is Waiting. After a fix at the source, the next message shows as processed on Messages and the job returns to Healthy at its next evaluation.

The pages are described field by field in Page reference.

---

Keeping data project mappings in step

Goal. Find data projects whose field mappings no longer match their entities, typically after an update added or removed entity fields, and repair them without losing your own mappings.

Two service operations of MGCLatticeDmfMappingService (service group MGCLatticeDataManagementServiceGroup) do this; there is no page for them. Call them from a pipeline, Postman or the Service test console.

• validateMappings checks the projects that match a name pattern, or the project of a named recurring data job, and lists each finding with the entity, field, check, severity and a suggested fix. It changes nothing. Errors (a key or mandatory field not mapped, a mapping to a field that no longer exists) stop rows from importing; warnings (a field the standard mapping would map but this project does not, a stale staging-to-target mapping) are drift to review.
• refreshMappings repairs one project, or one entity of it. It keeps every existing mapping exactly as it is, adds the standard mapping for each staging field that has none, and removes mappings to fields that no longer exist. Run it with ValidateOnly first: the preview lists exactly the changes the real run makes.

Typical uses:

• Before a deployment: run validateMappings with the integration's project pattern and stop the pipeline when Success is false.
• After an update added entity fields: validateMappings reports the new fields as not mapped; run refreshMappings with ValidateOnly, then without it. In data management, the entity's mapping on the project now shows the new fields, and your own mappings are unchanged.
• After an entity lost a field: validateMappings reports the mappings to the missing field as errors; refreshMappings removes them. Map the source column to the field that replaced it on the mapping page.
• A stale staging-to-target mapping: run refreshMappings with RegenerateTargetMapping. That mapping is shared by every project that uses the entity, so the change reaches all of them.

A recurring data job whose data project has mapping errors shows as Broken on Recurring integration health, with the number of errors in its reasons.

validateMappings needs the integration operator or administrator role; refreshMappings changes integration configuration and needs the administrator role.

Comparing a configuration specification with an environment

A data management configuration specification describes data projects, their entities and field mappings, and the recurring data jobs that run them; captureSpec on MGCLatticeDmfConfigService reads one from an environment and applySpec makes an environment match one. Before you apply one, or to check that an environment still matches the specification in source control, call diffSpec on MGCLatticeDmfConfigService. It changes nothing and lists every difference, member by member, with the environment's value and the specification's value. diffSpec uses the same comparison as applySpec with ValidateOnly, so the two always agree.

A difference marked CanApply false is one applySpec cannot remove, for example a default value or a value conversion in a field mapping, which data management offers no programmatic way to write. Set those on the target environment's mapping page; the difference then disappears.

Comparing a field mapping needs the standard generated mapping, which data management only produces inside a data project: captureSpec and diffSpec create a temporary data project named MGCLatticeMapDefault-... and remove it again. If you see one in the data project list, a comparison is running or was interrupted.

diffSpec needs the integration operator or administrator role, like captureSpec.

---

Testing a service operation safely

Goal. Reproduce or validate an operation without risking a posting.

Click path

1. Go to System administration > Inquiries > Lattice > Services > Service test console.
2. On the Request tab, pick the Service name and Operation name from the lookups (they list what the metadata refresh has discovered).
3. Click Load sample to fill Request JSON with the generated sample for that operation, or paste your own payload into it.
4. Set Preview mode (validate / run-and-abort - no posting) if you want a non-committing run - read the warning below first.
5. Click Run.
6. Click Yes on the confirmation prompt. Its text differs between a preview and a real run; read it before confirming.
7. Open the Response tab and read Status (outcome, duration, message) and Response JSON.

To keep a payload for later: type a Request name on the Request tab and click Save request. To bring it back: open the Saved requests tab, select the row, and click Load selected. To remove one: select it on Saved requests and click Delete.

Preview mode is not a universal safety net. It applies only to operations whose request contract is preview-capable; as shipped that is the general-ledger journal posting operations and the sales-order confirm, packing-slip and invoice operations. Any other operation whose request contract carries PreviewMode gets the flag set and refuses the run with PreviewUnsupported, so nothing runs. Only for a request contract without PreviewMode (for example the async submission, submitAsyncOperation) is the flag silently ignored and the operation runs for real. Check the operation against the list in Posting preview before you rely on it, and treat an operation whose request has no PreviewMode on a production-like environment as a live run.

How to verify. A preview returns a response carrying the preview block described in Posting preview and writes no document. A real run produces the document, and the call appears on Service call statistics after the next rollup.

When it does not work. "No metadata found for operation …" means the service metadata refresh has never run for that operation - click Refresh metadata on the Service metadata explorer, let the job finish, and try again. Payload shapes are in Endpoint payload specification; the operation catalog is browsable on the Service metadata explorer (System administration > Inquiries > Lattice > Services), which also exports Postman and OpenAPI artifacts and per-operation Download request / Download response samples.

---

Tuning how much an operation logs

Goal. Reduce call-log volume for a chatty operation, or keep more history for one under audit.

The grid is empty by design. An operation with no row here is logged at level All - every call is persisted - using the global retention window. Add a row only to change that for one operation.

Click path

1. Go to System administration > Setup > Lattice > Service operation logging configuration.
2. Click New on the action pane.
3. Fill Service and Operation with the operation you are tuning.
4. Set Logging level to All, Errors only or Off.
5. Optionally set Retention (days) for a per-operation window; leave it at zero to inherit the global default.
6. Click Save.

To return an operation to the default, select its row and click Delete on the action pane.

What the levels do:

Column	Effect
Logging level = All	Persist every call (the default)
Logging level = Errors only	Persist only failed calls
Logging level = Off	Persist nothing for this operation
Retention (days)	A per-operation window; leave it at zero to inherit the global default

How to verify. Run the operation, then look for the call on Service call statistics after the rollup. Note that the statistics rollup aggregates the call log, so an operation set to Off stops contributing rows to the raw log - reducing logging reduces what you can report on later.

When it does not work. Retention is enforced by the daily Lattice integration log cleanup background process (MGCLatticeServiceLogCleanup); a shortened window has no effect until it runs.

---

Reviewing service call activity

Goal. See throughput, failures and latency per operation without querying the raw log.

Click path

1. Go to System administration > Inquiries > Lattice > Services > Service call statistics.
2. Type a service name into the quick filter above the list to narrow it to one service.
3. Read the row for the operation and date you care about.
4. If you need today's numbers before the daily run, click Service call statistics rollup on the action pane and complete the dialog. It runs the same job as the Lattice service call statistics rollup background process listed under The jobs that must be running, once, now.

Each row is one operation on one Date, with Calls, Successes, Failures, Total duration (ms), Minimum duration (ms), Maximum duration (ms), Average duration (ms) and Last call.

Read failures here first, then open Service call log (same submenu, or the Failed service calls (24 h) tile on the integration operations workspace) for the individual calls behind them - each row carries the Status, Error code, Message, the Posted document, the User context the caller sent (for information only), the user the call ran as (Created by) and the Request ID / Correlation ID you need to trace one request; calls that were answered without running - a repeated request ID, a request still in progress, a license refusal - are listed too - and the operations console for the dead-letter items they produced.

---

Publishing the API surface to Azure API Management

Goal. Produce the Azure API Management artifacts for the endpoints you want to expose.

Click path

1. Go to System administration > Setup > Lattice > APIM configurator. Select an existing publication profile in the list, or click New to create one; the header carries Profile name and Description.
2. Fill the FastTabs: Target (Default product, Subscription required, Include OData API and OData API name), Output formats (Bicep templates, APIOps artifacts, ARM templates), Default policy (Validate JWT, Rate limit and quota, Backend authentication, IP restriction, CORS, Application Insights logging) and Rate limits. Hover a check box for what it does. The Default policy applies to every API of the profile.
3. Add the child records on their tabs with New and Delete: APIM profile API (which APIs the profile publishes), APIM profile endpoint (tick Excluded to leave an endpoint out), APIM profile policy (overrides for one product, API or operation; a scope is required) and APIM profile environment (per environment: Environment tier - a name such as dev, test, uat or prod, using letters, digits and hyphens - with the APIM instance, resource group, backend URL and credentials; the backend client secret field takes only the Azure Key Vault URI of the secret, never the secret itself).
4. Click Save.
5. With the profile still selected, click Validate. The result is reported to the infolog - it checks the profile against the live metadata, so run it after any metadata refresh.
6. Click Generate bundle to build the artifact bundle and download it as a ZIP.

How to verify. Validate reports cleanly and the generated ZIP contains the formats you selected. Deploying the bundle into Azure is outside F&O and outside this guide.

When it does not work. Both actions require a profile to be selected; with no selection they warn and stop. Profile name and API name cannot be changed after the record is saved; deleting a profile deletes its APIs, endpoints, policies and environments, and deleting an API deletes its endpoints. To export every profile at once, click APIM bundle bulk export on the action pane instead.

---

Granting and revoking just-in-time database access

This is the highest-risk action in the product. It provisions a real, temporary db_owner login on AxDB and opens a firewall rule for one IP address. It is granted only by the Database access administrator role, deliberately separate from the integration roles. Read the dedicated section in Security model before using it, and treat every grant as an auditable event.

Click path - grant access

1. Go to System administration > Inquiries > Lattice > Database access > Database access grants.
2. Click Request access on the action pane.
3. Enter the public IPv4 address that will connect, and confirm the dialog.
4. Copy the credentials from the infolog immediately - they are not shown in the list. Until the grant expires, Show password can show them again (below).
5. Confirm the new grant appears in the list with its Database user, IP address, Requested by, Issued, Expires and Status (dates and times in your time zone).

Requesting a grant revokes every active grant you already hold - one active grant per administrator. If one of them cannot be revoked at that moment, you see a warning; it stays active until the expiry sweep revokes it, and the new grant is still issued. The lifetime defaults to 24 hours and is clamped to between 1 and 72 hours.

Click path - retrieve a credential again

1. Go to the same page and select the active grant in the list.
2. Click Show password on the action pane, and read the credentials from the infolog.

Show password works only while the grant is active and before its Expires time. After that it is refused, even if the expiry sweep has not yet revoked the grant. The password is stored encrypted with the platform encryption service, so any server of the environment can show it.

Click path - revoke a grant early

1. Go to the same page and select the grant in the list.
2. Click Revoke on the action pane.
3. Click Yes on the confirmation prompt. The database user's open sessions are ended, the user and the firewall rule are dropped, the row is marked revoked, and its stored password is cleared.

When a revoke fails. A warning says the grant could not be revoked now. The grant stays Active, with Expires moved to now, because its database user may still exist; the next expiry sweep retries the revoke and marks the grant Expired.

How to verify. The grant's Status is active and Expires is what you expect; after a revoke the status is revoked. Grants expire only when the expiry sweep runs after their Expires time. The sweep is System administration > Periodic tasks > Lattice > Run database access expiry sweep, granted by the same database access administrator privilege. Issuing a grant schedules a one-time sweep for its expiry (a job named Revoke expired just-in-time database access grants), and each sweep schedules the next one only while grants are still active, so grants expire on time with no setup and no job keeps running once no grant is active. An expired grant's stored password is cleared.

---

Setting the inbound order guardrails

Goal. Control what happens to sales orders that arrive through the integration.

Click path

1. Go to System administration > Setup > Lattice > Inbound order policy parameters.
2. On the Policy tab, set Inbound order policy enabled to Yes. Everything else is inert while this is off, which is the shipped default.
3. On the Price tolerance tab, set Price tolerance (%) and the Price hold reason applied when a line is priced outside that tolerance. Set Price hold code too if the hold should also be a standard order hold.
4. On the Confirmation tab, set Auto-confirm hold-free orders and the Post-confirmation edit lock (minutes) that blocks edits for a period after confirmation.
5. Optionally, on the Customers page, add a row for a customer whose orders need other values, and set its Enabled. An enabled row replaces the tolerance, hold and confirmation settings for that customer; the policy switch itself stays the legal entity's.
6. Click Save.
7. Schedule MGCLatticeInboundOrderPolicyEvaluationBatch - see Scheduling a Lattice job as a recurring batch. Turning the switch on without scheduling that job changes nothing.

Click path - map a sales origin to a financial dimension

1. Go to System administration > Setup > Lattice > Sales-origin financial dimension mapping.
2. Select Sales-origin dimension stamping enabled above the grid to turn stamping on in the current legal entity. Click New on the action pane.
3. Pick Sales origin, Financial dimension and Dimension value from their lookups. A value that does not exist for the chosen dimension is refused when you save.
4. Click Save. To stamp a value for another dimension on the same origin, add another row.

The mapping is applied by a trigger on order creation, not by a batch job, so it takes effect on the next order that arrives with that sales origin. Every dimension mapped to the origin is stamped. If a mapped value is deleted later, the order is still created and only that dimension is left unstamped. Deleting a sales origin deletes its rows on this page.

Stamping has its own switch. Nothing is stamped until Sales-origin dimension stamping enabled, the check box above the grid on the same page, is selected. It is off by default and set per legal entity; until it is selected, the mapping rows have no effect.

---

Turning off an asynchronous operation

Goal. Stop callers from submitting a particular service operation for asynchronous processing, for example while a posting problem in that area is investigated.

The operations that can run asynchronously are part of the product, and each needs its own processing code. You cannot add one, but you can switch a shipped one off and on again. The registry ships these rows:

Service	Operations
MGCLatticeFixedAssetService	runDepreciationProposal, postAcquisition, postDisposal, postAssetTransaction
MGCLatticeCurrencyRevaluationService	runCustomerRevaluation, runVendorRevaluation, runLedgerRevaluation
MGCLatticeInventoryCostService	activatePendingPrices, calculateItemCosts
MGCLatticeGeneralLedgerJournalService	postGeneralJournal, postIntercompanyJournal, reverseJournal
MGCLatticeJournalPostingService	postLedgerJournal, postInventoryJournal, postProjectJournal, postProductionJournal, postTradeAgreementJournal
MGCLatticeBudgetRegisterService	postBudgetEntry, postBudgetTransfer

Click path

1. Go to System administration > Setup > Lattice > Async operation registry.
2. Find the row by Service and Operation.
3. Clear Enabled to switch it off, or select it to switch it back on. It is the only column you can change.
4. Click Save.

What changes

• A new submission of a disabled operation is refused at once with a message that says it is disabled. Nothing is queued, so the caller can call the operation synchronously instead.
• A submission that was queued before you switched it off is not run. Its async operation status becomes Failed with the reason, and the item is Parked in the dead-letter queue. Once the operation is enabled again, replay it from Integration operations console if it is still wanted.
• Updates to Lattice add new operations enabled and never switch back on one you disabled. The registry fills itself: the first time it is read after an update (opening this page, or the next async submission), its default seeding (populateDefaults) inserts any shipped row that is missing, enabled. Only missing rows are inserted; existing rows, including the Enabled setting you chose, are left as they are, so an existing environment needs no setup step for a newly shipped operation.

Access to the target operation. Submitting an async operation also needs access to the operation it runs, the same access a direct call needs. Before the operation runs, the processor checks that the user who submitted it still has that access; if not, the operation is set to Failed and parked in the dead-letter queue. Replaying it from the console needs that access too, for you or for the owner of the retry sweep batch job. Fixed asset disposals, intercompany journals, journal reversals and pending price activations need the administrator role; the per-operation privileges are in Security model.

How to verify. Reopen the page: Enabled is cleared on the row. The next submission of that operation returns Success false with the disabled message.

---

Letting callers send their own keys

Goal. Let an integration send the key its own system uses for a record (a shop's order number, a CRM's account id) instead of the D365 id.

Lattice services accept an ExternalSystem member and ...ExternalKey members next to the ids they take, and resolve the key to the D365 id before the operation runs. For that to work, the external system must exist (System administration > Setup > Lattice > External systems) and the record must hold an alternate key for it, entered on the record's Cross references page or loaded through the cross-reference data entities. A key that does not resolve fails the call with ValidationFailed, which shows up in the daily check like any other failed call.

Setup, the record kinds covered, the pages, the entities and the service members are in Cross-reference keys.

---

Standard procedures

These two are ordinary Finance and Operations procedures rather than Lattice pages, but every task above depends on one of them. They are written out once here.

Assigning a Lattice role to a user

Click path

1. Go to System administration > Security > Assign users to roles.
2. Select the Lattice role in the list on the left - the four are named in The role you need above.
3. Click Manually assign / exclude users.
4. Select the user in the list.
5. Click Assign to role.

How to verify. The user appears in the role's assigned users, and the pages that role grants open for them. Role assignment is a security change: see Security model for which role is appropriate, and treat the database access administrator role as the exception that should stay unassigned.

Changing a background process

The Lattice background processes in The jobs that must be running schedule themselves; change one only when its default does not suit you.

Click path

1. Go to System administration > Setup > Process automations and open the Background processes tab. The Lattice processes are named Lattice ....
2. Select the process and click Edit to change how often it runs, when it runs next, or a time range in which it sleeps. Switch it off on the same page to stop it.

How to verify. The process's results list each run (a run with nothing to do creates no batch job, so the reconciliation processes show runs only when they had work). The batch jobs the framework creates are named after the process, in System administration > Inquiries > Batch jobs.

Do not schedule the same job as a recurring batch as well. The runs duplicate each other, and the workflow alert scan remembers what it reported, so a second scan with another threshold reports the same items again. A background process runs each job with the defaults of its dialog; to run one with other values on a schedule, switch its background process off and schedule the job as below.

Scheduling a Lattice job as a recurring batch

The jobs that are not background processes (the inbound order policy evaluation, the metadata refreshes, the file ingestion pull and segment processor), and any job whose background process you switched off, are action menu items, so they are all scheduled the same way.

Click path

1. Go to System administration > Periodic tasks > Lattice, and click the job you want to schedule. The service metadata refresh is not on that menu: click Refresh metadata on the Service metadata explorer, which opens the same kind of dialog.
2. In the dialog, expand Run in the background and set Batch processing to Yes.
3. Set Task description to something you will recognize in the batch list, and pick a Batch group if your environment uses them.
4. Click Recurrence, set the pattern and its start time, and click OK.
5. Click OK on the dialog to create the batch job.

How to verify. Go to System administration > Inquiries > Batch jobs and confirm the job is listed and its status moves on its schedule. If a queue looks frozen, this is the first place to look.

Running a job once, now, is the same dialog with Batch processing left at No - useful when you want a rollup or a refresh immediately rather than at the next run of its background process.

---

Reading the states

Dead-letter status

Status	Meaning	Your action
Retrying	In the automatic retry lifecycle; Next retry says when	Usually none - let the sweep work. Hold it if you need it to stop.
Parked	Attempts are exhausted, or a manual resubmit failed	This is the backlog that needs a person. Diagnose, then Fix and resubmit, Retry now, or Discard.
Held	An operator took it out of the sweep	Release it when your investigation is done.
Reprocessed	Replayed successfully	None - terminal.
Discarded	An operator ended it deliberately	None - terminal.
Requeued	A file ingestion record was queued again by a resubmit or retry; its outcome is pending	None. It becomes reprocessed when the record is processed, or parked again if it fails.

An item that fails again after it was reprocessed, discarded or requeued is reopened (retrying or parked, with Attempts increased) rather than added as a second item.

Failures are also categorized. Error category is Connection (the target or network), Format (the payload could not be read), Data (the payload was read but the content was rejected) or Configuration (missing setup, an invalid license, a missing privilege, or an operation an administrator turned off) - which maps onto: retry it, fix the template, fix the data, fix the setup.

Segment state (one record inside an ingested file)

State	Meaning	Your action
Queued	Waiting for the segment processor	If it does not move, check that the segment processor job (Process file ingestion segments, at System administration > Periodic tasks > Lattice) is running.
Processed	Dispatched successfully; Request ID is the request it was sent with	None. A warning in the ingestion log that the record "was answered from an earlier request" means nothing was posted again: check that the template's request key is unique per record.
Failed	Dispatch failed; Error message says why	Follow it into the dead-letter queue.
Held	An operator excluded it from reprocessing	Release it from the file ingestion monitor.

An ingested file (bundle) is complete when all its segments are Processed; the cleanup removes it after the connection's retention period.

Recurring data job health

A job's health is the worst state any of its reasons gives. The thresholds are the job's own Health thresholds or, at 0, the defaults shown in brackets.

Health	Meaning	Your action
Broken	The job is active but cannot run as configured: a batch job is missing, on hold, in error, ended or canceled; an import job has no enabled client application; or the data project has mapping errors	Repair for a batch job problem, enable or add a client application, or fix the mappings. A deleted batch job needs the job to be created again.
Failing	Messages failed in the failure window (24 hours), at least as many as the failure threshold (1)	Open the failed message's Row errors, fix the data or mapping, and have the file submitted again.
Warning	The oldest waiting message is older than the backlog age (three recurrence intervals, at least 15 minutes); as many messages as the failure threshold were processed with failed rows; a message has been processing longer than the stuck period (60 minutes); or no message arrived within the silence period (off unless set). For an inactive job, any waiting message	Read Reasons. Waiting messages on an inactive job are processed only after Activate.
Healthy	Active, with no reason	None.
Inactive	Not active, and nothing is waiting	None, unless the job should be running.

---

What this guide does not cover

Topic	Where it lives
Privileges, duties, roles, and the database-access risk detail	Security model
Request and response payload shapes	Endpoint payload specification
Preview fidelity, guarantees and which operations qualify	Posting preview
External systems, cross-reference keys and the ...ExternalKey request members	Cross-reference keys
Business events and their catalog	the business events operator guide
Data entities and coverage analysis	the data entities operator guide
End-to-end walkthroughs of a whole business outcome	Using Lattice end to end