Data entities - Operator Guide

Data entities is the entity surface of Lattice: a set of data entities that expose core ERP data through OData and the Data Management Framework, published under Lattice* collection names. This guide is for the person who runs that surface day to day - checking what is exposed, proving an entity's shape to an integration partner, and working out which tables an entity actually reaches.

Audience. A data or integration administrator working inside Finance and Operations. It assumes you can open System administration and have been assigned a Lattice role.

What is authoritative elsewhere. The entity list and per-entity metadata live in Entity catalog and Service catalog; the security model in Security model; the coverage analyzer's internals and limits in Table and entity coverage; the cross-reference key entities, which store other systems' keys for D365 records, in Cross-reference keys. This guide links down into those rather than repeating them.

---

Before you start

Two pages carry this pillar, and they are granted by different duties.

Page	Menu path	Privilege → duty → role
OData entity metadata explorer	System administration > Inquiries > Lattice > OData	MGCLatticeODataEntityMetadataExplorerPrivilege → MGCLatticeODataEntityMetadataExplorerDuty → MGCLatticeIntegrationAdministratorRole
Table data and entity coverage	System administration > Inquiries > Lattice data entities	MGCLatticeTableEntityCoverageView → MGCLatticeIntegrationServiceMonitoringDuty → MGCLatticeIntegrationAdministratorRole, MGCLatticeIntegrationOperatorRole, MGCLatticeIntegrationReadOnlyRole

The explorer is administrator-only. The coverage page is visible to the operator and read-only roles as well, because it is a read of the last snapshot; running a new snapshot is a separate privilege (MGCLatticeTableEntityCoverageAnalyzeExecute, which the administrator role holds through the batch maintenance duty MGCLatticeBatchMaintenanceDuty).

Publishing entities themselves - enabling an entity for OData, running imports and exports - is standard Finance and Operations work in the Data management workspace and is not covered here. The Lattice pages describe and analyze that surface; they do not configure it.

---

Browsing the OData surface

Click path - look up an entity's shape

1. Go to System administration > Inquiries > Lattice > OData > OData entity metadata explorer.
2. Type part of the entity name in the quick filter above the list. It filters on Entity name by default.
3. Select the entity's row in the list.
4. Open the Fields tab to read the field-by-field shape, or the Methods tab for the OData actions the entity exposes. The Details tab carries Entity table, Primary key and Description.

The page lists every public OData data entity discovered in the environment, not only Lattice's own. The list shows Entity name, Collection name (the name a client uses in the URL), Public entity name, Category, Module, Package, Custom, Fields and Obsolete. Use the quick filter above the list to narrow it - it filters on entity name by default.

Selecting an entity fills three tabs:

Tab	Shows
Details	Entity table, Primary key, Description
Fields	One row per field: Field name, Data type, Extended data type, Enum type, Label, Mandatory, Key, Allow edit, Obsolete, Position
Methods	OData actions on the entity: Method, Action name, Bound, Type, Parameters, and the parameter detail (Parameter name, Sequence, Type, Class name, Is contract)

The Fields tab is the quickest answer to "what must my payload contain?" - Mandatory and Key together give the minimum an insert needs, and Allow edit tells you what an update may change.

The catalog is a snapshot

The page reads a stored catalog, not live metadata. The Catalog status line beside the quick filter tells you how current it is: Not yet refreshed before the first run, otherwise Last refresh: n entities, n methods.

Click path - rebuild the catalog

1. Go to System administration > Inquiries > Lattice > OData > OData entity metadata explorer (or click the OData entity metadata explorer tile on the Data management workspace). The OData metadata button on the standard Data entities page opens the same explorer filtered to the entity selected there.
2. Click Refresh OData metadata on the action pane. The Refresh OData entity metadata dialog opens.
3. Expand Run in the background, set Batch processing to Yes, and click OK.
4. Close the page. The list does not change while you watch it.
5. Reopen the page when the batch job has finished and check the Catalog status line.

Choose Refresh OData metadata to rebuild it. The button opens the refresh's batch dialog, the same one System administration > Periodic tasks > Lattice > Refresh OData metadata opens. Run it in the background: enumerating every public entity in the application can take minutes and would otherwise block your session. Run with Batch processing No, the page waits until the refresh has finished and then shows the new Catalog status line and entity list.

Nothing refreshes the catalog automatically. After any deployment that adds, changes or removes entities, refresh the catalog (or schedule the refresh as a recurring batch job); otherwise the explorer and anything generated from it describe the previous state.

