Lattice - Product Offering

Document purpose: a capability-led offering brief for IT directors, enterprise architects, and implementation leads evaluating Lattice for Microsoft Dynamics 365 Finance & Operations (10.0.x). Lattice ships as a single ISV model and one deployable package with three shipped capabilities - integration operations, data entities, and business events - plus the licensing pillar, wired through the shared Siren module. The pillars lead; each carries its own outcome statement so value sits beside the capability that delivers it.

Capability Pillars at a Glance

Area	Capability scope	Headline surface	Outcome
Integration operations	Idempotent inbound REST operations with UI-equivalent validation and audit across AR, AP, Inventory, Production, GL, Fixed Assets, Project, Expense, and Workflow - plus posting of journals already in F&O, async, cloud file ingestion, pricing/trade-agreement services, and API tooling	30 services · 13 auto-deploying service groups · 182 operations	One package, one contract pattern, one security model replaces bespoke per-module integrations
Data entities and feeds	OData/DMF read and write surfaces: writable contact and document-attachment entities plus lean, high-performance read feeds where standard entities are heavy or missing	149 data entities (46 read-only, 103 writable) + 1 composite + 2 extensions	Predictable, lean integration and BI feeds without hand-built loading layers
Business events	Process-level outbound business events with enriched, versioned payloads and a correlation/ordering envelope	81 business events across 16 modules	Turns D365 F&O into a first-class real-time event source without per-signal custom development
Licensing	Product entitlement and the runtime soft check, via the shared Siren module	Wired - gates Lattice service writes and interactive processing actions	Commercial entitlement enforcement without a hard kill switch

---

1. Executive Summary

Lattice is an enterprise integration platform for Microsoft Dynamics 365 Finance & Operations (10.0.x), published by Magicite as a single ISV model (layer 8) in one deployable package. It consolidates three formerly independent packages - integration operations, data entities, and business events - into one model with a shared reliability and security substrate, organized as three shipped capability pillars:

• Integration operations delivers 30 X++ services organized into 13 module-aligned, auto-deploying service groups that expose 182 service operations, complemented by a pull-based cloud file-ingestion framework, pricing and trade-agreement services, and dual-surface API documentation tooling (Postman and OpenAPI).
• Data entities delivers 149 data entities (46 read-only, 103 writable) plus 1 composite entity and 2 entity extensions, exposed through OData and the Data Management Framework (DMF).
• Business events delivers 81 process-level business events across 16 modules, each activatable with zero code through the standard Business Events Catalog.

A fourth pillar, product licensing, is wired through the shared Siren module (product id Lattice). It is a soft check: Lattice service write operations are refused, and interactive actions that run Lattice processing stop with a warning, on a definitive adverse license verdict, while reads, previews, data entities, and business events are never blocked, and an unregistered environment is allowed through. Siren must be deployed in the target environment - it is a deployment prerequisite, and the Lattice deployable packages include it. See Licensing.

The platform is engineered around four operational promises that recur across every pillar:

• Reliability - RequestId-keyed idempotency and a self-describing reconciliation sweep so retries never double-post.
• Auditability - full call logging with three correlation IDs, per-operation interaction logging, and a daily statistics rollup.
• Speed-to-integrate - uniform contracts, batch variants, generated API docs, an in-app test console, and ready-to-use OData/DMF feeds and business events.
• Risk reduction - least-privilege RBAC, strong typing, partial-success reporting, and what-if posting preview.

It ships as a deployable F&O model plus two .NET companion libraries, with a curated documentation set and a multi-layer test strategy.

---

2. At a Glance (Fact Sheet)

Every metric below is counted from the model's metadata.

Metric	Value
Publisher / layer	Magicite / 8 (ISV)
Package / model	Lattice - one package; the Lattice model plus the one-class MGCLatticeHelp contextual-help model
Model references	36 (35 standard + Siren)
Custom X++ services	30
Auto-deploying service groups	13
Service operations	182
Data entities	149 (46 read-only, 103 writable; 131 enabled for Data management)
Composite entity (DMF)	1
Entity extensions	2
Business events	81 across 16 modules
Security - privileges / duties / roles	291 / 22 / 4
net472 companion libraries	2 (MGCLatticeDocumentationGenerator, MGCLatticeFileIngestion)

