Data Model – Entities

The Entity model is the most basic part of the model. It defines data entities which in turn define database tables for storing customer data. Entities contain not only fields but also predefined filters, row-level-security rules, row-color rules and more.

Entities are essential for defining internal data structures but also for guiding the ORIGAM Runtime in generating SQL queries automatically.



Model elements which reference entities:

Model Element Reference Attribute
Data structure Entity
Entity Relationship RelatedEntity
Entity Field ForeignEntity


Every entity has the following common attributes.

Caption A description of the entity. Can be used to describe an entity in error messages (e.g. when mandatory fields are not entered).
DescribingField Used to select a field from an entity which can be used to directly describe a row to the user. This can is typically a field that is at the same time a primary key to the table, e.g. an Invoice number. This attribute can be used for error messages to tell the user something like “There is an error in the entity {entity caption} in the row 201420009”.




This entity maps to a database. Database entities can be used in Data Structures referenced by Screen Menu Items or the DataService LoadData method in sequential workflows where they retrieve data from the mapped database tables.

A database entity has these specific attributes:

IsAuditingEnabled When set to True an audit log will be automatically recorded for every change made through ORIGAM. The default is False.
DatabaseObjectType Type of object in the database. Either a table or a view. For views, you need to provide your database script manually using a Deployment Script. Creating scripts for tables can be automated by using the Deployment Script Generator.
DatabaseObjectName The name of the database table or view. Typically you will use the same Name and DatabaseObjectName to keep things simple but you can take advantage of different names e.g. if you want to connect to already existing database tables.
GenerateDeploymentScript When set to False the entity will be skipped by the Deployment Script Generator. This can be useful e.g. if the table already exists and is not under your control. Default is True.


This entity does not map to a database. The main feature of a virtual entity is that it will not require a database script to be generated but at the same time, it will clearly define the internal data structures. It can be useful in the following cases:

Ancestor – You want to create an entity ancestor for inheritance. In this case, you would use a virtual entity because the ancestor entity will not physically exist in the database. E.g. IOrigamEntity2.

Wizard Screen – You want to create a screen in the wizard (sequential workflow connected to a menu) and you need to create a screen whose structure is not defined by any database entities. In that case, you will create a virtual entity and base the screen on this entity. You will not be able to save these data to a database directly by calling a DataService.


flowchart LR
    Entity --- Conditional-Rule[Conditional Formatting Rule]
    Entity --- Filter
    Entity --- Index
    Entity --- Parameter
    Entity --- Relationship
    Entity --- Row-Level-Security-Filter
    Entity --- Row-Level-Security-Rule-Entity
    Entity --- Fields
    Entity --- Actions
    Fields --- Common-Subelements
    Common-Subelements --- Dependency
    Common-Subelements --- Dynamic-Field-Label[Dynamic Field Label]
    Common-Subelements --- Row-Level-Security-Rule-Field[Row Level Security State]
    Fields --- Field-Aggregated[Aggregated Field]
    Fields --- Field-Database[Database Field]
    Fields --- Field-Function[Function Call]
    Fields --- Field-Lookup[Lookup Field]
    Fields --- Field-Virtual[Virtual Field]
click data-model ""