Property relations allow administrators to control which options appear in dropdown fields based on other selections, helping users avoid irrelevant or invalid choices.

Why use property relations?

By default, code-type properties (dropdown lists) display global content, the same list of options for all units, departments, or project types. This often results in irrelevant or incorrect options being shown to users.

Property relations solve this by filtering dropdown options dynamically based on other selected property values (also known as cascading dropdowns). This ensures that users only see valid choices based on their current selections, improving data accuracy and reducing confusion.

Examples:

• If the Business unit is Logistics, then only relevant Investment categories like Fleet or Warehousing should be shown, not Production equipment.

• If the Project type is Maintenance, then Justification types should exclude options like Capacity expansion.

• If the Country is Germany, then only relevant Cost centers tied to German operations should be available.

• If the Capex type is Sustaining, then Funding source options might exclude Strategic initiatives.

• If the Production unit is Mill A, only routes and sub-units within Mill A should appear.

These filters help standardize data entry, prevent invalid combinations, and reduce the time users spend navigating long dropdowns.

How it works for users

Users encounter filtered dropdowns in the following areas:

• Capex request forms – during both creation and editing

• Expenditure grid – when creating or editing expenditure entries

Behavior overview:

• If no related property is selected, all options will be displayed.

• Once a related (head) property is selected, the tail property will only show the values allowed by the defined relation.

• When relation rules reduce valid options for a property to a single value, the system will automatically select that value, overriding any default if present.

Handling invalid values:

• If a value becomes invalid due to a change in property relations (e.g., an admin update), the field will be marked as invalid.

• Users must manually correct the invalid value before submitting the form.

• If the form is read-only, the invalid value will remain visible but cannot be changed.

⚠️ Weissr never removes or modifies invalid values automatically — it’s up to the user to update them as needed.

Understanding property relations

Scope of relations

• Property relations can be set from request properties to other request properties.

• Property relations can be set from expenditure properties to other expenditure properties.

• Cross-type relations (e.g., request → expenditure) are not supported.

Understanding "head" and "tail" in property relations

Each property relation is defined by a head and a tail:

• The head is the controlling property — the one that determines which options are shown in another property.

• The tail is the dependent property — the one whose available options are filtered based on the head’s value.

Example:

If Business unit is the head, and Investment category is the tail:

If Business unit is Logistics → Investment category is Fleet or Warehousing

You can create relation chains, where the tail of one relation becomes the head of another:

• Funding type → Project type

• Project type → Justification type

• Justification type → Approval route

Example chain:

1. If Funding type is Capex → Project type is New investment or Sustaining capital

2. If Project type is New investment → Justification type is Strategic initiative or Compliance

3. If Justification type is Strategic initiative → Approval route is Executive review

⚠️ A property used as a tail in one relation cannot also be used as a head within the same chain, which prevents circular dependencies.

Supported property types

You can only create property relations between certain types of properties. The types you can use depend on whether the property is acting as a head (the controlling field) or a tail (the filtered field).

Supported as head (controlling property):

These property types can be used in property relations (to filter other properties):

• Boolean

• Code, Currency, Country, Node, Route (any property that displays dropdown options)

• Date (works when resolution is set to Year, Month and Day)

• Decimal

• Integer

• Money

Supported as tail (filtered property):

These property types can be filtered by a head property, and must be editable dropdown fields:

• Code

• Node (e.g. Production unit)

• Currency

• Country

• Model

• User

💡 Only dropdown-type properties can be used as tails, as they have a fixed set of selectable values that can be filtered.

Unsupported property types

• Current step

• Fiscal year

• Project state

• Project state category

• Status in approved budget

📌 Note: Property relations for expenditure properties currently do not support using Money or Boolean fields as head properties.

How to configure property relations

Navigation
Go to Administration → Capex Management → Properties → Request relations / Expenditure relations

Creating a relation

1. Select the head property (left side)
   This is the controlling property — the one whose value determines what options appear in another field.

2. Set the condition (middle section)
   Define the specific value(s) that must be selected in the head property for the filtering to take effect. Available conditions depend on the data type of the head property

3. Select the tail property (right side)
   This property will be filtered based on the conditions selected for the head property.

4. Define value mappings
   For each selected value in the head property, choose the allowed values in the tail property.

Logic example:
If Business Area is Manufacturing, then Approval Route must be one of: Standard, Major Projects

Or more generally:

If [Head Property] is [Value], then [Tail Property] must be one of: [Value1], [Value2], ...

5. Click Save to apply the relation

Removing relations

You can remove specific relation entries or entire property mappings:

• To remove individual mappings:
  Uncheck codificator values in the right panel.

• To remove entire properties or value groups:
  Use the ❌ icon next to a property or codificator to clear all associated mappings.

Behavior in requests after saving relations

• Existing requests: If a relation update makes current values invalid, those values are not cleared automatically

• Editable fields: Users will see a warning and must correct the value before saving

• Read-only forms: The invalid value will remain visible, but cannot be edited