Skip to main content

Integration operator: what you do and where

You watch the integrations every day, notice what failed, find out why and get it moving again. Assign the Integration operator security role. You will spend most of your day in the Integration operations workspace and the Integration operations console, with Recurring integration health for the data management recurring data jobs. The operator role sees everything it monitors, but the actions that change a failed item (retry, hold, release, discard, fix and resubmit, closing an idempotency claim, repairing a recurring data job) belong to the Integration administrator role. Each goal below says which role it needs, so you know when to hand an item over. The last section covers the Integration read-only role.

Every day​

I want to see at a glance whether integrations are healthy​

Where: the Integration operations workspace. Open it from the default dashboard or the Workspaces list in the navigation pane, or go to System administration > Inquiries > Lattice > Integration operations > Integration operations.

  1. Read the nine count tiles in the Summary section: Dead letters awaiting action, Failed service calls (24 h), Inbound orders on hold, Stale idempotency claims, Claims needing manual reconciliation, Unresolved business event errors, Recurring jobs failing or broken, Recurring jobs with a backlog and Silent recurring jobs. A healthy environment shows zero, or a number you know and that is falling. Inbound orders on hold falls as the price holds on those orders are cleared.
  2. Select a tile that needs attention. It opens the page behind it, filtered to the rows that need you.
  3. Expand Recent activity and click through its tabs: Dead-letter queue, Recent service calls, Idempotency claims, Business event log and Inbound order policy state. Each list is newest first; double-click a row to open the full page.

Needs: Integration operator. More: Page reference: Integration operations, what each tile means.

I want to do the daily check​

Where: the Integration operations workspace and the pages in its Links section.

  1. Read the workspace tiles, as in the goal above.
  2. Open Integration operations console from Links and read the Queue status line beside the filter: the number of retrying, parked and reprocessed items and the age of the oldest parked item. A parked count, or an oldest-parked age, that keeps growing needs a person.
  3. Open Recurring integration health and select Needs attention only.
  4. Open Service call statistics and compare yesterday's Failures and Average duration (ms) for each operation with what you usually see.
  5. If you receive files, open Inbound message inquiry: the Bundles tab should show recent Received times, and the Segments tab records reaching Processed.

Everything in the check is read-only. The operator guide's file step uses the File ingestion operations workspace, which needs the Integration administrator role; Inbound message inquiry shows the same files and records.

Needs: Integration operator. More: The daily check.

I want to check call volumes and error rates​

Where: System administration > Inquiries > Lattice > Services > Service call statistics.

  1. Type a service name in the filter to narrow the list.
  2. Read the row for the operation and Date: Calls, Successes, Failures, Minimum duration (ms), Maximum duration (ms), Average duration (ms) and Last call.
  3. A Failures count that is suddenly above zero, or an average duration that jumps, points at the operation to look at. Open Service call log for the individual calls.

The rows are built once a day by the Lattice service call statistics rollup background process, so recent calls appear after its next run. An Integration administrator can build them now with Service call statistics rollup on the page.

Needs: Integration operator. More: Reviewing service call activity, Page reference: Service call statistics.

I want to check that the Lattice background processes ran​

Where: System administration > Setup > Process automations, Background processes tab (a standard page).

  1. Find the processes whose names start with Lattice, for example Lattice dead-letter retry, Lattice idempotency reconciliation, Lattice business event reconciliation, Lattice service call statistics rollup, Lattice integration log cleanup and Lattice recurring data job health alerts.
  2. Select one and choose View most recent results. A run with nothing to do creates no batch job, so the reconciliation processes show runs only when they had work.
  3. To see the batch jobs a process created, go to System administration > Inquiries > Batch jobs and look for jobs named after the process.
  4. Signs that a process is not running: dead letters stay Retrying long after their Next retry (dead-letter retry), Service call statistics stays empty (statistics rollup), the recurring job tiles never change (recurring data job health alerts).

Three jobs are not background processes and must be scheduled by an administrator: Run file ingestion (without it, no new files arrive), Process file ingestion segments (without it, file records stay Queued) and Inbound order policy evaluation (without it, orders stay Pending).

Needs: access to the standard Process automations and Batch jobs pages, which the Lattice roles do not grant. Changing a process needs an administrator. More: The jobs that must be running, Changing a background process, Scheduling these three jobs.

When a call fails​

I want to find the inbound calls that failed​