---

3. The Business Problem

Standard D365 F&O integration is expensive to build and operate because each program tends to reinvent the same plumbing across three distinct problem areas - pushing transactions in, pulling data out, and reacting to change:

• Bespoke per-document endpoints. Every document type gets its own ad-hoc service surface, contract shape, and error handling.
• Duplicate-posting risk on retries. HTTP clients and middleware retry on timeouts, and without idempotency a retry re-posts a financial transaction.
• Opaque all-or-nothing batches. A multi-document load fails as a single unit, with no per-item visibility into what succeeded and what did not.
• Error-prone hand-built file-loading layers. Pulling large partner files from cloud storage, parsing them, and transforming them is custom code in every project.
• Heavy or missing data entities. The standard entity catalog is heavy for high-frequency sync in some places and simply missing lean read feeds or key-friendly writable surfaces in others.
• A thin native business-events catalog. The standard catalog looks long (the reference list Lattice ships for its coverage report, taken from a Finance and Operations environment, has 211 entries), but most of its entries are workflow events, generated for each configured workflow, and Human resources, batch, alert and background operation events. The finance and supply chain events are comparatively few, and most report a posted document or a warehouse integration message; the process moments integrations actually care about (production order started, transfer order shipped, customer hold status changed, vendor check issued) have no native event, forcing teams to poll tables on a timer.
• No out-of-the-box observability or auditable trace. There is no standard call log, no correlation IDs, and no way for existing tools to query failures or in-flight work.

Lattice targets the outcome directly: predictable, auditable, high-volume integration - inbound operations, outbound data feeds, and real-time events - without per-project plumbing.

---

4. Capability Pillars

Lattice presents three shipped capabilities - integration operations, data entities, and business events - plus licensing, wired through the shared Siren module. All ship in the single Lattice model and share one reliability and security substrate. Each pillar below presents its capability scope, the mechanisms that realize it, and an outcome statement for the architect and implementation-lead audience.

4.1 Pillar 1 - Integration operations

The integration surface is the inbound operations surface: 30 services exposing 182 operations, organized into 13 module-aligned, auto-deploying service groups. Every operation is idempotent and runs the same validation and audit path as the UI; server-side security is re-validated in the operation and never trusted from the caller; failures return a typed error and leave no partial state.

4.1.1 Transactional Operation Coverage

The services span the D365 financial and supply-chain footprint:

• Accounts Receivable - sales order lifecycle (confirm, packing slip, invoice), cancellation of a posted packing slip (a high-risk operation), free text invoices (post, cancel), sales/purchase return orders (receive, credit, ship), an effective sales-price inquiry, and sales trade-agreement create/post.
• Accounts Payable - purchase order lifecycle, cancellation of a posted product receipt (a high-risk operation), purchase prepayment invoices, posting of pending vendor invoices with standard invoice matching, vendor invoice journals (register/approval), vendor payment proposal generation, generating the payments of a vendor payment journal (each check line gets the next check number of its bank account, optionally posted in the same call), and purchase requisition submit/approve/convert-to-order.
• Inventory - seven journal kinds (movement, adjustment, counting, transfer, BOM, tag counting, consignment ownership change), each validating that the journal name matches the operation type, item cost calculation in a costing version (pending cost prices), and activating the pending prices (new standard costs) of a costing version, which revalues on-hand inventory (a high-risk operation, administrator role only).
• Production - the largest single service: estimate, schedule, release, start, pick list, route card, report-as-finished, end, status query, plus their batch variants.
• General Ledger - GL journals (general + intercompany) whose lines can name main accounts or customer, vendor and bank accounts (customer invoices, vendor adjustments, bank transfers, defaulted from the account as the journal page does), payment journals + settlement (including customer and vendor prepayment lines marked against an order, and vendor check payments whose checks are generated before posting), reversal of posted journals and of customer and vendor payments (high-risk operations; a check reversal can be left in a check reversal journal for review), budget register entries/transfers, and customer/vendor/ledger currency revaluation (three counterparty scopes).
• Fixed Assets - acquisition, depreciation proposal, disposal, transactions after acquisition (acquisition adjustments, depreciation and depreciation adjustments, revaluations, write-up and write-down adjustments, extraordinary and bonus depreciation), transfer to new financial dimensions or a new location, split by percentage or quantity, and reversal of a posted fixed asset transaction (a high-risk operation), each with a batch variant.
• Project - four project journal types (hour, expense, item, fee) plus invoice proposal create-and-post, each with batch variants.
• Expense - expense reports from expense tools: create a report with its lines for a worker the caller may file for, optionally submit it to the expense report workflow, and post it once the workflow approved it.
• Journal posting - post a journal that already exists in F&O - entered on its page, imported through data management or created through the standard journal entities - with the journal page's standard posting: ledger journals (general, customer and vendor payment, invoice register, vendor invoice, invoice approval, project expense, fixed asset), inventory journals (movement, adjustment, counting, transfer, BOM, tag counting, ownership change, project item, fixed asset), project hour and fee journals, production journals (picking list, route card, job card, report as finished), and trade agreement journals. The caller must also hold the Lattice operation that posts that journal type, so the service never lets a role post more than it already could.
• Workflow - submit, approve, reject, delegate, recall, and status query.