Generating a Postman collection or an OpenAPI specification

Click path - export the entities a partner will call

1. Go to System administration > Inquiries > Lattice > OData > OData entity metadata explorer.
2. Narrow the list with the quick filter to the entities you want.
3. Mark the rows - tick each row's selection box, or place the cursor on a single entity.
4. Click Postman for a Postman collection, or OpenAPI for an OpenAPI specification.
5. If you marked more than 200 entities, answer the prompt: Yes to continue, or No to go back and narrow the selection.
6. Collect the generated file from your browser's downloads.

Select the entities you want, then choose Postman or OpenAPI. Both generate documentation for the selected entities and download the file to your browser.

• Mark one or more rows in the list. If nothing is marked, the entity under the cursor is used.
• With nothing selected at all you get: Select one or more entities in the list, or place the cursor on an entity, and then choose the download action again.
• Selecting more than 200 entities prompts first: You selected n entities. The generated file may be large and slow to import. Continue? Say no and narrow the selection unless you genuinely want the bulk file.

Export the handful of entities a partner will actually call rather than the whole catalog - the full public surface produces a file most clients struggle to import.

Downloading the OData service and metadata documents

Click path - hand a partner the environment's own OData description

1. Go to System administration > Inquiries > Lattice > OData > OData entity metadata explorer.
2. Click OData service on the action pane.
3. Choose Service document (/data) for the list of entity sets, or Metadata document ($metadata) for the full metadata.
4. Collect odata_service_document.xml or odata_metadata.xml from your browser's downloads.

These are the documents the environment's OData endpoint itself returns: the service document is the XML a browser receives from /data, and the metadata document is /data/$metadata. You need no access token, app registration or HTTP tool to capture them. They ignore the list, its filter and any selection, and they do not read the catalog, so they work before the first Refresh OData metadata and always describe the environment as it is deployed right now.

The metadata document covers every public entity and is large - about 54 MB on a standard environment. If the AOS has restarted and nothing has called OData since, the first download waits while the environment builds its OData model, which takes a minute or more.

---

Checking table and entity coverage

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

This answers a question the entity list cannot: which tables hold data, and can I reach each one through a data entity? It is a planning aid for migration and gold-configuration work, not a routine job.

Running an analysis

Click path - take a new snapshot

1. Go to System administration > Periodic tasks > Lattice data entities > Analyze table data and entity coverage. The same action is on the coverage page's action pane if you already have it open.
2. In the Analyze table data and entity coverage dialog, set Count rows - leave it on to count records, clear it for a much faster metadata-only pass.
3. Set Maximum tables to cap the run, or leave it at 0 to process every eligible table.
4. To schedule it instead of running it now, expand Run in the background and set Batch processing to Yes, then set Task description, Batch group and Recurrence.
5. Click OK.
6. Go to System administration > Inquiries > Lattice data entities > Table data and entity coverage and click Refresh to pick the new snapshot up.

Choose Analyze table data and entity coverage. The dialog offers two options:

Option	Meaning	Cost
Count rows	Count physical records for each table. Clear to capture metadata only (much faster).	The dominant cost of a run
Maximum tables	Optional cap on the number of eligible tables to process. Leave 0 to process all tables.	Use a small cap for a quick sample

Count rows defaults to on, the expensive choice. Per-company tables are counted in the current company only. For a fast structural pass - coverage, scope and owning module without row counts - clear Count rows. The run reports Coverage snapshot n complete: analyzed n table(s), wrote n row(s). when it finishes, and can be scheduled as a batch job from the same dialog.

Each run writes a new, independent snapshot; runs do not overwrite each other. The page opens on the most recent one. Refresh re-reads the latest snapshot and refreshes the list, which is how you pick up a run that completed while the page was open.

Reading the result

Click path - find the migration gaps

1. Go to System administration > Inquiries > Lattice data entities > Table data and entity coverage. The page opens on the most recent snapshot.
2. In the View filter, choose Data, no entity to list tables that hold data but have no covering entity - the gap list.
3. Change View to Multiple entities to list tables several entities read, where you must pick one for an integration.
4. Change View to Non-empty tables to see only tables that hold rows, or All tables for everything in the snapshot.
5. Use the quick filter to jump to a particular Table name.

The list shows Snapshot run ID, Snapshot date and time, Table name, Row count, Shared table, Table group, Model or module, Has data entity, Covering entity count and Covering entities.

The View filter selects what you are looking for:

View	Use it to find
All tables	Everything in the snapshot
Data, no entity	Tables that hold data but have no covering entity - these cannot be moved through OData or the Data Management Framework without a new entity
Multiple entities	Tables several entities read - you must choose the right one for an integration
Non-empty tables	Only tables that actually hold rows

Data, no entity is the gap list for a migration; Multiple entities is the disambiguation list.

Trust the count, not the string. Covering entities is truncated for long lists while Covering entity count is not, so a table can show a count higher than the names listed. The truncation rule and the other limits of covering-entity resolution are documented in Table and entity coverage.

Temporary, view, map, system-generated and staging tables, and tables whose name ends in Tmp, are skipped - the snapshot is deliberately a list of real data-bearing tables.

---

Exporting a data entity template

System administration > Periodic tasks > Lattice data entities > Data entity template generates a document that describes an entity's shape for whoever has to populate it - the fields, data types, lengths, mandatory and key fields, allowed values, and optionally real sample rows.

Click path - generate a template

1. Go to System administration > Periodic tasks > Lattice data entities > Data entity template.
2. In the Export data entity template dialog, type the entity's AOT name in Data entity name. One entity per run.
3. Set Include live sample data to Yes if the recipient needs to see real, correctly-shaped values - read the warning below first.
4. If you enabled sample data, set Number of sample rows.
5. Choose the Output format: Excel workbook (.xlsx) for a fill-in template, or XSD schema (.xsd) for a machine-readable schema.
6. Click OK.
7. Collect the generated file from your browser's downloads.

Option	Meaning
Data entity name	The AOT name of one data entity. Pre-filled when launched from the Data entities list.
Include live sample data	Include real, correctly-shaped records read from the current environment so you can see the expected format for each field.
Number of sample rows	The number of live sample rows to include for each entity when sample data is enabled.
Output format	Excel workbook (.xlsx) for a fill-in migration template, or XSD schema (.xsd) for a machine-readable schema that validates data management XML-Element files for the entity

The file is streamed to your browser when generation completes. The export is also available directly from the standard Data entities list, where the entity names are filled in for you:

Click path - from the standard Data entities list

1. Go to Workspaces > Data management > Data entities (the standard DMFEntity list).
2. Select the entity in the grid.
3. On the action pane, in the Lattice group, click Export data entity template.
4. Data entity name is pre-filled with the target entity (AOT) name of the first marked row, or of the selected row when none is marked. Set the sample data and output format options as above and click OK.

The Data management workspace itself also carries two Lattice tiles: Data entity template opens the same dialog with Data entity name empty, and OData entity metadata explorer opens the catalog described above.

Sample data leaves the environment. Include live sample data copies real records from the current company into the workbook. Do not send a sampled template outside your organization from an environment holding production data.

Which entities you can export. The template accepts only data entities listed in Data management, and only when you have read access to the entity in Data management, the same check Data management runs before an export. Any other name is refused: Data entity … is not in the Data management entity list. Refresh the entity list in Data management and try again, or You do not have access to read data entity ….

Exporting entity data to Excel (wide)

The standard Export to Excel cannot handle an entity with more than 255 fields. Export entity data to Excel (wide) writes an entity's records to a workbook with one column per field instead.

Click path

1. Go to Workspaces > Data management > Data entities.
2. Select the entity in the grid.
3. On the action pane, in the Lattice group, click Export entity data to Excel (wide).
4. Data entity name is pre-filled. Optionally list field names in Fields (optional), separated by semicolons (blank exports every field), and set Maximum rows (optional) (0 exports every record, up to the Excel worksheet limit).
5. Click OK and collect the workbook from your browser's downloads.

The same rule as the template applies: only data entities listed in Data management that you can read there. The button needs the operator or administrator role (MGCLatticeWideEntityExcelExportPrivilege in MGCLatticeDataEntitiesMaintain). The workbook holds real records from the current company, so treat it like the sampled template above.

---

Keeping the picture current

Both pages read stored snapshots, so both go stale in the same way.

After you…	Do this
Deploy a package that adds or changes entities	Refresh OData metadata on the explorer
Deploy a package that changes an entity's staging table	Refresh entity list in Data management, then regenerate the mapping of each data project that uses the entity - see below
Load or purge significant data, or plan a migration wave	Run Analyze table data and entity coverage again
Complete a coverage run while a page is open	Choose Refresh on the coverage page

Nothing refreshes automatically: the OData catalog changes only when you refresh it, and the coverage snapshot changes only when you run the analysis. If the catalog predates your last deployment, treat what it shows - and anything exported from it - as describing the previous state. The OData service downloads are the exception: they read the model the environment serves now, not the catalog.