Where: the Failed service calls (24 h) tile on the Integration operations workspace, or System administration > Inquiries > Lattice > Services > Service call log.

  1. Open the tile. The log opens filtered to the calls that failed in the last 24 hours, newest first.
  2. To look further back, open the log from the menu and filter Success or Status, and Start date/time.
  3. Group the failures by Operation and Error code to see whether one operation or many are failing, and read Legal Entity and Message.
  4. Failed asynchronous operations and file records also land in the dead-letter queue: see I want to see what is in the dead-letter queue and why.

Needs: Integration operator. More: Page reference: Service call log.

I want to see why a call was refused​

Where: System administration > Inquiries > Lattice > Services > Service call log.

  1. Find the call: filter Request ID if the caller gave you one, otherwise Service, Operation and Start date/time.
  2. Read Message: the outcome summary the caller received.
  3. Read Error details: the reasons, the response's error messages separated by semicolons. It is empty when the call returned none.
  4. Read Error code for the kind of failure, for example Validation failed (the request needs fixing), Business rule (Finance and Operations refused to create or post the document), Transient runtime error (safe to retry), Duplicate request, Request in progress or Request needs review (answers about the request ID, see the next goals), Product license is not valid or Operation disabled.
  5. Preview is set when the call ran in preview mode and posted nothing.

Calls that were answered without running (a repeated request ID, a request still in progress, a license refusal) are in the log too. A call refused by Finance and Operations security (HTTP 403) never reaches Lattice and is not in the log: check the roles of the user that the caller's application is mapped to on System administration > Setup > Microsoft Entra ID applications.

Needs: Integration operator. More: Error handling, error codes.

I want to trace one request end to end​

Where: Service call log, Service idempotency log and Inbound message inquiry.

  1. Get the request's Request ID or Correlation ID from the caller, or from the failed call.
  2. In System administration > Inquiries > Lattice > Services > Service call log, filter Request ID. Every call made with that ID is listed, including repeats that were answered without running again. Correlation ID and Execution ID tie each row to the caller's own logs.
  3. In Service idempotency log (same menu), filter Request ID to see the claim: Status, Reconciliation state, Document table, Document ID and Legal Entity say what the request created.
  4. If the request was submitted asynchronously, open System administration > Inquiries > Lattice > Integration operations > Inbound message inquiry, Async operations tab, and find its Tracking ID.
  5. If it came in a file, follow it on the Bundles, Segments and Dead letter tabs, as in I want to follow a file from arrival to posting.

Needs: Integration operator. More: Tracing an inbound message end to end.

I want to check whether a request was a duplicate​

Where: System administration > Inquiries > Lattice > Services > Service idempotency log.

  1. Filter Request ID.
  2. Status Succeeded: the request ran once. A repeat with the same request ID got the recorded result back and posted nothing; the repeat still appears in Service call log.
  3. Status Processing: the first request is still running, or it stopped part way. A repeat got Request in progress (retry later) or, once the claim is older than 60 minutes, Request needs review.
  4. No row: the request failed (a failed claim is removed so the caller can send it again), or it never arrived.

A request ID belongs to the operation that first used it: sending it to another operation is refused with Duplicate request.

Needs: Integration operator. More: Duplicate RequestId, Post a journal exactly-once.

I want to close a claim that is stuck in processing​

Where: the Stale idempotency claims and Claims needing manual reconciliation tiles, or System administration > Inquiries > Lattice > Services > Service idempotency log.

  1. Open the tile. Stale claims are still Processing after more than an hour. Claims needing manual reconciliation were parked by the Lattice idempotency reconciliation background process with Reconciliation state Manual review required.
  2. For each claim, open the document named by Document table and Document ID in its Legal Entity.
  3. If the document exists and is posted, an administrator selects the claim and chooses Mark succeeded. A repeat of the request then gets the recorded result instead of posting again.
  4. If the request committed nothing (or what it created was reversed or deleted), an administrator chooses Release claim. The claim is deleted and the caller can send the same request ID again.

Needs: Integration operator to find and check the claims; Mark succeeded and Release claim need the Integration administrator role and are not shown to other users. More: Idempotency reconcile runbook, Page reference: Service idempotency log, The administrator's side.

I want to check an asynchronous operation​

