Overview
When creating your Data Model, note that Bizagi presents six different types of entities: Master, Parameter, System, Application, Persona and Runtime.
Each of these types of entities is oriented to a specific purpose, in order offer your processes the possibility to rely on all powerful Bizagi UI features and optimization aspects.
Consider the characteristics of each of the types of entities, so that you design best your data model with important aspects in mind such as: UI functionality, performance and usability, or overall maintainability and reusability aspects.
Master entities are shown in Bizagi Studio in blue color.
In this type of entity, Bizagi will hold information directly related to process cases, such as: a request's date, the request's customer information, or any amount of products requested for that case.
Therefore, typical examples of Master entities are: Customer, Request, or Product (those which usually have their detail typed in through fields, or whose records are searched for and selected by means of an auto-complete text box, or inputted into a table having many rows).
Information is stored in Master entities according to the data being filled in by end users, as the process moves forward (you may see this type of entity as the type holding transactional records).
The Process Entity defined for your processes is a Master Entity, and this entity in particular is the entry point of your business information, which also connects to other entities of your Data Model.
View more information about the Process Entity.
|
You can include as many Master entities as your project requires. In each entity, it is recommended that you do not include more than 85 attributes (even though it is not usual to have more than 30 attributes, for instance, when following standard good design practices in a data model, such as normalization).
Exceeding the maximum amount of attributes may compromise the performance of your project (i.e data access operations related to such entity may take longer). |
Parameter entities are shown in Bizagi Studio in green color.
In this type of entity, Bizagi will store a list of predefined values (or parameter values of your business), such as: a city in which the request originates, a customer's gender, or the type/classification of a customer.
Therefore, typical examples of Parameter entities are: City, Gender, or Customer type (those whose records are usually selected by means of a drop-down list).
In Parameter entities you will find values which are independent from a specific process case (not transactional), though these will be bound to any cases.
Parameter entities in particular, have the following important characteristics:
•You have the possibility to classify them into 2 sub-types: Manageable in production, and not manageable in production (managed in development instead).
If manageable in production, values of that entity will need to be entered and modified directly in the production environment, since these will not be promoted from a development environment (save only, for the very first time in an initial deployment)
If not manageable in production, values of that entity will be promoted from a development environment into a production environment and Bizagi will not allow the creation of new records in them nor modification to the existing ones in a production environment.
To view more information and guidelines about this concept, refer to Where to manage Parameter entities.
•You may not create new records in them, nor modify the existing ones during process execution.
Since they hold a list of predefined values for your processes, Bizagi uses optimization measures when loading these values.
New records or modifications to existing ones should be done as part of your system's administration tasks.
|
You can include as many Parameter entities as your project requires. In each entity, it is recommended that you do not include more than 85 attributes (even though it is not usual to have more than 30 attributes, for instance, when following standard good design practices in a data model, such as normalization).
Exceeding the maximum amount of attributes may compromise the performance of your project (i.e data access operations related to such entity may take longer). |
Persona entities are shown in Bizagi Studio in purple color.
In this type of entity, Bizagi embody the Persona classification for end users, as defined for Experience design.
Therefore, typical examples of Persona entities are: Employee, Customer, or Sponsor (those who has an interest in the project).
This type of entity belongs to the internal data model of Bizagi and includes information concerning end users.
System entities are created by default in each project; you may not create additional system entities nor add or modify its attributes.
Bizagi presents them to provide with the possibility to associate them from within a Master or Parameter entity (specifically, a reference to the WFUser from Parameter entities being manageable in production, or a reference to other System entities from Parameter entities manageable in development).
Some of the System entities presented by Bizagi are: WFUser (where end users of the project are stored), Area, Location, or Role (all related to end users' further organizational detail).
|
You may not include additional attributes in System entities. If you need to store or map additional information related to your end users, you may define user properties within the organizational definition in your project. For more information about this feature, refer to user properties. |
Application entities are located in Bizagi Studio under the Application entity category showing a Bizagi icon.
This type of entity, centralizes the information of each business application.
Recall that a Bizagi project may hold any number of processes, and business applications are the first criteria to classify a group of processes.
Hence, the Application entity represents that entry point of information in the system (manages the entire data model), for a group of processes.
Application entities are generated automatically by Bizagi when an business application is defined (named after that application), in order to promote an structural organization of processes.
You may not delete these entities, though you may create new ones when needed or modify their attributes (their attributes are namely references to Process entities).
Runtime entities contain read-only information relating Bizagi’s process and cases internal data.
They are also available from Forms, Expressions, Document templates, emails and Connectors.
Information that is available through Runtime entities includes: On going Activities and its status history, the currant case and it's status history, the allocation history for the current case, the reallocation history of the current case and the transition history.
Runtime entities are created by default in each project; you may not create additional entities nor add or modify their attributes.
Change between entity types
You can change entity-types between Master, Parameter and Persona with some restrictions.
The entity-type change must be done in the development environment, and it is available as long as there are no dependencies in the entity you are changing.
When you change an entity from one type to another, the values of the entity will be deleted. If an entity has been deployed to the Production environment, it cannot be changed.
The following table shows the options available:
From / To |
Master |
Parameter |
Persona |
|---|---|---|---|
Master |
- |
Dependencies reviewed Data will be cleaned |
No dependencies reviewed No data cleaned Cannot be Process Entity |
Parameter |
Dependencies review Data will be cleaned |
- |
- |
Persona |
- |
- |
- |
Changing Master entities to Persona is the only exception: the change can be done even if the entity has been deployed. No dependency validations are performed and no data will be lost.
Last Updated 12/12/2024 12:06:08 PM