A virtual object is a read-only object that combines selected attributes from multiple source objects into a single dataset. Virtual objects do not store data themselves - they present existing data in a consolidated view.
They are typically used to simplify reporting, improve process performance, and reduce the amount of data a process needs to load.
Why Use a Virtual Object?
If several objects store related data that is frequently used together, a process or report would normally need to load each object separately, filter each dataset, and combine them in logic. A virtual object eliminates that overhead by presenting the combined data as a single structure.
For example, if you have separate objects storing daily volumes for different product types, a virtual object could combine them into one view with a single date and entity key - reducing the number of rows loaded and simplifying the filter logic in any process that uses them.
A well-designed virtual object improves clarity and performance. An overly broad one adds unnecessary complexity - keep them focused and purpose-driven.
Key Characteristics
Virtual objects are read-only
They can be used as process inputs
They cannot be used as process outputs
They cannot be referenced by other objects
They cannot be based on another virtual object or a summary object
They do not support file data types or aggregation
Creating a Virtual Object
Virtual objects are configured at Objects \> Virtual Objects in the Configuration application and must be published before they can be used.
Step 1 - Create the virtual object record
Navigate to Objects \> Virtual Objects and click New.
Complete the following fields:
System Name - internal identifier, follow naming conventions
Business Name - displayed in screens and processes
Description - explains the purpose of the virtual object
Main Object (optional) - determines which source object provides the Created At and Modified At timestamps. The selected object must have Filter on Modification Dates set to True. Leave blank if these timestamps are not required.
Enter an Audit Comment and click Save and Refresh.
Step 2 - Add attributes
Each attribute in a virtual object maps to an attribute on a source object.
Select the virtual object and in the Source Attribute panel click Edit.
Enter the number of attributes required and click Add.
For each attribute, define:
System Name - internal name of the virtual attribute
Order - controls display order
Business Name - user-facing label
Description - displayed as tooltip help text
Source Attribute - the source object attribute providing the data
Unique Identifier - set to True for all attributes forming the virtual object's unique key
Optional - controls record inclusion. If True, a record is included even if this attribute has no value. If False, records with no value for this attribute are excluded.
Sort Order and Sort Type - defines default sort behaviour; if blank, sorting defaults to the unique key
Enter an Audit Comment and click Save and Refresh.
Step 3 - Publish
After configuring all attributes, click Publish. The publish process validates the configuration, creates the underlying virtual object, and makes it available for use in screens and processes. If configuration changes later, you must re-publish.
Do not edit the generated virtual object directly via Objects \> Objects. Always make changes through the Virtual Objects configuration screen and re-publish.
Editing a Virtual Object
You can modify a virtual object at any time. Changes take effect only after re-publishing.
Navigate to Objects \> Virtual Objects.
Click Edit and update the required fields, or select the virtual object and edit its source attributes in the lower panel.
Enter an Audit Comment and click Save and Refresh.
Click Publish to apply the changes.
Before editing, check whether the virtual object is used as a process input. Changes to attribute structure or ordering may require updates to dependent process logic workbooks. For guidance on identifying dependencies, see Assess the Impact of Attribute Changes.
How Virtual Objects Handle Dates
When source objects contain date attributes, the publication process applies specific logic to determine how records are joined. This behaviour relies on standard attribute naming conventions.
Date-specific objects - an object is treated as date-specific if it contains an attribute named PRODUCTION_DATE. Records are matched across objects on the same production date.
Date-ranged objects - an object is treated as date-ranged if it contains FROM_DATE. The platform assumes TO_DATE also exists and that date ranges are correctly maintained. An empty TO_DATE is treated as open-ended.
When combining a date-specific object with a date-ranged object, the platform ensures the PRODUCTION_DATE falls within the FROM_DATE to TO_DATE range. However, if primary keys match exactly, primary key matching takes precedence over date-range logic.
These rules are not configurable. If date attribute names do not follow the standard conventions (PRODUCTION_DATE, FROM_DATE, TO_DATE), date logic will not behave as expected.
Creating a Virtual Object from an Existing Object
The platform provides a process that creates a virtual object directly from a standard object. This is useful when you need a copy of an object's structure or a version without units for an OData feed.
Navigate to Processes \> Process Execution and locate ENERGYSYS Create Virtual Object from Object.
Click Run.
The process enforces the following rules on the new virtual object's name: it must not already exist, cannot start with EU_ or ES_, cannot contain spaces, must be a maximum of 24 characters, and must contain _V_.
After the process runs, publish the virtual object manually via the Virtual Objects screen.
Limitations
Virtual objects do not support calculations, aggregation, sums, or averages
They cannot be used as process outputs
They cannot be targets of reference attributes
File data types are not supported
For complex joins, transformations, or aggregations, use a process or a summary object instead.