These are delivered as module-aligned, auto-deploying service groups, which are the supported surface.

4.1.2 Uniform Request/Response Contract Pattern

Every operation uses the same contract shape. All posting/processing operations return the shared MGCLatticeOrderOperationResponseContract carrying Success, Status, CorrelationId, ExecutionId, RequestId, DocumentId, timing, and Errors/Warnings/InformationalMessages arrays. A small, fixed family of response contracts covers the four operation shapes - single-document (MGCLatticeOrderOperationResponseContract), bulk (MGCLatticeBulkOperationResponseContract), async (MGCLatticeAsyncOperationResponseContract), and status query (MGCLatticeStatusQueryResponseContract) - with a strongly-typed request contract per operation family.

4.1.3 High-Volume Throughput, Async & Exactly-Once Reliability

Nearly every base posting/processing operation ships a batch (multi-document) counterpart, cutting HTTP round-trips and throttling exposure. Batch operations return MGCLatticeBulkOperationResponseContract, an envelope carrying CorrelationId, TotalCount, SuccessCount, FailureCount, start/end timing, and a Results collection of per-item MGCLatticeBulkItemResultContract - so a multi-document load never fails opaquely as all-or-nothing.

• End-to-end idempotency. Operations key on a mandatory RequestId GUID. Each request first claims its RequestId in MGCLatticeServiceIdempotencyLog, and only successful completions stay recorded there; a duplicate of a prior success returns the original cached outcome (with a fresh ExecutionId and replay timestamps) instead of re-executing, a duplicate of an in-flight request is told it is still being processed, a RequestId reused for a different operation is refused (DuplicateRequest), and a failed request releases its claim so it can be safely retried with the same RequestId. Because the idempotency log is not per-company, deduplication is cross-company.
• Fire-and-poll async. submitAsyncOperation validates the request, records MGCLatticeAsyncOperationTracking, schedules a batch job, and returns a TrackingId; a status operation polls by that ID. A Process Automation series drains the queued backlog once per minute; the worker is BatchRetryable so transient faults are retried, and failures are captured (never masked) across a 6-state lifecycle (None, Queued, Processing, Succeeded, Failed, NotFound).
• Exactly-once reconciliation. Every create-then-post operation stamps a self-describing idempotency claim that names the created document (legal entity + document table + number) inside the create transaction. The MGCLatticeIdempotencyReconciliationSweep batch then resolves any stranded Processing claims - finalizing a posted document to Succeeded, releasing a not-found claim, or parking a created-but-unposted document for manual review - closing the exactly-once gap on interrupted create-then-post journals. See Idempotency reconcile runbook.

4.1.4 What-If Posting Preview