Where: System administration > Inquiries > Lattice > Integration operations > Inbound message inquiry, Async operations tab.

  1. Find the operation by the Tracking ID the caller received, or by Service and Operation.
  2. Read Status (Queued, Processing, Succeeded or Failed), Submitted time, Completed time and Message.
  3. Choose Download request payload to see what was submitted.
  4. A failed operation is also in the dead-letter queue: the Dead letter tab, Source Async operation.

The caller can read the same status with the getAsyncOperationStatus operation. Each submission runs as its own batch job, so operations that stay Queued point at the batch server.

Needs: Integration operator. More: getAsyncOperationStatus, Send many requests at once, or run long work asynchronously.

I want to check which key an external system uses for a record​

Where: the Cross references button, or the Cross references FactBox, on the record's standard page, for example Customers or Sales order.

  1. Open the record.
  2. Choose Cross references to see one row per External system with its External key and Key kind, or read the FactBox.
  3. A call that sent an external key with no match fails with Validation failed: compare the key in the request with the keys the record holds. Only Alternate key rows match; a Historical key never does.

The button and FactBox appear only when an external system is set up as visible on forms for that kind of record. System administration > Setup > Lattice > External systems lists the systems.

Needs: Integration operator, read only, plus your usual access to the standard page; adding or changing keys needs the Integration administrator role. More: Cross-reference keys on the pages, Use external keys.

When a message is dead-lettered​

I want to see what is in the dead-letter queue and why​

Where: the Dead letters awaiting action tile, or System administration > Inquiries > Lattice > Integration operations > Integration operations console.

  1. Open the tile. The console opens filtered to items that are Retrying, Parked or Held.
  2. Read Queue status, then each row's Source (Async operation or File ingestion), Service, Operation, Error category, Error code, Status, Attempts, First failed and Next retry.
  3. Select a row and choose View payload to see the original payload and the failure message. Who viewed which item is sent to Application Insights as a Lattice.ReadAudit event, only when the environment's monitoring and telemetry is set up to send there; no page shows it. View payload is the way to read a payload with the operator or read-only role: the LatticeIntegrationDeadLetters entity gives these roles the dead letters without OriginalPayload and EditedPayload.
  4. Let Error category guide the fix: Connection (retry once the target is back), Format (the payload could not be read), Data (the content was rejected), Configuration (missing setup, license or privilege, or an operation that was turned off).

Retrying items are retried automatically: first after 60 seconds, then at doubling intervals up to an hour, and parked after 5 attempts. Parked items need a person.

Needs: Integration operator. More: Dead-letter status, Page reference: Integration operations console.

I want to look up what an operation expects​

Where: System administration > Inquiries > Lattice > Services > Service metadata explorer.

  1. Filter the tree and select the operation named by the item's Service and Operation.
  2. Read Request schema (Sample request (JSON) and Sample request (XML)) for the members the operation expects, and Response schema for what it returns. The values are placeholders, not real data.
  3. Compare the request with what View payload showed for the item. The payload of an asynchronous operation is the object that the JSON sample shows inside _request. A file record's payload is the record as the partner sent it: compare the schema with Produced contract in the File ingestion simulator instead.
  4. Before you hand the item over, note what differs: a missing member, a misspelled name or a value of the wrong type.

If the operation is missing or out of date, ask an Integration administrator to choose Refresh metadata.

Needs: Integration operator or Integration read-only; the simulator needs Integration operator. More: Review the contract of a service operation, Endpoint payload specification, The administrator's side.

I want to retry, hold, release or discard a dead-lettered message​

Where: System administration > Inquiries > Lattice > Integration operations > Integration operations console.

  1. Select the item and read View payload first.
  2. Choose the action:
    • Retry now when the cause was temporary and is fixed. The item becomes due at once and the retry process picks it up on its next run.
    • Hold to stop automatic retries while you investigate.
    • Release to return a held item to retrying.
    • Discard when the message must never be processed, for example a duplicate or a test.
  3. Choose Refresh to re-read the list and Queue status.

A replay reuses the original request ID, so a message that in fact posted is not posted twice.

Needs: Integration administrator. An Integration operator sees the buttons, but they are refused with "You are not authorized to operate the integration dead-letter console", so hand the item to an administrator with what View payload showed. More: Recovering a failed integration message, The administrator's side.

I want to fix a bad payload and resubmit it​

