Entities

This topic covers information specific to the Entity super type that is important to know when working with entities. For general object maintenance information (applicable to all object types rather than specific to entities), refer to the All Objects topic within this guide here.

A STEP entity can be any object not defined as a product. Entities are commonly used to model customer-related data, such as contacts, addresses, markets, or customers, though they can be used for any number of data modeling scenarios, including modeling of reference data.

Entities differ from products in that they do not contain all of the product-specific functionality like specification attributes, value inheritance, or tables. As entities can only use description attributes, the application of category-specific attributes is not supported. Therefore, attributes are applied to entities strictly via object type validity and all entity instances of a particular object type will have the same attributes available for population. Additionally, entity handling is limited for publishing (e.g., as part of print publishing solutions as defined in the Publisher (Adobe InDesign Integration) documentation here), and you cannot translate entities using a background process.

Entities may or may not be subject to approval, dependent upon the revisability settings (globally revisable entities are the same in the Main and Approved workspaces, while workspace revisable entities adhere to standard approval concepts). This provides a great deal of freedom in determining how entities are handled, specifically in terms of how events are generated and processed. For more information, refer to the Revisability on Entity Object Types section of the Getting Started documentation (here) or the Events section of the System Setup documentation (here).

Entities cannot be linked into classifications, though configuration of entity references allows for determination of a hierarchical display (with source displayed as child to target, or vice versa). In effect, this makes classifications unnecessary for use with entities as entities can be classified via entities. Additional information on this is available in the Entity Reference Types section (here) of the System Setup documentation.

However, entities do retain the standard data modeling capabilities and provide even more configurability. The Revisability parameter allows you to define an entity object type that does not have to be approved and also determines how events are processed.

Entity Hierarchy

Any number of entity hierarchies can be added to any system. For example, you may set up address hierarchies, customer hierarchies, market hierarchies, and so on. Entities are represented by icons chosen as part of the implementation process and will likely differ on each system. The following is an example of an entity hierarchy.

For more information on hierarchy setup, refer to the Object Types and Structures section of the System Setup documentation here.

Entity Editor

Once the entity hierarchy is created and description attributes are applied to the entity object types, the next logical step is to start entering values.

Note: Only description attributes can be applied to an entity object types and will appear in the entity editor. Specification attributes are not allowed on entities.

For example, the image above shows an entity modeled as an address. The entity object has several description attributes: City, Country, State, Street, and Zip. In addition to the Name attribute, these attribute can be modified and maintained. Since this entity object type has been modeled to be globally revisable, approval is not applicable. Therefore, the Approval Status field is not shown.