A non-committing PreviewMode validates a posting operation and returns the projected outcome without writing - no document number is burned, no ledger line persists, and any in-transaction business event self-suppresses. Preview runs the operation's real validation path (validate-only fidelity for the enabled operations) and returns a structured preview block, so callers can prove an integration payload will post cleanly before committing it. See Posting preview.

4.1.5 Operability - Test Console, Interaction Logging, Statistics & Dead-Letter Replay

Lattice ships in-product operability tooling for building, tuning, and running the integration estate:

• Service Test Console - an in-app form that invokes any operation by reflection with a saved-request library, so an operation can be exercised (including in preview mode) without an external client.
• Configurable per-operation interaction logging - call-log verbosity and retention are set per operation, so high-volume operations can be quieted and sensitive ones can be captured in full.
• Daily statistics rollup - a batch aggregates call volumes and outcomes into a per-operation daily statistics table with an inquiry form.
• Dead-letter fix-and-resubmit - a failed operation parked in the dead-letter queue can have its payload edited and resubmitted from a DLQ management form, turning a terminal failure into a recoverable one.

4.1.6 Pricing, Trade Agreements & Inbound-Order Guardrails

A set of pricing and order-governance capabilities layer on top of the base operations:

• Effective sales-price inquiry (MGCLatticePriceInquiryService) - a read-only, idempotent point query that resolves the effective sales price for a customer, item, date, and quantity through the standard pricing engine.
• Sales trade-agreement create/post (MGCLatticeSalesTradeAgreementService) - creates and posts sales-price trade agreements with clean forward-only supersession (an open row is edited in place on the same effective date, or capped and superseded by a new row on a later date, in a single journal).
• Inbound-order guardrail/policy layer - an optional, parameter-driven policy applied to inbound orders: a price-tolerance soft-hold when a line price deviates beyond a configured percentage, auto-confirmation of hold-free orders, and a post-confirmation edit-lock. It runs in a batch (never in the order-creation transaction) and is inert until enabled.
• Source-attribution financial-dimension stamping - maps an order's sales origin to a default financial dimension value and stamps it before the order is written, so downstream ledger postings carry integration-source attribution. Disabled by default; an unmapped origin is a silent no-op.

The trade-agreement story spans all three pillars: the create/post and inquiry services here in the service surface, a unified active-agreement OData feed (§4.2), and a six-event sales-price change family (§4.3).

4.1.7 Pull-Based Cloud File Ingestion

A claim-check ingestion framework pulls large files from Azure Blob, Azure File Share, or SFTP on a schedule, stores raw payloads out-of-band in D365 Document Management, decomposes them atomically into per-record segments, applies Liquid (Fluid engine) transforms, dispatches to a target service, and cleans up by retention policy.

• Claim-check + atomic decomposition. The raw file is stored via Document Management (keeping multi-hundred-MB payloads off the transaction log); bundle, state, claim-check, and bulk-inserted segments commit in one transaction.
• Top-picking parallel processing. Each worker claims one queued segment under a pessimistic lock that skips rows already locked by other workers, so N batch threads drain the same staging table concurrently without blocking.
• Configuration over code. Interface-plus-factory extension axes keep customization out of core code for the cloud file source (Blob / File Share / SFTP), the format parser (JSON, XML, and delimited CSV), and the dispatcher (target service). Liquid templates render through a parse-once/render-many cache, with an offline tester form.
• Resilience & dedup. A retry cap precedes Failed; content-hash deduplication (SHA-256 of the path and the content) skips a file that was already ingested; failed files move to an error folder and ingested ones to an archive folder when configured; and retention-driven cleanup cascade-deletes the bundle, segments, and backing blob.

4.1.8 API Documentation & Metadata Tooling

A net472 dual-surface documentation generator (MGCLatticeDocumentationGenerator) emits both Postman v2.1 collections and OpenAPI 3.0.3 specs for custom-service endpoints (/api/services/) and OData entities (/data/), including bound and unbound OData actions. Generated samples are type-aware (ISO 8601 dates, GUIDs for ID fields, real numbers, USMF for company fields, named keys for GET-by-key). Two in-product read-only explorer forms - for custom services and OData entities - let users stream Postman/OpenAPI files directly to the browser, generated in-process from the environment's own metadata, with no app registration, client secret or access token required. A customOnly default keeps generated collections importable in environments with thousands of OData entities.

