Concepts

Lattice is one package with three capabilities. Each capability answers a different integration question: how do I drive a transaction, how do I move data, and how do I know something happened. Understanding the split helps you decide which part of the surface each of your systems should use.

Integration operations

The integration operations are a REST surface over the transactions your business runs. The 155 REST operations, implemented as 27 X++ services, cover posting for sales and purchase orders, journals, inventory, production, projects, and workflow, plus pull-based cloud file ingestion for systems that hand off files rather than calls.

The point of the integration operations is consistency. Every operation shares one predictable request shape, so an integrator who has called one operation can call the rest without relearning the surface. That consistency is what turns a multi-month integration build into days of configuration, and it is also what keeps re-testing manageable when Finance & Operations is updated.

Data entities

Lattice fills the gaps in the standard data entity catalog with 132 purpose-built OData entities. Some close functional gaps, such as writable contact and attachment entities and intercompany visibility. Others exist for performance: change-tracked inventory and product feeds tuned for delta export and real reporting volume, so BI and integration workloads move large datasets without dragging the environment down.

Use the data entities when the question is "get this data in or out", and the integration operations when the question is "make this transaction happen". They are complementary, not interchangeable.

Business events

Lattice adds 80 real-time business events that Finance & Operations does not ship. When a document posts or a status changes, the event fires over Event Grid, Service Bus, or HTTPS, and downstream systems react to the change itself rather than the next polling cycle.

This flips the integration model. Instead of scheduled jobs scanning the database on a timer, adding load and reacting minutes or hours late, the system tells you the moment something happens. Your database stops paying for questions no one asked.

Idempotent operations

Every integration operation is idempotent: submitting the same request twice produces the same result once, not a duplicate transaction. This matters because real integrations retry. Networks drop, timeouts fire, and message brokers redeliver. With an idempotent surface, your integration can retry safely by default instead of wrapping every call in duplicate-detection logic of its own.

Correlation and audit

Every call carries a correlation ID and is audit-logged. When something goes wrong, or when someone asks six months later what happened, you can trace a business outcome back through the exact calls that produced it. Finance systems demand that kind of evidence, and Lattice produces it by design rather than as an afterthought.