Entity modeling and querying best practices

Modeling and query guidance for Data Fabric / Data Service entities: business object scope, cross-entity queries, filters, query volume, and transaction scope.

An entity in Data Fabric / Data Service represents a single business object. The practices on this page keep entity schemas aligned to that boundary, and keep queries within the volumes that the platform and its source systems handle reliably.

Which practices apply to a given entity depends on whether it is Native or Federated. For the difference between the two, refer to Entity types.

Practice	ApplicableÀ
One entity per business object	Native and Federated
Joins across business objects	Native and Federated
Filters and aggregates at the source	Native and Federated
Federated query volume	Federated
Transaction scope	Native

One entity per business object

An entity is designed to represent a business object, and each entity stays limited to one. A single entity should not embed several business objects, and it should not model an entire business process.

Where a business process spans several business objects, each object belongs in its own entity, and the connections between them are modeled as relationships. For how relationships are defined, refer to Creating relationships.

Joins across business objects

A single automation often needs data from more than one business object. Rather than widening one entity to hold them all, the Query Multiple Entity Records activity provides one interface that fetches data across several entities.

Filters and aggregates at the source

Native and Federated entities both support filters and aggregates. Depending on the interface in use, the platform accepts SQL-style WHERE clauses or OData filter queries, along with aggregate functions including SUM, COUNT, and AVG.

Leaving this work to the platform, rather than performing it inside an automation, has three effects:

• Less data moves at runtime.
• Query performance improves.
• The logic coded into the automation stays simpler.

Federated query volume

A query over a Federated entity reads from a live system of record, such as Workday, Salesforce, or SAP. Those systems do not deliver consistently reliable performance when a transactional request fetches a large volume of data, and Data Fabric / Data Service entities are designed for transactional use cases.

A filter that holds each query under 50 MB of fetched data keeps the request within the range these sources serve reliably. The limits the platform itself enforces on queries that read external data are documented in Query limits for external data.

Transaction scope

Data Fabric / Data Service provides ACID-compliant transactions, meaning atomic, consistent, isolated, and durable, scoped to a single Native entity.

An operation that modifies several Native entities has no platform-level transaction covering it as a unit. Where a use case requires that guarantee, the transaction semantics are handled in the application or automation layer.