Asset Baselines
Asset Baselines in Omega 365 capture, control, review, approve, and compare asset configurations at key points, enabling structured change management.
Asset Baselines provide a controlled way to capture, review, approve, and compare the configuration of objects at defined point in time.
A baseline represents the state of selected objects when the baseline version was created. It can include object information, properties, document relationships, and relationships between objects.
Baselines can be used throughout the asset lifecycle to establish approved configuration states, track changes, and compare the configuration between different stages of a project or asset lifecycle.
Understanding Asset Baselines
What is a Baseline?
A baseline is a recorded configuration of a defined set of objects at a specific point in time.
When a baseline version is created, Omega 365 captures the relevant information for the objects included in the baseline. The captured information is retained with that version even if the live objects are changed later.
A baseline can therefore be used as a reference for determining:
What objects were included at a particular stage
What information was registered on those objects
Which documents were connected to the objects
Which relationships existed between objects
What has changed since the baseline was created
What changed between two baseline versions
What changed between different baselines
A baseline should not be considered a separate copy of the Object Register. The live objects remain in the Object Register, while the baseline provides a controlled historical representation of their configuration.
Baselines and Versions
A baseline can contain multiple versions.
For example:
Baseline: Allocated Design Baseline
Version 1 – Initial approved configuration
Version 2 – Updated configuration following approved changes
Version 3 – Later approved configuration
Creating a new version does not overwrite previous versions. Each version remains available for review and comparison.
This provides a history of how the configuration represented by the baseline has developed over time.
Baseline Types
Baseline Types are used to distinguish between different purposes or stages of configuration control.
The Baseline Types available in a solution depend on how the solution has been configured. Workflow/Approval Process can be set per baseline type.
Typical examples may include:
Functional Design Baseline
Allocated Design Baseline
Manufacturing and Construction Baseline
As-Manufactured Baseline
As-Built Baseline
The terminology and number of Baseline Types may vary between projects and organizations.
Baseline Lifecycle
Typical Baseline Process
A typical baseline lifecycle consists of the following steps:
Relevant objects are selected.
A baseline is created.
Version 1 of the baseline is generated.
The baseline version is submitted for approval if an approval process is configured.
The baseline is reviewed.
The baseline is approved or rejected.
Changes may later be requested for objects controlled by the baseline.
Approved changes are implemented.
A new baseline version can be created to capture the updated configuration.
The new version is reviewed and approved.
This allows the baseline to develop together with the controlled configuration while previous versions remain available for reference.
Baseline Approval
A Baseline Type can be configured with an approval process.
When a baseline version requiring approval is created, an approval workflow is started.
The approval workflow is used to review and formally accept or reject the captured configuration.
The baseline displays information about the associated approval process and its current status.
Approved Baselines
An approved baseline version represents an accepted configuration state.
Approval does not remove the historical information captured by the baseline.
The approved version remains available for later review and comparison.
Objects included in an active controlled baseline remain subject to baseline change control until that control is released through the applicable process.
Rejected Baselines
If a baseline approval is rejected, the rejected version remains part of the baseline history.
The objects are released from the baseline approval control associated with the rejected approval.
The baseline can subsequently be corrected or updated as required before continuing the configuration process.
Cancelled Baseline Approval
Users with the required permissions can cancel an ongoing baseline approval.
Cancellation is intended for situations where an approval process should no longer continue, for example because the baseline was created incorrectly or the approval should be restarted later.
A baseline approval cannot be cancelled after the approval process has already been closed.
When an approval is cancelled:
The cancellation is recorded on the baseline version
The user who cancelled the approval is recorded
The associated approval process is cancelled
The objects are released from that baseline approval control
Cancelling an approval does not delete the baseline version or its captured information.
Creating a Baseline
Selecting Objects
A baseline is created from selected objects in the Object Register.
The objects included should represent the configuration scope that needs to be controlled.
Depending on the purpose of the baseline, this could include:
A complete system
A subsystem
A defined equipment scope
Objects associated with a particular design stage
Objects required for a project milestone or configuration gate
The exact scope should be determined according to the project's configuration management requirements.
Creating the Baseline
To create a baseline, the user must have the Can Create Snapshot/Baseline capability for the selected Org Unit.
If the user does not have this capability for the selected Org Unit, they cannot create a baseline for that organizational scope.
To create a baseline:
Open the Object Register.
Select the objects that should be included.
Select Tasks --> Create Snapshot/Baseline for Selected Objects.
Enter the required baseline information.
Select the appropriate Baseline Type.
Confirm the creation of the baseline.
Omega 365 creates the baseline and its first version using the selected objects.
If an approval process is configured for the selected Baseline Type, the approval process is also initiated.
Naming a Baseline
Use a name that clearly identifies the configuration scope represented by the baseline.
The name should make it possible for users to distinguish the baseline from other baselines of the same type.
For example:
Allocated Design – Cooling Water System
As-Built – Electrical Distribution
Manufacturing Baseline – Pump Package A
Avoid names that only describe the Baseline Type when several baselines of the same type may exist.
What is Captured in a Baseline?
Object Information
The baseline captures object information applicable to the object at the time the version is created.
This allows later comparison with the current object or another baseline version.
Fields and Properties
Object fields and properties are captured as part of the baseline.
When reviewing an object from a baseline, users can see the values recorded in the selected baseline version and compare them with another configuration state.
Examples may include:
Object identification
Description
Classification information
Technical properties
Dates
Numeric values
Other configured object attributes
The exact fields and properties available depend on the object configuration.
Documents
Document relationships associated with the objects are captured in the baseline.
The baseline information can be used to determine which documents and revisions were associated with an object when the baseline version was created.
This is useful when configuration control includes both physical or functional objects and their supporting documentation.
Object Relationships
Relationships between objects are also captured.
This allows users to review how objects were related at the time the baseline version was created and identify relationships that have subsequently been added, removed, or changed.
Viewing Baselines
Asset Baselines Register
The Asset Baselines register provides an overview of the baselines available in the solution.
The register can include information such as:
Baseline name
Baseline Type
Current version
Approval information
Creation information
Select a baseline to open its details.
Baseline Details
The baseline details page provides access to the baseline and its versions.
From this page, users can:
Select a baseline version
Review approval information
View objects included in the selected version
Compare objects between baseline configurations
Open detailed comparison information for individual objects
Selecting a Version
Use the Version selector to select the baseline version you want to review.
Changing the selected version changes the baseline context shown in the application.
Previous versions remain available and are not replaced when a new version is created.
Creating a New Baseline Version
When to Create a New Version
A new baseline version should normally be created when the controlled configuration has changed and the updated state needs to be captured.
For example:
Baseline Version 1 is approved.
A change to one or more controlled objects is requested.
The change is approved.
The approved change is implemented in the Object Register.
A new baseline version is created.
The new baseline version is reviewed and approved.
This establishes a new controlled configuration while preserving the previous baseline version.
Creating the New Version
To create a new version:
Open the relevant baseline.
Open Tasks.
Select Create New Version.
The new version captures the configuration applicable at the time it is created.
If the Baseline Type has an approval process configured, a new approval process is initiated for the new version.
Change Control
Changes to Baselined Objects
Objects that are under active baseline control cannot be changed freely.
This ensures that the controlled configuration is not modified without following the required change process.
When a controlled object needs to be changed, a Change Request can be used to formally request and approve the change.
Change Requests
A Change Request provides controlled authorization to make changes to an object that is part of a controlled baseline.
The Change Request should describe the required change and follow the configured review and approval process.
Approved Change Requests
When a Change Request is approved, the object is released for implementation of the approved change.
The baseline itself is not modified. Existing baseline versions continue to represent the configuration captured when they were created.
After the approved change has been implemented, a new baseline version should normally be created when the updated configuration is ready to become part of the controlled baseline.
This creates a clear sequence:
Approved Baseline → Change Request → Approved Change → Updated Object → New Baseline Version → Approval
Rejected Change Requests
If a Change Request is rejected, the requested change is not authorized.
The Change Request is closed, but the object's existing baseline control remains in place.
The object therefore continues to be controlled by the existing baseline.
Comparing a Baseline with the Current Configuration
Baseline to Current Comparison
A baseline version can be compared with the current configuration in the Object Register.
This answers the question:
"What has changed since this baseline version was created?"
The comparison can include:
Fields and properties
Documents
Object relationships
Differences are categorized by change type.
Added
Added means that the information exists in the comparison state but did not exist in the base state.
When comparing a baseline with Current, this normally means the information was added after the baseline version was created.
Removed
Removed means that the information existed in the base state but does not exist in the comparison state.
When comparing a baseline with Current, this normally means the information has been removed since the baseline was created.
Changed
Changed means that the same item exists in both states, but one or more of its values are different.
For example, a property may exist in both the baseline and Current but have a different value.
Unchanged
Unchanged means that the information is identical in both compared states.
Unchanged information may be hidden by default to make differences easier to identify.
Use the available filters to include Unchanged information when required.
Comparing Baseline Versions
Version-to-Version Comparison
Different versions of a baseline can be compared.
For example:
Allocated Design Baseline Version 2 → Allocated Design Baseline Version 3
This allows users to identify what changed between two controlled configuration states.
The selected Base version represents the starting point, while the Compare version represents the configuration being compared against it.
The direction of the comparison is important.
For example:
Version 2 → Version 3
means:
Added = added in Version 3
Removed = present in Version 2 but not Version 3
Changed = exists in both but has different information
Reversing the comparison may therefore change whether an item is shown as Added or Removed.
Comparing Different Baselines
Cross-Baseline Comparison
Omega 365 can compare an object between different baselines and baseline versions.
This is useful when the same configuration develops through different lifecycle stages.
For example:
Allocated Design Baseline Version 3 → As-Built Baseline Version 1
This allows users to identify differences between the allocated design configuration and the final as-built configuration.
Selecting the Comparison Baseline
When viewing an object from a baseline, the baseline on the left is the Base baseline.
The Base baseline is determined by the baseline context from which the object was opened and is not changed from the comparison view.
The Base version can be selected using the Version selector.
Under Compare with, select the baseline that should be compared against the Base baseline.
After selecting a baseline, select the required version.
The comparison is then performed as:
Base Baseline / Base Version → Compare Baseline / Compare Version
Comparing with Current
Instead of selecting another baseline, select Current to compare the Base baseline version with the current object configuration in the Object Register.
This provides two different types of analysis:
Baseline → Current
or
Baseline A / Version X → Baseline B / Version Y
Comparing an Object Not Present in Both Baselines
An object does not have to exist in both compared baselines. This is important when comparing different configuration stages.
If an object exists in the Base baseline but not in the comparison baseline, the comparison can identify that the object or associated information is no longer present in the comparison configuration.
Similarly, when comparing complete baseline scopes, objects that exist only in the comparison baseline can be identified as Added.
Object Comparison
Comparing Baseline Scope
The Object Compare function provides a higher-level comparison of the objects included in two baseline configurations.
This can be used to identify changes in the baseline scope before reviewing individual object details.
The comparison identifies objects according to their presence in the two selected configurations.
Added Objects
An Added object exists in the Compare baseline/version but not in the Base baseline/version.
Removed Objects
A Removed object exists in the Base baseline/version but not in the Compare baseline/version.
Unchanged Objects
An Unchanged object exists in both baseline versions.
An object being categorized as Unchanged at this level means that the object exists in both compared baseline scopes. Detailed object information may still be reviewed separately where required.
Opening an Object Comparison
Select an object from the comparison to open its detailed baseline information.
The detailed comparison retains the selected Base baseline/version and Compare baseline/version.
This allows users to move from the overall scope comparison directly into the detailed configuration differences for the selected object.
Detailed Object Comparison
Fields and Properties
The Fields and Properties section compares captured object values.
Depending on the comparison, values are shown from:
The Base baseline version
The selected Compare baseline version
Current Objet Register information
Changed values show the value from the Base configuration and the value from the Compare configuration.
Documents
The Documents section shows differences in documents associated with the object.
The comparison can identify documents that have been:
Added
Removed
Changed
Left unchanged
Document information may include document name, title, revision, and revision date.
Connections
The Connections section compares relationships between objects.
This can identify relationships that have been added, removed, changed, or retained between the two configuration states.
The comparison can include information about:
Connection Type
From Object
To Object
Relationship information
Comparison Filters
Filtering by Change Type
Comparison views provide filters for the different change types.
Available filters include:
Added
Removed
Changed
Unchanged
Use these filters to focus the comparison on the information relevant to the review.
Showing Only Differences
For most configuration reviews, the most useful view is to display:
Added
Removed
Changed
and hide:
Unchanged
This provides a concise overview of the differences between the selected configurations.
Enable Unchanged when a complete verification of both configurations is required.
Baseline Information on Objects
Baseline Indicator
Objects that are currently under baseline control are identified in the Object Details view.
The baseline information identifies the active baseline associated with the object and can include:
Baseline Type
Baseline name
Version
The baseline information provides a direct link to the relevant baseline.
Baseline Indicator in the Object Register
Baselined objects can also be identified from the Object Register.
This makes it easier to identify objects that are currently subject to configuration control before attempting to modify them.
Approval Information
Viewing Approval Status
When a baseline version has an associated approval process, the baseline displays the approval information.
Users can open the approval item to review the workflow and its current status.
The exact statuses available depend on the configured approval process.
Approval History
Each baseline version retains its own approval relationship.
This means that Version 1 and Version 2 can have separate approval processes and approval outcomes.
The version history therefore provides both configuration history and the associated approval context.
Recommended Working Method
Establishing the Initial Baseline
When establishing a new controlled baseline:
Confirm that the required objects and configuration information are ready.
Select the required objects.
Create the baseline using the appropriate Baseline Type.
Review the captured baseline scope.
Review detailed object information where required.
Complete the baseline approval process.
Use the approved version as the controlled configuration reference.
Managing Changes After Approval
When a controlled configuration needs to change:
Identify the object requiring modification.
Create or initiate the applicable Change Request.
Describe and justify the required change.
Complete the Change Request approval process.
If approved, implement the authorized change.
Verify the updated object configuration.
Create a new version of the relevant baseline when the updated configuration is ready.
Review the differences between the previous and new versions.
Complete approval of the new baseline version.
Reviewing a New Baseline Version
Before approving a new version, use the comparison functionality to review the changes.
For example:
Version 2 → Version 3
Review:
Added objects
Removed objects
Changed fields and properties
Changed document relationships
Changed object relationships
This provides a structured way to verify that the new baseline version contains the intended configuration.
Comparing Lifecycle Stages
Cross-baseline comparison can be used when configuration needs to be verified between lifecycle stages.
For example:
Functional Design → Allocated Design
Allocated Design → Manufacturing and Construction
Manufacturing and Construction → As-Built
The actual Baseline Types and comparison sequence depend on the configuration management model used by the project.
Example: From Design Baseline to As-Built
Initial Design Baseline
A project establishes:
Allocated Design Baseline – System A
Version 1 is created and approved.
The baseline now represents the approved allocated design configuration for System A.
Design Change
A component requires modification.
A Change Request is created and approved.
The authorized change is implemented in the Object Register.
A new version of the Allocated Design Baseline is then created.
The project compares:
Allocated Design Version 1 → Allocated Design Version 2
The comparison confirms the changes introduced by the approved modification.
Version 2 is then reviewed and approved.
As-Built Baseline
Later in the project, an As-Built Baseline is established.
Users can compare:
Allocated Design Version 2 → As-Built Version 1
The comparison can be used to identify differences between the approved design configuration and the final as-built configuration.
Users can first review changes in the overall object scope and then open individual objects to review detailed differences in fields, properties, documents, and relationships.
Important Concepts
A Baseline is Historical
A baseline version represents the configuration captured when that version was created.
Changing the live object does not rewrite an existing baseline version.
New Versions Preserve History
Creating a new version does not replace previous versions.
Previous versions remain available for comparison and historical review.
The Base Determines Comparison Direction
Always consider the direction of the comparison.
Base → Compare
An item shown as Added exists in Compare but not Base.
An item shown as Removed exists in Base but not Compare.
Current Means Live Configuration
When Current is selected, the baseline version is compared with the current information in the Object Register.
Current is not another baseline version.
Different Baselines Can Be Compared
The Compare baseline does not need to be the same baseline as the Base.
This allows configuration to be compared between different lifecycle stages and different Baseline Types.
Baseline Approval and Change Approval Serve Different Purposes
Baseline approval accepts a captured configuration state.
A Change Request authorizes a change to a controlled configuration.
After an approved change has been implemented, a new baseline version can be created to establish the updated controlled configuration.
Frequently Asked Questions
Does creating a baseline create new Object Register objects?
No. The baseline captures the configuration of the selected objects. The live objects remain in the Object Register.
Does creating a new baseline version overwrite the previous version?
No. Previous versions remain available.
Can I compare a baseline with the current Object Register?
Yes. Select Current as the comparison target.
Can I compare two versions of the same baseline?
Yes. Select the required Base version and select the same baseline with another version as the comparison target.
Can I compare two different baselines?
Yes. The Base baseline remains fixed, while another baseline and version can be selected under Compare with.
Can I compare different Baseline Types?
Yes. For example, an Allocated Design Baseline can be compared with an As-Built Baseline.
What does Added mean?
Added means that the item exists in the Compare configuration but not in the Base configuration.
What does Removed mean?
Removed means that the item exists in the Base configuration but not in the Compare configuration.
What does Changed mean?
Changed means that the item exists in both configurations but its captured information differs.
What does Unchanged mean?
Unchanged means that the compared information is the same in both configurations.
Why does the comparison direction matter?
Because Added and Removed are determined relative to the Base configuration.
For example:
Version 1 → Version 2
may show an item as Added.
Reversing the comparison:
Version 2 → Version 1
would show the same item as Removed.
What happens if a baseline is rejected?
The rejected version remains available as part of the baseline history, while the objects are released from the baseline approval control associated with that rejected approval.
What happens if a Change Request is rejected?
The Change Request is closed and the object's existing baseline control remains in place.
What happens when a Change Request is approved?
The object is released so that the approved change can be implemented. The existing historical baseline versions are not modified.
A new baseline version should normally be created after the approved change has been implemented and the updated configuration is ready to be baselined.
Can an approval be cancelled?
An ongoing baseline approval can be cancelled by users with the required permissions, provided the approval process has not already been closed.
The baseline version itself is retained.
Can an object be included in another active baseline?
An object already controlled by an active baseline cannot normally be added to another active baseline at the same time. A new version of the same baseline can be created as part of the controlled baseline lifecycle.
Workflow Configuration Requirements
Asset Baseline and Change Request workflows require specific configuration to ensure that objects are released correctly when the associated approval process is completed.
Baseline Approval Workflow
For a Baseline Approval Workflow Process, the Process Closed SP parameter must be configured as:
astp_Assets_BaselineWorkflowHandler
This procedure handles the release of objects when the Baseline Approval process is closed.
If the Baseline Approval is closed with status Rejected, the objects associated with the baseline approval are unlocked and released from the approval control.
Asset Change Request Workflow
For an Asset Change Request workflow process, the Process Closed SP parameter must be configured as:
astp_Assets_ChangeRequestWorkflowHandler
When the Change Request is closed with status Approved, this procedure unlocks the objects associated with the Change Request so that the approved changes can be implemented.
Reopening Closed Processes
Baseline Approval and Asset Change Request processes must not be configured to allow a closed process to be reopened.
The object locking and unlocking logic is handled when the workflow process is closed. If a closed process is reopened, the associated objects are not automatically locked again.
Allowing these processes to be reopened may therefore result in the workflow status and the actual object locking state becoming inconsistent.
If a new approval or change cycle is required, a new applicable process should be initiated instead of reopening the previously closed process.
Summary
Asset Baselines provide controlled configuration history for objects in Omega 365.
The functionality allows users to:
Capture object configuration at defined points in time
Maintain multiple versions of a baseline
Review and approve configuration states
Control changes to baselined objects
Compare a baseline with the current Object Register
Compare different versions of the same baseline
Compare different baselines and lifecycle stages
Identify Added, Removed, Changed, and Unchanged information
Review differences in fields, properties, documents, and object relationships
Maintain historical configuration information throughout the asset lifecycle
Used together with approval workflows and Change Requests, Asset Baselines provide a structured process for establishing, maintaining, and reviewing controlled asset configurations.
.svg?scale=thumbnail)
.png?scale=thumbnail)
