Fields and Attributes

Entities are created with a default set of system fields, which provide the basic structure for data management. You can enhance entities by adding custom fields of various types or modifying existing ones. Field customization is available for both predefined entities (such as Product) and custom entities created by users.

For detailed information about each data type and its specific configuration options, see Data Types.

Field Types and Restrictions

Field modification restrictions apply based on field origin:

• Predefined fields in predefined entities cannot be deleted
• Default fields (like Name, Description) in any entity cannot be deleted
• System fields (like ID, Created At, Created By, etc.) cannot be modified in any entity

The Fields panel in an Entity record displays all fields contained within the entity, providing a comprehensive view of the entity's data structure.

UI Display: It is up to Layouts settings how the field (either custom or predefined) will look like in the UI. Layouts control field positioning, visibility, presentation in forms and lists, and overall user interface appearance.

Access Control: Field-level access permissions can be configured through Roles.

Creating Fields

Required Fields

When creating a new field, the following fields must be configured:

Code, Type, Entity values cannot be changed after field creation.

Configuration Options

Additional configuration options are available when creating fields.

The following options are available for all or most field types:

• Required: Field must be filled in.
• Read-only: Field is not editable in the UI.
• Non Comparable: Field is excluded from comparison operation.
• Uninherited: Field value is not inherited in entity hierarchies.
• Tooltip: Enables contextual help for the field, supporting text and links. Can be localized — see Labels.
• Create no record activity: Changes in this field are not displayed as Activity.
• No recording as modification: Changes to this field will not update the Modified at timestamp.
• Protected: Field value is read-only from UI and from API.

For detailed information about configuration options specific to each data type, see Data Types.

The Relation management panel is available for Link and Multiple Link field types. This panel provides additional configuration options for managing relationships between entities, including:

• Entity selection: Choose which entity to link to
• Relationship configuration: Set up how the relationship behaves
• Display options: Configure how related records appear in the interface

For detailed information about configuring relationships and using the Relation management panel, see Fields and Relations.

Field Behavior and Validation

Fields can be configured with various behavior controls and validation rules to ensure data quality and user experience:

• Type-specific options: Each data type includes built-in configuration options (e.g., validation rules, display formats, behavior settings). See Data Types for advanced configuration details.
• Data quality rules: Apply comprehensive data quality validation through the Data Quality module, which provides advanced validation, cleansing, and monitoring capabilities.

Conditional Properties

Certain field options can be dynamically controlled using Conditional Properties. These properties define how a field behaves based on specific conditions or context. One or more conditional properties can be applied simultaneously.

Conditional properties are configured through the Basic conditions type. This functionality allows administrators to define specific field properties that will be automatically applied when predefined conditions are met.

Visible

Specifies whether the field should be displayed in the user interface when defined conditions are met. When the condition evaluates to true, the field becomes visible to the user. Otherwise, it remains hidden. This property is useful for dynamically adjusting form layouts and displaying only relevant fields based on user input or record state.

Required

Specifies whether the field must contain a value when defined conditions are met. When the condition evaluates to true, the field becomes mandatory. This property is typically used to enforce data integrity for specific business scenarios.

Protected

Determines whether the field should be protected from modification when certain conditions are met. When active, the field remains visible but cannot be edited, regardless of user permissions via API or AI. This property is often used to prevent critical data from being changed after a record reaches a certain state or approval stage.

Read-only

Specifies that the field should be displayed in a non-editable state in the UI when certain conditions are met. In this mode, users can view the field's value, but cannot modify it.

Disabled options

This property only appears for List and Multi-value list type fields. It specifies that the selected options should be disabled when certain conditions are met.

Fields vs Attributes

While this article focuses primarily on fields, it's important to understand the distinction between fields and attributes in AtroCore:

Fields are standardized data points that are consistent across all records within an entity. They provide uniform and constant information such as name, description, and other essential data that applies universally to all records of that entity type. Fields ensure consistency and facilitate efficient data management and retrieval.

Attributes are dynamic characteristics that can vary between individual records of an entity. Unlike fields, attributes are not automatically applied to all records - they can be selectively assigned to specific groups or individual records as needed. This makes attributes ideal for describing characteristics that vary across records, such as size, color, or functionality.

For detailed information about attributes and their management, see Attribute Management.

Basic conditions type

The Basic condition type enables administrators to define conditional logic for applying property values to records. Conditions are evaluated whenever a record is created or updated, and the resulting property updates are applied only when all defined criteria are satisfied.

Basic conditions support the use of logical operators AND(), OR(), and NOT(), allowing construction of complex rule sets that combine field-based criteria, attribute-based criteria, and user-related criteria.

Condition Components

Each Basic condition consists of one or more of the following elements:

Field

Allows defining a rule based on the value of a specific field in the entity. The following comparison operators are available:

• Equals / Not Equals — checks whether the field value matches or does not match the specified value.
• Is Empty / Is Not Empty — checks whether the field contains no value or contains value.
• Contains / Does Not Contain — checks whether the field contains or not the specified value.
• Greater Than Or Equals / Less Than Or Equals — checks whether the field value is greater/lesser than or equal to, the specified value (applicable to numeric, date, and comparable field types).

Attribute

Allows defining a rule based on an attribute linked to the current entity (applicable only if the entity supports attributes). Supported conditions include but are not limited to:

• Equals / Not Equals — compares the attribute value against a specified value.
• Is Empty / Is Not Empty — checks whether an attribute value is set.
• Contains / Does Not Contain — checks whether an attribute contains or not the specified value.
• Is Linked / Is Not Linked — verifies whether an attribute is linked to the record.
• Greater Than Or Equals / Less Than Or Equals — checks whether an attribute value is greater/lesser than or equal to, the specified value (applicable to numeric, date, and comparable attribute types).

Current User

Enables applying property updates based on information about the currently logged-in user. Supported conditions include:

• Is Empty / Is Not Empty — verifies presence of user context.
• Equals / Not Equals — checks if the current user matches a specified user.
• Is In / Not In — checks if the user is one of the selected user(s).
• Is In / Not In Team — checks membership in selected team(s).

Example

In the configuration shown below, the condition specifies:

• The field Classifications must include the option LED driver.
• The current user must be Admin.
• The current user must not be auto-test.

When all these criteria evaluate to true, the property values defined for the Basic conditions type are applied.