How sets interact with the rest of a blueprint
Summarize
Summary of How Sets Interact with the Rest of a Blueprint
This document outlines how sets within a blueprint interact with other fields. It explains the relationship between set fields and non-set fields, highlighting how rules can be applied conditionally based on their context within the blueprint.
Show less
Key Features
- Field Independence: Fields within a set (e.g., setFieldA and setFieldB) do not influence fields outside of the set (e.g., field1 and field2). Conversely, fields outside the set can influence fields within the set.
- Rule Application: Rules can be created that apply to fields within a set. Each index of the set handles rules independently from one another.
- Set Aggregates: To enable sets to affect fields outside their boundaries, set aggregates (Sum, Average, Min, Max, Count) can be used, which then operate as standard fields that can influence other blueprint fields.
Key Outcomes
Understanding the interaction of sets and fields within blueprints allows for precise rule creation and management. Customers can effectively utilize set aggregates to ensure that conditions met within a set can influence broader blueprint functionalities, enhancing overall blueprint capabilities.
The implications of sets when used in blueprints.
Suppose you have a blueprint with the following fields:
- field1
- field2
- setFieldA
- setFieldB
The setFieldA and setFieldB fields are part of a set named sampleSet. The field1 and field2 fields are not part of a set, but they are in the same blueprint as sampleSet. For our case, assume that sampleSet has a size of 2. That structure would look something like this:
Because a field can have a different value for each set index, a field in the set cannot influence a field outside the set (such as field2). However, fields outside the set (such as field1) can influence fields in the set. See the diagram:
Example: Ambiguous conditions
If in sampleSet index 1, setFieldA=Video and in sampleSet index 2, setFieldA=Audio, we cannot have the following rule:
- Condition: “if setFieldA==Video
- Action: set field2 to mp4
For index1, the condition is true, and the rule fires. For index2, the condition is false, and the rule does not fire. Because field2 is outside the set, it is not clear whether the rule should fire.
However, you can write rules for fields that affect other fields in the same set. These rules are independently applied to each index. Fields in indexes cannot influence fields in other indexes.
Example: A valid rule
The following rule is valid:
- Condition: field1 == Mammals
- Action: Include the following field options on setFieldA: [“Lions”, “Tigers”, “Bears”]
The field options Lions, Tigers, and Bears are present for each index in sampleSet.
Example: Independent indexes
Suppose in sampleSet index 1, setFieldA=Video and in sampleSet index 2, setFieldA=Audio, and the following rule is set:
- Condition: If setFieldA == Video
- Action: setFieldB = true
For index1, the condtion is true, and the rule fires. For index2, the condition is false, and the rule does not fire. Therefore, setFieldB for index 1 is true, but the rule does not fire for the second index. Each index is independent of the other indexes.
A set that is isolated from the rest of the blueprint is not very useful, but there are ways that the set can affect the blueprint outside of the set. First, if a Product rule is created using fields in the set, each Index in the set uses the Product rule to affect the BOM when the conditions are met. This is beneficial because you can write a single rule that each Index of the set follows differently, depending on the field values in that index.
If we want to have set fields affect fields outside the set, we have to use the set aggregates. There are five set aggregates: Sum, Average, Min, Max and Count. Each created aggregate will have a field variable name (with special formatting). This is because the aggregate fields operate like any other field outside the set, and they can influence other fields.