Where: System administration > Inquiries > Lattice > Integration operations > Dead-letter fix and resubmit.

  1. Select the item. The header shows its Error code and Failure message.
  2. On the Payload tab, read Original payload (kept as evidence) and type the correction in Edited payload.
  3. Choose Fix and resubmit and confirm. An asynchronous item runs at once and ends Reprocessed, or Parked if it fails again. For a file record, your correction replaces the stored record and the item becomes Requeued until the segment processor has processed it.

Only a retrying, parked or held item can be resubmitted. Before you hand a file record to an administrator, you can try the correction yourself in the File ingestion simulator.

Needs: Integration administrator; the Integration operator role cannot open this page. More: Fixing a bad payload and resubmitting it, The administrator's side.

I want to follow a file from arrival to posting​

Where: System administration > Inquiries > Lattice > Integration operations > Inbound message inquiry.

  1. On Bundles, find the file by Source file name and note its Bundle ID. Download bundle payload gives you the file as received.
  2. On Segments, filter Bundle ID. There is one row per record, with State (Queued, Processed, Failed or Held), Processing attempts and Error message. Download segment payload gives you one record as received.
  3. On Dead letter, find the failed records (Source File ingestion) with their Status and Attempts.
  4. Records that stay Queued usually mean the Process file ingestion segments job is not running, not that the data is bad.

A record is tried up to 3 times, then marked Failed and parked in the dead-letter queue; replaying it from there queues it again. The File ingestion monitor (with its log and the Hold and Release actions) and the File ingestion operations workspace need the Integration administrator role.

Needs: Integration operator. More: Tracing an inbound message end to end, Inbound file to posted document, File ingestion user guide.

I want to test a corrected record without posting anything​

Where: System administration > Inquiries > Lattice > File ingestion > File ingestion simulator.

  1. On Input, set Connection ID to the connection the file came in on.
  2. Paste the record, or the whole file, into Raw payload.
  3. Choose Run.
  4. On Results, read each step's Succeeded and Message, then Produced contract (what would be sent) and Response (the preview's response).

Nothing is posted: the operation is called in preview mode when it supports preview, and otherwise only the request is checked. To keep a payload for later, store it on System administration > Setup > Lattice > File ingestion > Sample payloads and use Replay. To try a service request rather than a file record, the Service test console needs the Integration administrator role; from your own client you can send the request in preview mode to an operation that supports it.

Needs: Integration operator. More: Page reference: File ingestion simulator, Posting preview.

Recurring data jobs​

I want to see which recurring data jobs need attention​

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

  1. Open a tile, or open the page and select Needs attention only.
  2. Read Health (Broken, Failing, Warning, Healthy or Inactive) and Reasons (the worst reason, and how many more).
  3. Read the signals: Waiting messages, Oldest waiting since, Failed messages, Stuck messages, Last message and Next run.
  4. The list shows the last evaluation, which runs every 15 minutes. Choose Refresh health for the selected jobs, or Refresh all, to evaluate now.

Needs: Integration operator. More: Watching recurring integrations, what each health state means.

I want to find the rows a recurring data job rejected​

Where: Recurring integration details: select the job on Recurring integration health and choose Recurring integration details, or click the job's name.

  1. On Messages, select Failed messages only (widen Period (days) if needed; 0 shows every message) and select the failed message.
  2. On Executions, read each entity's staging and target status and its error count.
  3. On Row errors, read the entity, the column, the error message and Staging row (the key fields and values of the failed row).
  4. Use Download file for the file the client application submitted, or Execution details and View staging data for the standard pages.
  5. Have the data or the mapping fixed at the source, then let the client application submit the file again. Lattice does not resubmit, skip or delete a message.

Download file works only while data management still holds the file in its temporary storage. The standard pages it opens follow their own security.

Needs: Integration operator. More: Page reference: Recurring integration details.

I want to repair or reactivate a recurring data job​

Where: Recurring integration health, or Recurring integration details for one job.

  1. Broken because a batch job is on hold, in error, ended or canceled: select the job, choose Repair and confirm.
  2. An inactive job with waiting messages: choose Activate. The job needs a schedule and an enabled client application.
  3. Broken because no client application is enabled: on the details page, Client applications, enable one or choose Add client application.
  4. Broken because of mapping errors: check the data project with the validateMappings operation, which the operator role may call; repairing with refreshMappings needs the administrator.
  5. Choose Refresh health and check that Job state is Active and the health is no longer Broken.

