✏️ Explanatory Question
Before the properties, one important point:
EcoResProduct is a core product table in Product Information Management. It acts like a base/shared product definition table. Two properties are especially important:
That means this table is part of an inheritance design and is not just a simple standalone table.
@SYS133912
This is the user-friendly display name of the table.
Instead of hardcoding English text like Product, Microsoft stores labels in the label files. The value @SYS133912 points to a label resource.
If a user opens the AOT or sees a reference in UI, the system can show a friendly name from the label instead of the technical table name EcoResProduct.
DisplayProductNumber
This is the first title field used to identify a record.
When D365 needs to show a readable identity for a record, it uses title fields. This field becomes part of how a product record is visually identified.
Instead of seeing:
5637144576
the user may see:
P-1001
if DisplayProductNumber contains the product number.
SearchName
This is the second display field used alongside Title Field1.
It gives extra readable context for the record.
If DisplayProductNumber shows the code, SearchName usually gives the descriptive text.
A lookup could show:
P-1001 | Office Chair
That combination is more useful than only a code.
Found
This controls how records from this table are cached by the application.
Found means when a record is found, the system caches it for reuse.
Caching improves performance by reducing repeated database calls.
If the same product record is looked up multiple times, the system can reuse the cached result instead of going back to SQL every time.
Different cache modes exist for different table usage patterns. Found is good when:
SurrogateKey
This is the clustered index of the table.
The clustered index defines the physical ordering of data at the SQL level.
It affects:
Using SurrogateKey means the table is physically organized around the RecId-based surrogate key index.
RecId-based clustered indexes are common in D365 because:
Yes
This tells the system to automatically create the RecId index.
Every table in D365 usually has a RecId. This property ensures an index exists for it.
RecId is heavily used internally by the platform.
When records are joined internally, related, or referenced by RecId, the system depends on efficient RecId access.
SurrogateKey
This is the main index used as the primary index of the table.
It is the core identifying index from the table-definition perspective.
It affects:
This means the main identity of this table is not a business key like product number, but the surrogate key structure.
Main
This classifies the table functionally.
D365 tables are grouped into categories such as Main, Group, Parameter, Transaction, Worksheet, and so on.
This classification helps developers and the system understand the business role of the table.
Main usually means this is a major master-data-style table, not a setup table and not a transaction table.
A product table is naturally "main" data because it stores a core business entity.
Yes
This controls whether the table is visible in metadata tools and usage scenarios.
The table is exposed and available to developers and platform features.
A visible table can be used normally in the AOT and other development scenarios.
Yes
This means Optimistic Concurrency Control is enabled.
The system checks whether a record was changed by someone else before your update is committed.
It helps prevent accidental overwriting of data in multi-user scenarios.
Two users open the same product.
With OCC, the system can detect that the record changed in between and avoid silent overwrite.
In ERP systems, multiple users may work on the same record. OCC protects data consistency.
No
This indicates the table is not configured for archival behavior.
The system does not treat this table as one that supports data archival through that framework setting.
Older data in this table is not managed through archival features from this property alone.
Yes
This allows SQL change tracking support for the table.
Changes to this table can be tracked for scenarios like export, sync, or incremental movement.
Important for:
If product data changes and an export process only wants changed rows, change tracking helps identify those rows efficiently.
No
This property controls whether certain framework-level overrides are allowed.
The table is not intended to allow override behavior through this specific metadata option.
It is basically a restriction-oriented setting here.
No
This means retention policy support is not enabled through this property.
The table is not set up for retention management in that context.
You do not treat this table like a retention-controlled data source through this setting.
Yes
This allows row-version-based change tracking.
The system can use row-version information to detect changed rows efficiently.
Useful in synchronization and integration scenarios where detecting changed data matters.
If a downstream system needs only changed products, row version tracking helps identify them without scanning everything manually.
None
This defines authorization behavior at the AOS level.
No special AOS authorization rule is set here.
Authorization is not additionally restricted by this table property.
This does not mean the table is insecure. Security is still controlled by roles, duties, privileges, menu items, service security, etc.
LogisticsBasic
This ties the table to a configuration key.
The table is available only when the related configuration key is enabled.
Configuration keys control whether certain application functionality exists in the environment.
If LogisticsBasic is disabled, objects depending on it may not be available in the expected way.
This means no specific country/region limitation is directly set here.
The table is not restricted to specific country/region codes through this property.
It is generally available globally unless other localization logic applies elsewhere.
This means no dedicated field is defined for country/region context on this table.
The table itself is not using this mechanism to localize record behavior by a context field.
No
This tells whether the system stores the creator user automatically.
For this table, the standard CreatedBy system field is not enabled.
You cannot rely on a built-in CreatedBy field here.
No
This means the standard CreatedDateTime system field is not enabled.
This table does not automatically store creation timestamp through that built-in field.
No
This means transaction-id tracking for creation is not enabled.
The table does not maintain that extra creation-transaction metadata.
None
This defines how data sharing works across entities/companies.
No special data-sharing type is configured here.
The table is not using a special sharing mechanism through this property.
@SYS133913
This points to developer-facing documentation text via label. Developer Documentation - The EcoRes Product table stores products and is the base table in the products hierarchy.
The table has associated developer documentation stored as a label reference.
Useful for understanding intended use in metadata-driven development.
No
This means database logging is not forcibly disabled.
If database logging is configured for this table through the logging framework, it can still work.
If admins enable logging for changes to product data, this property does not block that.
No
This indicates lock escalation is not disabled at this metadata level.
Normal SQL/database locking behavior can occur.
The table does not impose a special "no lock escalation" behavior.
SchemaAndData
This tells what is durable in the database.
Both schema and data are durable.
This is a normal persistent table whose data is stored durably in SQL, not a temporary-memory-style structure.
Entity
This classifies the relationship style.
The table represents a business entity in the platform sense.
It fits with its role as a core business object: product.
EcoResProductDetails
This links the table to its main reference form.
When users open a record from certain contexts, this is the preferred form.
Improves navigation and system consistency.
If a developer or user drills into the product record, the system can use EcoResProductDetails as the main form.
No
This means the table is current and supported.
Microsoft is not marking this object as obsolete.
Developers can continue to use it normally.
EcoResProductListPage
This is the list page associated with the table.
The table's list-style browsing experience is tied to this page.
When users browse products in a list page scenario, this page reference is used.
Yes
This means the table stores which user last modified the record.
Helpful for audit-style understanding and operational support.
If a product was changed incorrectly, the ModifiedBy field can help identify who last updated it.
No
This means the standard ModifiedDateTime field is not enabled here.
This sometimes surprises developers: one metadata field may exist while another does not, depending on design.
No
No standard transaction-id tracking for modifications is enabled here.
ProductInformationManagement
This shows the functional module owning the table.
The table belongs to the Product Information Management area.
Helps developers locate ownership, functional context, and related objects.
EcoResProduct
This is the technical object name of the table.
This is the name developers use in X++ and AOT references.
EcoResProduct ecoResProduct;NotSpecified
This means no special operational domain classification is set.
The table is not tagged here with a special domain boundary.
No preview part is configured.
The table does not point to a preview part through this property.
DisplayProductNumberIdx
This is one of the most useful properties.
A replacement key is the readable business key shown instead of RecId in forms and lookups.
Users should see product numbers, not technical IDs.
Instead of showing:
5637147832
the system can show:
P-1001
because the replacement key uses the product-number-based index.
No report reference is defined.
The table does not point to a primary report via this property.
No
This is a very important property.
The table is shared across companies, not company-specific.
Product definitions are generally shared data in D365, not separate per legal entity.
If product P-1001 exists, it can be shared across legal entities because this is global product data.
If asked whether EcoResProduct is company-specific, the answer is:
SaveDataPerCompany=No
Yes
This means the data is stored per partition.
Partition-level data separation is respected.
In older/multi-partition architecture concepts, data belongs to a partition.
No singular label is explicitly set here.
The table does not define an extra singular label value through this property.
Disk
This tells where data is stored.
The data is physically stored in SQL/database storage, not memory-only.
Unset
No subscriber access level is specially defined.
No special event/subscriber access metadata is configured through this property.
No
This means it is not marked as a low-level system table.
It is an application/business table, not purely an internal infrastructure table.
NotSpecified
This property is not explicitly categorized further here.
No special content classification is declared through this property.
Regular
This is a standard persistent table.
It is not:
It stores real business data persistently.
No special metadata tags are entered.
None
This table does not use valid-time-state date-effectivity.
Records are not automatically date-effective through the valid-time-state framework.
This table is not behaving like date-effective entities where versions are active across date ranges.
Public
This means the table is publicly visible in metadata/development usage.
It is intended to be accessible for normal development scenarios.
Yes
This is one of the most important properties in your screenshot.
The table is abstract, so it acts as a base table in inheritance and is not meant to represent a fully concrete end type by itself in the same way as a normal simple table.
This signals inheritance design.
EcoResProduct is used as a parent concept for product-related subtype structures.
An abstract table usually participates in inheritance where more specific child tables represent concrete subtypes.
If a value is not shown, it means either:
I should be careful here and not invent a value that is not visible in your screenshot.
InstanceRelationType
This property supports inheritance behavior.
It identifies the field/type mechanism used to determine which subtype a record belongs to.
In inheritance-enabled tables, the system needs a way to know the actual derived type for a record.
If multiple product subtypes exist, the instance relation helps determine the actual subtype behind the base record.
Yes
This confirms inheritance support is enabled for the table.
The table is part of D365's table inheritance framework.
The system can model parent-child table structures where shared fields live in the parent and specific fields live in subtype tables.
This is a big architectural signal:
EcoResProduct is not just "a table" If you need to remember the most important ones from all of this, focus on these:
SaveDataPerCompany=No
This means the table is shared/global, not company-specific.
Abstract=Yes
This means it is a base abstract table.
SupportInheritance=Yes
This means inheritance is enabled.
Primary Index=SurrogateKey
The table uses a surrogate-key-based identity model.
Replacement Key=DisplayProductNumberIdx
Users see a business-friendly product identifier instead of RecId.
Modules=ProductInformationManagement
This table belongs to PIM.
You can explain this table like this:
EcoResProduct is a core shared product table in D365 F&O. It belongs to Product Information Management, stores global product-level information, is not company-specific, and is designed as an abstract inheritance-enabled base table. It uses a surrogate key internally and a business-friendly replacement key for user display.