Float on Release in Aras Innovator: When Released Data Should Move Forward

---

In Aras Innovator, versioning is not just a technical detail. It is part of how the product structure tells the truth.

A Part, Document, CAD file, Material, Specification, or Assembly may exist in many generations or revisions. Some are still preliminary. Some are released. Some become obsolete. The difficult question is not whether the item has a new version.

When should everything that references the old version move forward to the new released version?

The Problem: Structures Need Stability, but Revisions Keep Moving

Consider this structure:

Assy 001/01
 ├─ 10 → Assy 002/01
 │       ├─ 10 → Part 003/01
 │       └─ 20 → Part 004/01
 └─ 20 → Part 005/01

At this point, Part 004/01 is already part of the structure.

Now Part 004/01 is revised.

That revision creates:

Part 004/02

But this does not mean that Part 004/02 automatically becomes part of the structure.

The existing assembly still points to the released or controlled revision it already had:

Assy 002/01
 └─ 20 → Part 004/01

Meanwhile, the new revision begins its own life-cycle journey:

Part 004/02 = Preliminary

This distinction is important.

The use case is not:

A completely new item is created,
therefore existing structures should consume it.

The real use case is:

An item already used in a structure is revised.
The new revision starts in Preliminary.
The existing structure continues to point to the older revision.
When the new revision becomes Released,
eligible references may move forward.

That is the core idea behind Float on Release.

Do not float because a new revision exists.
Float only when the revised item reaches the correct life-cycle state, and only when the configured rules allow it.

---

Why Preliminary Revisions Should Not Be Consumed Automatically

When Part 004/02 is created through revision, it is usually not immediately ready for use.

It may be in Preliminary. It may still need engineering changes. It may fail review. It may be rejected. It may be replaced by another revision. It may not yet have the correct documentation, validation, or approval.

So even if the newer revision exists, the existing structure should normally remain stable:

Assy 002/01
 └─ 20 → Part 004/01

Only later, when Part 004/02 is promoted to Released, should the system ask:

Are there existing references to older generations of this same logical item?

Are those references allowed to move forward?

Does the rule permit this source item, relationship, and released revision?

If the answer is yes, then the reference can float:

Before:
Assy 002/01 → Part 004/01

After:
Assy 002/01 → Part 004/02

This is not uncontrolled latest-version behavior.

It is release-driven, rule-controlled reference movement.

---

Native Aras Innovator Behavior: Fixed, Float, Hard Fixed, and Hard Float

Aras innovator already provides an important foundation through Item Behavior.

Item Behavior can be defined on RelationshipTypes and Life Cycle States. The common values are:

• Fixed
  The parent points to a specific generation of the related item.
• Float
  The parent points to the latest generation of the related item.
• Hard Fixed
  The reference is fixed and cannot be changed later by state behavior.
• Hard Float
  The reference floats and cannot be changed later by state behavior.

In the earlier life-cycle guide, I explained that RelationshipType behavior and Life Cycle State behavior interact. If the RelationshipType is Hard Fixed or Hard Float, it overrides the state behavior. Otherwise, the state can influence how the relationship behaves while the item is in that state.

This gives Aras a powerful native model. But there is still a practical architectural question:

Should a reference move because a newer generation exists, or should it move only when the newer revision is released?

For many business scenarios, release timing matters.

---

The Timing Problem: Revision Is Not the Same as Release

Remember, A revision is a work process while release is a business decision.

When Part 004/01 is revised to Part 004/02, the system has created a new version of the same logical item. But that new version is not automatically valid for consumption.

This is why the difference between “revision exists” and “revision is released” matters.

Part 004/01 = Released
Part 004/02 = Preliminary

At this moment, the correct structure may still be:

Assy 002/01
 └─ 20 → Part 004/01

Later:

Part 004/02 = Released

Now the system may evaluate whether the structure should move forward:

Assy 002/01
 └─ 20 → Part 004/02

The release event becomes the trigger.

That is why I call this pattern Float on Release.

---

What “Same Logical Item” Means

In Aras Innovator, different revisions or generations of the same logical item are connected through the same config_id.

For example:

Part 004/01
Part 004/02
Part 004/03

These are different item IDs, but they represent the same logical item across revisions.

So a Float on Release engine should not search by name alone. It should not simply look for matching item numbers. It should use the stable logical identity:

same config_id
older item id
newly released item id

That is how the engine knows that Part 004/01 and Part 004/02 belong to the same version chain.

---

Float on Release: The Rule-Based Concept

The concept can be described like this:

When an item is released,
find references to older generations of the same config_id,
evaluate the configured rules,
and update only the eligible references to the newly released item.

The engine should not blindly update everything.

It should ask:

• Is this released item type covered by a float rule?
• Is this relationship type included?
• Is this reference property included?
• Is the source item allowed to move forward?
• Is the existing relationship allowed to move forward?
• Is the newly released item in an acceptable state?
• Is the old referenced item eligible to be replaced?
• Is the source item frozen, obsolete, baselined, or under change control?

Only when the rule passes should the reference move.

This turns floating into a governed release behavior, not a technical accident.

---

The Engine Has Two Paths

A complete Float on Release engine needs two paths:

1. Relationship floating
2. Property floating

That distinction matters because not all references in Aras are stored in relationships.

Some references are relationship rows, such as Part BOM or Part Document.

Other references are direct item properties, such as a Material pointing to a specification document through a property.

Both need to be handled.

---

Path 1: Relationship Floating

Relationship floating handles relationship rows where related_id points to an older generation of the released item.

Typical examples:

Part BOM
Part Document
Part CAD
Part Standard
Material Specification
Document Reference

Example before release:

Assy 002/01
 └─ 20 → Part 004/01

Now Part 004/01 is revised:

Part 004/02 = Preliminary

Nothing should move yet.

The structure remains:

Assy 002/01
 └─ 20 → Part 004/01

Later, Part 004/02 is promoted:

Part 004/02 = Released

Now the Float on Release engine looks for relationship rows where:

related_id points to an older generation
of the same config_id as Part 004/02

If the rule passes, the engine updates the relationship row:

relationship_table.related_id = newly_released_item_id

After floating:

Assy 002/01
 └─ 20 → Part 004/02

This is useful when the business meaning of the relationship is:

This structure should consume the latest released revision of the referenced item, but only after that revision is actually released.

---

Path 2: Property Floating

Not every reference is a relationship.

Sometimes an item has a direct property that points to another item.

Examples:

Material.specification
Document.template
Part.standard
Item.reference_property

Before release:

Material A
 └─ property = Specification 001/01

Now Specification 001/01 is revised:

Specification 001/02 = Preliminary

The material should still point to the old released specification:

Material A
 └─ reference_property = Specification 001/01

Later:

Specification 001/02 = Released

If the rule allows it, the engine updates the direct reference property:

reference_item.reference_property = newly_released_item_id

After floating:

Material A
 └─ reference_property = Specification 001/02

This is important because a relationship-only solution would miss many real-world Aras reference patterns.

---

The Rule Model

The engine should be rule-driven.

A Float Rule can define:

Released item type
Affected relationship types
Affected reference properties
Conditions for the source/context item
Conditions for the relationship row
Conditions for the old referenced item
Conditions for the newly released item

For example:

When a Document revision is released:
  update Part Document relationships
  only where the Part is not Obsolete
  only where the document role is Manufacturing Specification
  only where the new Document is Released

Another example:

When a Material revision is released:
  update direct material references
  only where the referencing item is not frozen
  never update historical baselines

Another example:

When a lower-level Assembly revision is released:
  update parent assembly BOM references
  only where the parent assembly is allowed to consume floating children
  only where the relationship type is configured for release floating

This is the main design principle:

Float on Release is not one global behavior.
It is a configurable policy.

---

Example XML Rule Condition

A rule condition can be stored as XML and parsed into predicates.

Example:
<rules>
<rule>
<state>Released,Approved,Restricted</state>
</rule>
</rules>

---

The Core Algorithm

At a high level, the algorithm looks like this:

On release of an item:

  Load all Float Rules for the released item type.

  For each relationship floating rule:

    Find relationship rows where related_id points to an older generation
    of the same config_id as the newly released item.

    Fetch:
      - the source item
      - the relationship row
      - the old referenced item
      - the newly released item

    Evaluate configured conditions.

    If valid:
      update relationship.related_id to the new released item id.

  For each property floating rule:

    Find items where the configured reference property points to an older
    generation of the same config_id.

    Fetch:
      - the referencing item
      - the old referenced item
      - the newly released item

    Evaluate configured conditions.

    If valid:
      update reference_item.reference_property to the new released item id.

  If any required update fails:
    stop and return an error.

The engine should be deterministic.

Given the same released item, rules, and data, it should make the same decision every time.

---

Example 1: A Revised Part Floats into an Assembly

Initial structure:

Assy 001/01
 ├─ 10 → Assy 002/01
 │       ├─ 10 → Part 003/01
 │       └─ 20 → Part 004/01
 └─ 20 → Part 005/01

Part 004/01 is revised:

Part 004/02 = Preliminary

At this stage, the assembly still references the old revision:

Assy 002/01
 └─ 20 → Part 004/01

This is correct. The new revision is not released yet.

Later:

Part 004/02 = Released

The engine finds references to older generations of the same config_id.

It finds:

Assy 002/01 → Part 004/01

Then it evaluates the rule:

Is the released item eligible? Yes.
Is the source assembly eligible? Yes.
Is the relationship type eligible? Yes.
Is the relationship row eligible? Yes.

Then it updates the relationship:

Assy 002/01 → Part 004/02

The structure moved forward because the revised part became released, not because the revision merely existed.

---

Example 2: A Revised Sub-Assembly Floats into a Parent Assembly

Initial structure:

Assy 001/01
 ├─ 10 → Assy 002/01
 └─ 20 → Part 005/01

The lower-level assembly is revised:

Assy 002/02 = Preliminary

The new revision may have a different internal structure:

Assy 002/02
 ├─ 10 → Part 003/01
 └─ 20 → Part 006/01

But Assy 001/01 still points to the released or controlled revision:

Assy 001/01
 └─ 10 → Assy 002/01

This is correct.

The parent assembly should not automatically consume a preliminary sub-assembly.

Later:

Assy 002/02 = Released

Now the engine can evaluate whether Assy 001/01 is allowed to move forward from:

Assy 001/01 → Assy 002/01

to:

Assy 001/01 → Assy 002/02

If the rule allows it, the parent now consumes the newly released sub-assembly revision.

If the rule does not allow it, the parent remains fixed on Assy 002/01.

Both outcomes can be correct depending on the business rule.

---

Example 3: Obsolete or Historical Structures

Now consider this case:

Part 004/01 = Obsolete
Part 004/02 = Released

Should all references to Part 004/01 move to Part 004/02?

Not necessarily.

Some references may represent live product structures. Those may need to move forward.

Other references may belong to historical baselines, released records, manufacturing snapshots, or compliance evidence. Those should often remain unchanged.

This means:

Only float references where the context item is not Obsolete,
and the newly referenced item is Released.

The important point is that Obsolete handling is not a technical constant.

It is a business policy.

---

Why This Is Not “Always Latest”

A dangerous interpretation of Float is:

Always point to the newest version.

That sounds convenient, but it can damage traceability.

Engineering, quality, manufacturing, and compliance processes often need to know exactly which revision was used at a specific point in time.

If references silently move every time a newer version appears, the structure becomes historically unreliable.

A better interpretation is:

Move forward only when the newly revised item is released
and the consuming reference is allowed to adopt it.

That protects the difference between:

latest revision

and:

latest approved revision that this structure is allowed to consume

Those are not the same thing.

---

Where Life Cycle Design Fits

This is where the earlier Life Cycle discussion becomes important.

In the Life Cycle guide, Released was described as a state that can mark an item as released, and states can also define whether the item is lockable, what permissions apply, and what item behavior applies.

That means Float on Release should not be designed separately from the life cycle.

It should respect the life cycle.

For example:

Preliminary:
  item can change
  references should usually not consume it automatically

Released:
  item is approved
  selected references may float to it

Obsolete:
  item is no longer active
  references may or may not move depending on policy

Frozen baseline:
  references should not move unless explicitly allowed

The earlier guide also notes that after release, Hard Fixed behavior may be useful when the configuration must remain frozen.

That point is critical.

Float on Release should not bypass Hard Fixed design.

If a structure is intended to be frozen, the rule engine should leave it alone.

---

Where the Engine Should Run

The natural trigger is the release event.

In Aras terms, this can be implemented around the promotion into the Released state, usually through a transition method or related release-side logic.

The design question is whether the operation should be:

in-scope

or:

out-of-scope

In the earlier Life Cycle article, transition methods were described as pre-methods and post-methods, with post-methods able to run in-scope or out-of-scope. In-scope failure can roll back the transition; out-of-scope failure does not necessarily roll it back.

For Float on Release, the decision matters.

If floating is mandatory for the release to be valid, then failure should block or roll back the release.

If floating is only a convenience, it may run asynchronously and log errors for later repair.

For controlled engineering structures, I would usually prefer this behavior:

If the rule says the reference must float,
and the update fails,
the release should return an error.

Otherwise, the system may create a dangerous half-success:

The item is Released,
but the references that should have moved forward did not move.

Final Thought

Float on Release is a small concept with large architectural consequences.

It connects versioning, lifecycle state, relationship behavior, direct reference properties, and business governance.

Native Aras Item Behavior gives the foundation: Fixed, Float, Hard Fixed, and Hard Float. Life Cycle States and RelationshipTypes already influence how versionable parent and child items behave. But real implementations often need a more specific release-driven rule:

When a revised item becomes Released,
move selected references from the old revision to the new revision.

That is what a rule-based Float on Release engine provides.

It does not mean that newly created items automatically enter structures.

It means that when an item already used in a structure is revised, the new revision can be adopted by eligible references only after it reaches the correct release state.

That is the key distinction:

Float is not about chasing the newest version.
Float on Release is about adopting the right released revision, at the right time, under the right rules.