4.1.9 Outcome - Coherent, Reliable, Self-Documenting Inbound Integration

One package, one contract pattern, and one security model across AR / AP / Inventory / Production / GL / Fixed Assets / Project / Expense / Workflow replaces bespoke per-module integrations. Retry-safe idempotency, exactly-once reconciliation, batch-backed async, what-if preview, and in-product operability tooling let the suite absorb high-volume, retry-prone traffic without double-posting financial transactions - while claim-check file ingestion and generated API docs remove the most error-prone hand-built layers.

4.2 Pillar 2 - Data entities and feeds

The data-entity surface is the OData/DMF data surface: 149 data entities (46 read-only, 103 writable) plus 1 composite entity and 2 entity extensions. It pairs writable, key-friendly master-data and attachment entities with lean, high-performance read feeds engineered for integration and BI where the standard entities are heavy or simply missing.

4.2.1 Writable Onboarding & Document-Attachment Surfaces

• Customer/vendor onboarding. Writable contact-info and contact-person entities import and export using only the customer or vendor account number - no need to pre-resolve party numbers - ideal for ERP migrations and ongoing CRM/master-data sync.
• Document & attachment management. A general-purpose DocuRef entity plus business-keyed document-attachment entities let integrations create, read, update, and delete attachments by business key (e.g. sales order + invoice id + invoice date) - including attaching files and notes to posted journals - without ever touching internal RecIds. Covered surfaces include sales/purchase posting types, customer, vendor and free-text-invoice master data, production and quality orders, projects, and transfer order headers and lines.
• Cross-reference keys. 33 writable entities, one per record kind, hold the keys other systems use for D365 records (a CRM account id for a customer, a marketplace order number for a sales order), keyed by the record's business key plus the external system. Integrations can then send their own key to Lattice services, entities and file ingestion instead of the D365 id. See Cross-reference keys.
• Set-based imports. 15 import-only entities load journals (inventory, customer payment, customer invoice, vendor payment, vendor invoice, project, trade agreement and production journals) and high-volume masters with data management's Set-based processing. The customer invoice journal entity imports customer invoices without a sales order into general journals, defaulted from the customer as the journal page does; posting the journal leaves the invoices open for settlement. The journals they create can then be posted through the journal posting service. See Set-based imports.

4.2.2 High-Performance Read Feeds

Read-only feeds are engineered, not accidental: explicit field projection (DynamicFields=No) so SQL selects a narrow column set, read-only marking that skips the write/validate machinery, baked-in range filters so consumers receive pre-filtered result sets, index-aligned keys so server-driven $skiptoken keyset paging stays efficient at any depth, and change-tracking readiness for incremental delta export via DMF/BYOD/Data Lake.

• Inventory on-hand and released-product catalog feeds for WMS/3PL stock sync, e-commerce inventory, ATP, and PIM/storefront sync.
• Order-line, open-order-line, and intercompany order/order-line feeds for near-real-time fulfillment, backlog, and cross-entity reconciliation, plus customer packing-slip journal entities (and a composite for atomic DMF export packages).
• Unified trade-agreement OData feed - the active sales-price agreements exposed as a single read feed, the OData counterpart to the service surface's trade-agreement services and the price-change events.

4.2.3 Outcome - Lean, Predictable Feeds Without Hand-Built Loaders

Public, DMF-enabled entities with a consistent Lattice collection-name prefix drop straight into an integration architecture: key-friendly writable surfaces cut onboarding effort, and lean read feeds with $skiptoken paging and change-tracked delta export move only what changed at high frequency - removing the hand-built loading layers that heavy or missing standard entities would otherwise require.

4.3 Pillar 3 - Business events

Lattice adds 81 process-level business events across 16 modules, each capturing a specific operational moment as it happens and pushing an enriched, integration-ready payload to the endpoint of your choice - filling the process-level gaps in the standard D365 F&O business events catalog.