After an upgrade that changes staging tables

Data management keeps its own copy of each entity's fields and of the field mapping in every data project. When an upgrade adds or renames fields in an entity's staging table, both copies still describe the old table until you refresh them, and imports and exports skip the fields they do not know.

Click path - refresh the entity list

1. After the database synchronization, go to Workspaces > Data management and open Framework parameters.
2. Open the Entity settings tab.
3. Click Refresh entity list and wait for it to finish.

Click path - regenerate a data project's mapping

1. In the Data management workspace, open the import or export data project that uses the entity.
2. On the entity's row, click View map.
3. Click Generate source mapping, confirm, and save the mapping. Removing the entity from the project and adding it again has the same effect.

This release needs both steps for five entities whose staging tables were missing fields or still had old field names, so Data management imports and exports silently skipped those fields. OData was not affected.

Entity	Fields that were skipped
MGCLatticeSalesOrderLineEntity, MGCLatticePurchaseOrderLineEntity	Quantity, unit, requested date, site, warehouse and lot ID (the entity's key)
MGCLatticeCustomerContactPersonEntity, MGCLatticeVendorContactPersonEntity	The customer or vendor account and its company
MGCLatticePurchaseOrderConfirmationDocumentAttachmentEntity	The confirmation date

The cross-reference keys release needs both steps too. Twenty existing entities gained an ExternalSystem field and one or more ...ExternalKey fields, which accept an external system's key in place of a lookup value, and their staging tables gained the same columns. Until you regenerate the mapping, a data project ignores the new columns; the entities otherwise behave as before.

Entities whose staging tables gained cross-reference key columns
MGCLatticeSalesOrderLineEntity, MGCLatticePurchaseOrderLineEntity
MGCLatticeFreeTextInvoiceTemplateLineEntity, MGCLatticePaymentRequestEntity, MGCLatticeVendorContactPersonEntity
MGCLatticeCustomerDocumentAttachmentEntity, MGCLatticeVendorDocumentAttachmentEntity, MGCLatticeProjectDocumentAttachmentEntity, MGCLatticeProductionOrderDocumentAttachmentEntity, MGCLatticeFreeTextInvoiceDocumentAttachmentEntity
MGCLatticeSalesConfirmationDocumentAttachmentEntity, MGCLatticeSalesPackingSlipDocumentAttachmentEntity, MGCLatticeSalesInvoiceDocumentAttachmentEntity
MGCLatticePurchaseOrderConfirmationDocumentAttachmentEntity, MGCLatticePurchasePackingSlipDocumentAttachmentEntity, MGCLatticePurchaseReceiptsListDocumentAttachmentEntity, MGCLatticePurchaseInvoiceDocumentAttachmentEntity, MGCLatticePurchaseOrderLineDocumentAttachmentEntity
MGCLatticeTransferOrderDocumentAttachmentEntity, MGCLatticeTransferOrderLineDocumentAttachmentEntity

The same release adds 33 cross-reference entities (Lattice<Record>CrossReferences), one per record kind; Refresh entity list makes them available to data projects. What they hold and how keys are used is in Cross-reference keys.

---

Setting up a recurring data job from an integration

A recurring data job is the schedule that moves messages into or out of a data project. It is normally created by hand with Create recurring data job on the data project's page in the Data management workspace. Two Lattice entities expose the same thing to OData and to data management, so an environment's integrations can be set up from a data project or a script instead of by hand.

Entity	OData collection	Key	What it is
MGCLatticeRecurringDataJobEntity	LatticeRecurringDataJobs	Name	The job: which data project, which direction, on what schedule
MGCLatticeRecurringDataJobClientEntity	LatticeRecurringDataJobClients	JobName + ClientId	A client application allowed to submit messages to that job

The operator and read-only roles can read both entities. Creating, changing and deleting jobs and their client applications needs the integration administrator role: the two Maintain privileges are in the high-risk duty (MGCLatticeIntegrationServiceHighRiskDuty), because a job moves data in or out of the environment and a client entry decides who may send it. Through the entity, changing State (PATCH) and calling the Activate and Deactivate actions both need Maintain recurring data jobs.

The order things have to happen in

1. The data project already exists. Neither entity creates one. A job naming a data project that is not there is refused by the platform: the value '…' in field 'Processing group' is not found in the related table 'Definition Groups'.
2. Create the job. It is created inactive whatever State says, because a job cannot be started before the next step exists.
3. Authorize at least one client application, with IsEnabled set to Yes.
4. Activate, by calling the Activate action or setting State to Active.

Steps 2 and 3 are two separate imports if you are doing this through data management, because they are two entities. Step 4 can be a third import.

The schedule

A schedule is stored as a packed container, which no data entity can carry, so these entities project it into ordinary fields:

Field	Meaning
RecurrenceUnit	Minute, Hour, Day, Week, Month or Year
RecurrenceInterval	The N in "every N units"
RecurrenceStartDateTime	When the first run is due, in UTC
RecurrenceEndType	NoEnd, EndAfterCount or EndByDate
RecurrenceEndAfterCount, RecurrenceEndDate	The end condition's value, for the matching end type
RecurrenceTimeZone	The zone the schedule's clock times are read in
MonitoringRecurrenceUnit, MonitoringRecurrenceInterval	The monitoring job's own schedule; the platform's default is hourly
RecurrenceDescription	Read-only, the same sentence the recurrence dialog shows
BatchGroupId	Not stored on the job: the batch group to schedule into when it is activated

Editing an interval or an end condition works on a job that is inactive. The platform refuses to change the schedule of a job that is running - deactivate it, change the schedule, activate it again, which is the order the page requires too. Changing anything else, a description for instance, works either way.

Weekly and monthly patterns keep the detail these fields do not express - which weekday, which day of the month - as long as the unit itself does not change.

Activating

Setting State to Active does not merely write a column: it runs the platform scheduler, the same call the setup page makes, and the job's two batch jobs exist afterwards. Setting it back to Inactive puts them on hold.

Activation is refused, with a message naming what is missing, when the job has no schedule or no enabled client application. That is deliberate: the alternative is a row that says Active with nothing running behind it.

The same two operations are available as bound OData actions for callers that would rather say what they want done. The Maintain recurring data jobs privilege grants them, so the Integration administrator role can call them as well as change State.

POST /data/LatticeRecurringDataJobs(Name='NightlyCustomerImport')/Microsoft.Dynamics.DataEntities.Activate
Content-Type: application/json

{ "_batchGroupId": "" }

POST /data/LatticeRecurringDataJobs(Name='NightlyCustomerImport')/Microsoft.Dynamics.DataEntities.Deactivate

Both answer with a sentence saying what happened, including when there was nothing to do.

Through data management

Both entities are data-management enabled and have staging tables, so they work in a data project like any other entity. One thing to know: activation happens in the entity's row-by-row write path, so set-based processing must stay off for these two entities - it is off by default and there is no reason to turn it on for a handful of configuration rows.

Click path - import recurring data jobs

1. Go to Data management > Import.
2. Name the project, choose the source format, and add the entity Recurring data job.
3. Upload the file, map the columns, and run the import.
4. Repeat for Recurring data job client.
5. Check the result with Manage recurring data jobs on the data project (Data management workspace, Data projects), or on Recurring integration health.

What these entities will not do

Not covered	Why
Creating the data project itself	Microsoft ships DataManagementDefinitionGroupEntity for that, and the tables behind it are closed to other models
Reading messages, runs or acknowledgements	Monitoring data, not configuration: the read-only LatticeRecurringJobMessages entity reads it, one row per message with its status and execution (see Recurring data job messages)
Changing ActivityId	Assigned by the platform; it is read-only here and Name is the key

Keeping integration configuration in source control

Data projects and recurring data jobs are configuration, and configuration built by hand is lost every time a database moves. A sandbox refreshed from production comes back with production's integration configuration; a new environment comes back with none. Rebuilding it by hand is slow during an implementation and risky after go-live.

The data management configuration service turns that configuration into a file you commit, and a pipeline step that applies it.

Step	What you run	What you get
1. Capture	captureSpec against the environment where it was built	A JSON specification
2. Commit	Your own source control	A reviewable file, one per integration or one per environment
3. Apply	applySpec from a pipeline	The environment matches the file

Step 1 has an alternative: if the integration already exists as a data package, pass its Manifest.xml to specFromPackageManifest and skip building it again.

The contract, the JSON shape and every flag are in The specification. This section is the workflow.

Why applying it repeatedly is safe

applySpec compares before it writes. Run it against an environment that already matches and it reports every item Unchanged and changes nothing. That is what lets it run on every deployment rather than only on a new environment, and it makes the change count meaningful: anything other than zero on a re-run means the environment drifted from the file.

In a deployment pipeline

- task: PowerShell@2
  displayName: Apply integration configuration
  inputs:
    targetType: inline
    script: |
      $token = <your existing token acquisition>
      $spec  = Get-Content 'config/integrations.json' -Raw | ConvertFrom-Json

      $body = @{ _request = @{
          Spec         = $spec
          ValidateOnly = $env:VALIDATE_ONLY -eq 'true'
          PruneMissing = $false
      } } | ConvertTo-Json -Depth 12

      $url = "$($env:AOS_URL)/api/services/MGCLatticeDataManagementServiceGroup/" +
             "MGCLatticeDmfConfigService/applySpec"

      $result = Invoke-RestMethod -Method Post -Uri $url -Body $body `
                  -ContentType 'application/json' `
                  -Headers @{ Authorization = "Bearer $token" }

      $result.Items | Where-Object { $_.Outcome -ne 'Unchanged' } |
          ForEach-Object { Write-Host "$($_.Outcome): $($_.Kind) $($_.Name) $($_.Detail)" }

      Write-Host $result.Message
      if (-not $result.Success) { throw 'The integration configuration did not apply cleanly.' }

Set VALIDATE_ONLY on a pull-request build and leave it off on a deployment: the same file and the same step then give you a plan and an apply.

Client ids come from the pipeline, not the file. The Entra application that calls the recurring integrations endpoints usually differs per environment, so keep the Clients entry out of the committed file, or overwrite it from a variable before posting.

Click path - capture what an environment already has

1. Call captureSpec with a project name pattern, or leave it blank for everything: POST .../MGCLatticeDmfConfigService/captureSpec with { "_projectNamePattern": "Cust*", "_jobNamePattern": "Cust*" }.
2. Save the response to a file in your repository.
3. Remove anything environment-specific - client ids, and any file paths that came from a data package.
4. Commit it, and from then on the file is what defines the integration.

After a database movement

A sandbox restored from production carries production's integration configuration, including jobs that may now point at the wrong places. The specification is the recovery:

1. Before anything else, stop what should not run. The restored jobs are inactive until their batch jobs are re-created, but confirm with Manage recurring data jobs on the data project, or on Recurring integration health.
2. Apply the target environment's specification with ValidateOnly set, and read the plan. On a freshly restored environment this normally shows updates to schedules and client authorizations - the differences between the two environments.
3. Apply it for real.
4. Check the result: every item should be Created, Updated or Unchanged, and Success true.

Use PruneMissing here if the specification is the whole truth for that environment. It removes entity lines and client authorizations the file does not describe, which is what takes production's client ids off a sandbox.

During an implementation

The same file is how an integration gets from the environment it was built in to every other one. Build it once in a development environment, capture it, commit it, and let the pipeline put it in test, UAT and production. A change to the schedule becomes a one-line diff in a pull request rather than a set of instructions for someone to follow in three places.

Standard procedures

Two Finance and Operations procedures this guide depends on. They are standard platform pages, not Lattice ones.

Click path - assign a Lattice role to a user

1. Go to System administration > Security > Assign users to roles.
2. Select the role in the list on the left - for the pages in this guide, the integration administrator, operator or read-only role.
3. Click Manually assign / exclude users.
4. Select the user's row.
5. Click Assign to role.

Click path - schedule a job as a recurring batch

1. Go to the periodic menu item you want to schedule - for this pillar, System administration > Periodic tasks > Lattice data entities > Analyze table data and entity coverage.
2. Set the job's own options in the dialog first.
3. Expand Run in the background and set Batch processing to Yes.
4. Set Task description so the job is recognizable in the batch list, and choose a Batch group.
5. Click Recurrence, set the pattern and its start, and click OK.
6. Click OK to submit the job.
7. Watch it under System administration > Inquiries > Batch jobs.

---

What this guide does not cover

Topic	Where
The entity list, per-entity metadata and OData collection names	Entity catalog, Service catalog
Coverage analyzer internals, cost model and resolution limits	Table and entity coverage
Roles, duties, privileges and how to assign them	Security model
Calling the OData surface (authentication, endpoints, payloads)	API reference, Endpoint payload specification
Deploying the package and enabling entities	Deployment
Page-by-page reference for every Lattice page	Page reference
Integration operations (dead letters, service testing, file ingestion)	Integration operations
Business events	Business events
Loading journals and high-volume master data with set-based data management	Set-based imports, scenario Import journals in bulk

Verify in your environment. Batch behavior (how long a metadata refresh or a full coverage run takes, and the size of a generated Postman or OpenAPI file or of the OData metadata document) depends on the size of your application and data. The first run of each is worth timing before you schedule it.