Repair cannot bring back a batch job that was deleted: the recurring data job must be created again.

Needs: Integration administrator; the Integration operator role does not see Activate, Deactivate, Repair or the client application actions. More: Watching recurring integrations, Validate and refresh data project mappings, The administrator's side.

I want to change when a recurring data job counts as unhealthy​

Where: the LatticeRecurringJobHealths entity over OData (operator), or the Health thresholds FastTab on Recurring integration details (administrator).

  1. Decide the values: Failure window (hours), Backlog age (minutes), Silence period (minutes), Stuck after (minutes), Failure threshold and Alerts enabled. For example, a silence period of 90 minutes for a job that must receive a file every hour.
  2. Update the job's row, keyed by JobName: the members are WindowHours, BacklogAgeMinutes, SilenceMinutes, StuckMinutes, FailureThreshold and AlertsEnabled. A value of 0 uses the default (24 hours; three recurrence intervals and at least 15 minutes; 60 minutes; 1), and a silence period of 0 switches the silence check off.
  3. Evaluate the job again with the entity's Refresh action, or Refresh health on the page.

Needs: Integration operator through the entity; on the page, Integration administrator. More: Recurring data job health entity.

Held orders and business events​

I want to see and release orders held by the inbound order policy​

Where: the Inbound orders on hold tile, or System administration > Inquiries > Lattice > Integration operations > Inbound order policy state.

  1. Open the tile. The list shows the orders whose Policy status is Held, with Sales order, Hold reason, Standard hold code and Evaluated. These orders carry the standard order hold the policy placed.
  2. Open the sales order and agree with the business whether its prices are right.
  3. To release it, clear that hold on Sales and marketing > Sales orders > Open orders > Order holds, as for any other order hold. The row changes to Released at once and the order leaves the tile. The next run of Inbound order policy evaluation confirms it when Auto-confirm hold-free orders is on (status Auto-confirmed); otherwise its status becomes Processed and you confirm it as usual. An order still on another standard hold is not confirmed automatically.
  4. Orders with the status Flagged were priced outside the tolerance but got no standard hold (no Price hold code is set, or the Advanced Order Hold status change feature is off). Nothing stops them and the tile does not count them: filter the list on Flagged, review each order, and confirm it yourself.
  5. Orders that stay Pending or Released have not been evaluated yet: the Inbound order policy evaluation job is not scheduled in this legal entity, or has not run since.

The Hold reason and Standard hold code stay on the row after the release. The tile and list show the legal entity you are working in.

Needs: Integration operator for the list; releasing a standard order hold needs your sales order permissions. More: Page reference: Inbound order policy state, Setting the inbound order guardrails.

I want to check that business events were sent​

Where: the Unresolved business event errors tile, or System administration > Inquiries > Lattice business events > Business event log.

  1. Open the tile, or filter Business event log status to Error.
  2. Read Status details (the publish error), Legal entity, Reconciliation state, Retry count, Last retry and Last replay error.
  3. Resolved: the Lattice business event reconciliation background process published the event again. Not reconciled: its next run tries again. Exhausted: the retries are used up, so fix the cause and send the event again from its source. Manual intervention required: the event cannot be replayed.

The log holds the events that opt in to Lattice logging: in this release the Retail assortment published event and the Business event publish failed alert. Other business events are not logged here, and delivery to your endpoint after publishing is handled by the standard business events framework.

Needs: Integration operator; running the reconciliation sweep by hand needs the Integration administrator role. More: Checking coverage and reconciliation.

Get told instead of looking​

I want to be alerted when something needs me​

Where: System administration > Setup > Business events > Business events catalog (a standard page).

  1. Find the Lattice alert events in the System administration category:
    • Integration item parked: a failed asynchronous operation or file record was parked in the dead-letter queue for manual review.
    • Recurring data job health changed: a recurring data job's health changed, for jobs with Alerts enabled.
    • Business event publish failed: a logged business event could not be published.
    • Workflow stalled or failed: a workflow faulted, or a work item waited too long.
  2. Select each one and choose Activate, with your endpoint (for example a Power Automate flow that notifies your team) and the legal entities. Activate Recurring data job health changed for all legal entities to hear about every job.
  3. For recurring data jobs, switch Alerts enabled on for each job you want to hear about, as in I want to change when a recurring data job counts as unhealthy.