4.3.1 Coverage Across 16 Modules

Events span the operational footprint - including Customer, Vendor, Sales order, Purchase order, Inventory, Production, Fixed assets, Project, Ledger, Bank, Master planning, Product information management, Retail terminal, and System administration - covering moments such as production order started, transfer order shipped, customer hold status changed, quality order failed, vendor check issued, and inventory on-hand changed. Among these is a six-event sales-price trade-agreement family (created, modified, superseded, deleted, effective, expired) raised by trade-agreement journal posting, by deletion and by a daily effectivity background process, complementing the record-based sales-price change event.

4.3.2 Built the Standard Way

• Standard pattern. Each event pairs a BusinessEventsBase event class with a [DataContract] payload contract, exactly as Microsoft's first-party events do - so it behaves like a first-party event in the catalog, monitoring, retry, and governance.
• Process-method triggers. Events fire from Chain of Command extensions on the process method that causes the data change (not raw table insert()/update() hooks wherever a process method exists), making them cancellation-safe and partial-posting-safe.
• Zero-code activation, endpoint-agnostic. Every event surfaces in the standard Business Events Catalog; activate it, point it at an endpoint (Azure Service Bus, Event Grid, HTTPS/webhook, Power Automate), and you are live. Inactive events carry no overhead.
• Enriched, correlated payloads. Status fields carry both the numeric value and a human-readable name; a shared contract base adds an ordering/correlation envelope (correlationId, eventSequence, schemaVersion).
• Never blocks the business. Delivery is post-commit (the event is recorded with the business transaction and sent after it commits) and at-least-once, so consumers must be idempotent by event id. A delivery failure never rolls back or blocks the underlying business action.

4.3.3 Outcome - D365 F&O as a First-Class Event Source

A curated, supportable event library turns D365 F&O into a real-time event source for the integration fabric - eliminating polling latency, missed changes, and the database load of scheduled scans - without custom one-off development for each signal a downstream system needs.

4.4 Licensing

Licensing runs on the Magicite licensing service. Lattice consumes it through the shared Siren X++ client module under product id Lattice.

This is a deployment prerequisite. The Lattice descriptor references Siren, so Siren must be deployed in the target environment or the Lattice package will not deploy. Both Lattice deployable packages (the Power Platform unified package and the LCS deployable package) include Siren, so installing either deploys it with Lattice.

What an administrator has to do: nothing in Lattice. There is no license-key entry field, no activation wizard, and no setup form. Environment identity is derived server-side and licenses are provisioned by the Magicite licensing service on first contact. Per-environment configuration is a Siren concern - populating the SirenLicenseParameters singleton table.

How enforcement behaves:

Aspect	Behavior
Style	Soft check. No AxLicenseCode / AxConfigurationKey hard gate; nothing is removed from the AOT
Gated	Write service operations; MGCLatticeDbAccessService.requestAccess; 27 interactive UI actions that run Lattice processing (they show a warning and do nothing)
Never gated	Lattice data entities (reads and writes), MGCLatticeDmfConfigService.applySpec, business events, status queries, PreviewMode previews, revokeAccess
Blocks on	Expired, Invalid, OfflineExceeded
Allows through	Unlicensed - fail-open by design
Caller sees	Error code LicenseNotValid, marked retryable (renew or reconnect; the same request then succeeds)

A lapsed license degrades Lattice to a read-and-observe product rather than taking it dark.

Full behavior and the LicenseNotValid runbook: Licensing.

---

5. Cross-Cutting Architecture & Quality Highlights

The foundations below are shared across the pillars - the engineering substrate that makes reliability and auditability structural rather than bolt-on.

5.1 Shared Service Base & Reliability by Design

26 of the 30 Lattice services extend MGCLatticeOrderPostingServiceBase (the price inquiry, Data management configuration, Data management field mapping and database access services stand alone), which centralizes idempotency (checkIdempotency caches by RequestId to prevent double-posting), self-describing idempotency claims, infolog capture, audit logging to MGCLatticeServiceCallLog/MGCLatticeServiceIdempotencyLog, what-if preview hooks, and safe abort-of-active-transaction on failure. Async failures are captured rather than masked, and workers are BatchRetryable. These are built-in structural guarantees, not per-service code.