Integration item parked carries the dead-letter ID, never the payload, so you can find the item in the console.

Needs: access to the standard business events catalog, which the Lattice roles do not grant. More: React to Lattice business events, Integration item parked, Recurring data job health changed, Recurring data job health alerts.

Integration read-only: what you can see​

Assign Integration read-only to someone who reviews integrations without operating them, such as an auditor or a support analyst. It opens the same monitoring pages as the operator: the Integration operations workspace and console (including View payload), Inbound message inquiry, Service call log, Service call statistics, Service idempotency log, Recurring integration health and its details, Inbound order policy state, Business event catalog, Business event log, Service metadata explorer, Table data and entity coverage and the cross-reference keys. It reads a failed message's payload only with View payload on the console, which records who viewed it; the LatticeIntegrationDeadLetters entity gives this role the dead letters without their payloads. It can call the status query operations. It cannot call any operation that posts or changes a document, and it has no recovery actions, no file ingestion pages (not even the simulator) and no service test console.

I want to review integration activity for a period​

Where: System administration > Inquiries > Lattice > Services > Service call log and Service call statistics.

  1. In Service call log, filter Start date/time to the period. Each row shows Service, Operation, Status, Success, Legal Entity, User Context (as the caller sent it), Preview (a preview run that posted nothing), Document ID and Message.
  2. In Service call statistics, read the daily Calls, Successes and Failures per operation.
  3. Before you rely on the log as complete, ask the administrator for the settings on Service operation logging configuration: an operation can be set to log only errors, or nothing, and to keep its rows for a shorter time. Even at All, some operations never write to the log: the status queries, resolveSalesPrice, setSalesPrice, the database access operations requestAccess and revokeAccess, and the data management operations such as applySpec, refreshMappings and validateMappings.

Needs: Integration read-only. More: Page reference: Service call log, Page reference: Service operation logging configuration.

I want to see who ran a call or acted on a failed message​

Where: the OData entities LatticeServiceCallLogs and LatticeIntegrationDeadLetters, for example https://<your-environment>/data/LatticeServiceCallLogs.

  1. In LatticeServiceCallLogs, CalledBy is the user the call ran as. UserContext is the user the caller named in the request, for information only.
  2. In LatticeIntegrationDeadLetters, LastActionedBy is the last user to touch the item: who chose Retry now, Hold, Release, Discard or Fix and resubmit, otherwise the user the failing run ran as.

Neither column is shown on the pages.

Needs: Integration read-only. More: Service call log entity, Dead-letter entity.

I want to keep a copy of what a partner sent​

Where: System administration > Inquiries > Lattice > Integration operations > Inbound message inquiry.

  1. Open the tab you need and select the row: Bundles (a file), Segments (one record of a file), Async operations (an asynchronous request) or Dead letter (a failed request).
  2. Choose the tab's download button: Download bundle payload, Download segment payload, Download request payload or Download dead-letter payload.

Payloads are kept only until the cleanup removes them: processed files after their connection's retention, and the other rows after the log retention.

Needs: Integration read-only. More: Page reference: Inbound message inquiry.

I want to check recurring data job health without changing anything​

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

  1. Read Health, Reasons and the signals.
  2. Open Recurring integration details for the messages, executions, row errors, client applications and the Health thresholds in use. The page is read-only for you.
  3. Refresh health and Refresh all are available to you. They evaluate the jobs again and change no job, but a health change they find raises Recurring data job health changed for jobs with alerts on.

Needs: Integration read-only. More: Page reference: Recurring integration health.

I want to read the integration logs from my own reporting tool​

Where: the Lattice OData entities, read with a Microsoft Entra application mapped to a user with the Integration read-only role.

  1. Read LatticeServiceCallLogs (calls), LatticeServiceCallStatistics (daily rollup), LatticeServiceIdempotencyLogs (claims), LatticeAsyncOperationTrackingRecords (asynchronous operations), LatticeIntegrationDeadLetters (dead-letter queue, without the OriginalPayload and EditedPayload fields, which only the Integration administrator role reads through the entity), LatticeFileIngestLogs (file ingestion log), LatticeRecurringJobHealths and LatticeRecurringJobMessages (recurring data jobs).
  2. These logs are shared by all legal entities, so you do not need the cross-company parameter.

Needs: Integration read-only. More: Entity reference, Recurring data job health entities.