5.2 Observability & Auditability

Every call is recorded in MGCLatticeServiceCallLog with three independent correlation GUIDs (RequestId, CorrelationId, ExecutionId), service/operation names, legal entity, user context, start/end timing and DurationMs, and Success/Status, with dedicated indexes for distributed-trace and SLA queries. Persistence verbosity and retention are configurable per operation, and a daily statistics rollup summarizes volumes and outcomes. Async tracking persists the full replay/diagnosis trail (including the serialized request payload and batch job id), and a dead-letter queue supports edit-and-resubmit of failed operations. Read-only OData monitoring entities (call log, idempotency log, async tracking - all public, read-only) let existing tools query failures and in-flight work via standard $filter/$orderby with no custom development.

5.3 Strong Typing End-to-End

Status and log-level fields are X++ enums that surface as enums in OData $metadata and in service contracts rather than as free strings. Status uses MGCLatticeServiceCallStatus for sync and bulk responses and MGCLatticeAsyncOperationStatus (which adds NotFound) for async tracking; log levels are typed enums. This enables qualified enum-member filtering (e.g. Status eq Microsoft.Dynamics.DataEntities.MGCLatticeServiceCallStatus'Failed') and keeps contracts self-describing.

5.4 Layered RBAC Security Model

Security follows a least-privilege hierarchy of roles → duties → privileges with no standing direct-access permissions. Operations privileges are split per module (*ServiceMaintain) and separated from read-only monitoring and entity-view privileges, so drop-in least-privilege custom roles can grant exactly the operations, monitoring surfaces, or data entities a given integration needs. data entities set SubscriberAccessLevel Read=Allow to enable cross-company read scenarios, with maintain privileges on read-only entities deliberately downgraded to read access. See Security model for the full role/duty/privilege inventory and entry points.

5.5 One Model, One Package

These three capabilities were previously three independent models; they are now a single model in a single package (Lattice, publisher Magicite, layer 8 ISV), sharing the reliability substrate above and a single deployment and version-management story. AOT element names carry the MGCLattice* prefix; OData collection names remain Lattice* as the public wire contract. The licensing pillar is wired via the shared Siren module, which is a deployment prerequisite.

---

6. Business Benefits

Each program outcome ties back to a named capability:

• Lower integration build and maintenance cost. One uniform contract pattern and one security model across all modules eliminate per-project plumbing - see (§4.1). Key-friendly writable entities and lean read feeds remove hand-built loaders - see (§4.2).
• Reduced operational risk. Idempotent retries, exactly-once reconciliation, partial-success reporting, what-if preview, and a full audit trail mean retries are safe and failures are visible and recoverable - see §4.1.3-4.1.5 and §5.1-5.2.
• Faster time-to-integration. Generated Postman/OpenAPI docs, in-product explorers, a test console, ready-to-use OData/DMF feeds, and zero-code business events shorten the path from deployment to a working client - see §4.1.8, §4.2, §4.3.
• Real-time reaction without polling. Process-level business events turn D365 F&O into a first-class event source, eliminating timer-based table polling - see (§4.3).
• Scalability for high-volume and large-file scenarios. Bulk operations, batch-backed async, claim-check file ingestion, and $skiptoken-paged read feeds handle both system-to-system and large-file/large-read workloads - see §4.1.3, §4.1.7, §4.2.2.

---

7. What's Included

A deliverables inventory so an implementation lead can scope a rollout.

7.1 X++ Application Model

One model, one package (publisher Magicite, layer 8 ISV), across three areas:

• Integration operations - 30 services in 13 auto-deploying service groups, exposing 182 operations, with the shared response-contract family, the MGCLatticeOrderPostingServiceBase base class, the cloud file-ingestion framework, pricing/trade-agreement and inbound-order-guardrail services, the monitoring/explorer/test-console/preview/DLQ forms, and the service-monitoring and metadata tables.
• Data entities - 149 data entities (46 read-only, 103 writable) plus 1 composite entity and 2 extensions, 133 of them public, 131 enabled for Data management (15 of them the set-based import entities), with a consistent Lattice collection-name prefix and per-entity security.
• Business events - 81 business events across 16 modules, each a BusinessEventsBase event class + [DataContract] payload with a Chain-of-Command process-method trigger and catalog labels.
• The full role-based security model and the shared X++ enums span all three areas.

7.2 Companion C# Libraries (.NET)

Two net472 (legacy non-SDK csproj) interop libraries referenced via AxReference, both running in-process in the AOS:

• MGCLatticeDocumentationGenerator - Postman/OpenAPI generation.
• MGCLatticeFileIngestion - cloud sources plus Fluid Liquid transforms and JSON/XML/CSV conversion; pulls SSH.NET, Fluid.Core, and BouncyCastle.Cryptography (PGP) via PackageReference.

7.3 Quality Bar

Every Lattice build is verified before release: X++ SysTest suites, a C# integration suite against the live OData and service surfaces of a cloud environment, tests of the documentation generator and converters, and UI tests. These test assets are Magicite's and are not part of the package; the Postman collections and OpenAPI specifications you use are generated in the product (Postman and OpenAPI on the Service metadata explorer and the OData entity metadata explorer).

7.4 Documentation & Samples

A curated documentation set with API and surface reference, deployment and security guides; posting-preview and exactly-once reconciliation guides; file-ingestion guides (user, technical, and Liquid transformer) with mermaid architecture diagrams; tooling READMEs; and ready-to-run sample order files in the file-ingestion guides.

---

8. Requirements & Compatibility

8.1 Platform & Dependencies

• D365 F&O 10.0.x, deployed as the single Lattice model/package.
• The Lattice model declares 36 module references in total. 35 are the standard application stack (ApplicationSuite, ApplicationFoundation, ApplicationPlatform, Ledger, Subledger, Tax, Directory, Currency, and related foundation modules), all present in any standard F&O environment.
• One ISV dependency is required: Siren, the shared Magicite licensing module. It must be present in the target environment; the Lattice deployable packages include it, so it is deployed together with Lattice. No third-party (non-Magicite) ISV dependencies are required. See Licensing.
• Two net472 (.NET Framework 4.7.2) companion libraries deployed into the AOS bin, with NuGet dependencies SSH.NET, Fluid.Core and BouncyCastle.Cryptography (plus AOS-bin Azure Storage SDKs) for file ingestion.
• .NET 8.0 SDK required only for the optional .NET tools (the intake accelerator bundle validator and catalog tool).

No external executable or .NET SDK is required at runtime - the documentation generator and file-ingestion libraries run in-process in the AOS.

8.2 Consumption & Interoperability

Lattice exposes SOAP custom-service endpoints (/api/services/), OData (/data/, data entities and the read-only monitoring entities), and business events to any supported endpoint - consumable by any HTTP client and by common middleware (Azure Logic Apps, Power Automate, MuleSoft, Azure Service Bus, Event Grid). Business-event activation requires a configured business-events endpoint; the OData customOnly documentation default keeps generated collections importable in environments with thousands of OData entities.

---

9. Where to Go Next (Documentation Pointers)

To evaluate…	Read
A hands-on trial in a sandbox	Trial and day-one guide
API and surface reference	API reference
What-if posting preview	Posting preview
Exactly-once idempotency reconciliation	Idempotency reconcile runbook
Business events - full event catalog and integration scenarios	Product offerings
Data entities - catalog	Service catalog
Build, deploy, and batch scheduling	Deployment
RBAC and least-privilege roles	Security model
File Ingestion - usage, architecture, Liquid transforms	User guide, Technical reference, Liquid transformer

Learn more

For a first look, follow the trial guide. For a deep technical evaluation, pair the API reference (Lattice service surface inventory) with the deployment guide. For the event surface, read the Business event offerings catalog; for the data surface, the data entity catalog. Security reviewers should go directly to Security model.