Survivorship Rules
The Survivorship rules (also known as survivorship strategy or OV rules) define a way to govern which attribute values must be identified as the OV.
Survivorship is important to defining the golden record (final state) of any object that your business considers important. This article explains the survivorship rules for defining the operational values of your object types.
Identifying Operational Values (OV) for Attributes
When an entity or relationship is the result of previous merges, it contains the aggregation of attributes and attribute values from the contributing objects. As a result, any attribute, whether it be a simple, nested, or reference, may contain multiple values. For example, after merging with two other entities, the first name attribute of an entity could contain three values: 'Mike', 'Mikey', and 'Michael'.
Through Advanced Search, you can use the has all option to search for Source System Names for which to add values to attributes for the crosswalk. From the values you specify, the system will choose the best value from these recent values. Furthermore, although multiple values are shown, you have the option to select the configuration to use to not calculate survivorship based on all of the system sources but to calculate survivorship only on certain sources. All rules work on the entire set of crosswalks that exist for the record.
If you do not want all of the survivorships to be calculated based on all of the records or all of the crosswalks that exist on any records, then you need to set Survivorship Rules from the Sources View of any entity. For more information, see Configuring Survivorship in the Hub.
While it is important to store all the contributing values in the attribute for audit purposes, ultimately, the 'best value' or set of values for the attribute must be determined so that they can be returned to Hub users and calling applications in a request. These 'best values' are called the Operational Values, or winner values, and referred to as the OV of the attribute.
In the Hub, the OV is primarily shown next to the attribute label. The Hub provides an indicator if additional, yet non-OV values exist. The indicator is a blue oval with a + and a number in it. The number indicates how many additional unique values are held within the attribute. Clicking on the oval will navigate the user to the Sources view, where all source crosswalks and all contributed values can be seen for each attribute.
Each attribute can have 0, 1, or multiple values that have been marked as OV. The OV flag is a boolean property used by the Hub to determine which attribute values must be shown to the user. The OV flag of each attribute value is calculated just-in-time whenever the entity's values are requested by either the Hub or a calling application.
Survivorship strategy is configurable for each entity type. Survivorship strategy can be changed on the fly and will take effect immediately. This ensures that you have the agility to change the rules for calculating the OV flags at any time, and the new definition will affect the very next payload returned from the database. Survivorship rules can be configured via the Hub or via the Configuration API.
Survivorship rules can be set for simple, nested, sub-nested, and referenced
attributes. However, survivorship rules cannot be set for sub attributes of
referenced attributes because survivorship rules for sub attributes are taken from
the referenced entity/relation and can't be overridden on the sub attribute level.
For example, if an address attribute has sub attributes such as
AddressLine1
, AddressLine2
, and
City
, the survivorship rules for these sub attributes will be
determined by the survivorship rules that are set for the Location
entity. However, sub attributes can be used as a link in additional fields of
strategy (primaryAttributeUri
,
comparisonAttributeUri
).
Supported survivorship strategies are described in the following table:
Strategy Name | Description |
---|---|
LUD |
Last Update Date. Attributes that were recently updated (with the
maximum number of update dates) will have highest priority to be
marked as OV. LUD is the default survivorship
strategy.The winner value is calculated in this order:
Note: The following apply:
|
SRC_SYS |
Source System. The user provides a priority list of sources. A
list of priority is defined for a mapping, if it’s absent, it is
taken from the priority list of the group. All crosswalks from a
source system with the highest priority become winners, all values
of those crosswalks also become winners. The following points apply:
|
Frequency |
Calculate amounts of crosswalks from which values were provided. Values with the most amount of crosswalks become winners. Note: If more than one value is the winner, the
LUD
strategy is used to find final winners. |
Aggregation |
All presented values become winners (ov =
True). |
Record-values based source priority |
All values from the winner source type become winners. The survivorship strategy is configured with two parameters:
If there is any value from the attributes considered that has a crosswalk with winner source type, then only crosswalks with this source type become winners, and their values become OV. If there is no such value, the |
Custom survivorship strategy name Example:
|
The custom survivorship strategy is configured with two
parameters:
All crosswalks from the winner source type become winners, and all values from those crosswalks also become winners. Note: If several or no crosswalks win, the parent strategy is
applied to determine the winner.
|
OldestValue |
Finds a crosswalk with the oldest create date. All values that were provided by this crosswalk become winners. Note: If there are many crosswalks with the same create date, only
the first crosswalk becomes a winner.
|
MinValue |
The smallest value becomes the winner. All crosswalks of those values become winners. Calculation of minimum value is based on attribute type:
Note:
|
MaxValue |
Values with the highest value become winners. All crosswalks of those values become winners. Calculation of maximum value is based on attribute type:
Note:
|
OtherAttributeWinnerCrosswalk |
The strategy has the required attribute
Every separate survivorship rule produces winner values and
winner crosswalks as a result of calculation. Winner crosswalks
from the OV calculation's result can be used only in
If the primary attribute doesn't have winner crosswalks, then the dependent attribute also doesn't have winner (OV) values. It is possible to have a primary attribute which also has
survivorship mapping using
Note: There is a restriction for
primaryAttributeUri . It can be on the same
level as the dependent (current) attribute or it can be on a
higher level, as indicated here:
Otherwise, the strategy will not work in a predictable manner. |
WinnerEntityCrosswalk |
The entity value of the current winning entity becomes the winner. All crosswalks from the winner entity also become winners. If the winner entity is explicitly specified in the
|
enableSeparateIndexing
flag,
see Reindex Data Task.Survivorship rules are defined for object attributes by survivorship mappings. All
rules are defined separately for each attribute and are calculated independently of
each other (the only exception is the OtherAtrributeWinnerCrosswalk
strategy which depends on a primary attribute). A survivorship group consolidates a
set of survivorship mapping.
An entity type can have multiple survivorship groups, and one of them must be marked as default. A default group is used in most cases; otherwise, non-default groups are applied for users with specific roles only. Roles are also defined in a group setting. However, if two users are assigned different roles with each role having a different set of survivorship rules, then the OV values displayed to these users may be different, depending on the rules applied. Survivorship groups can be associated with user roles by using the Rulesets.
If some attribute isn’t specified in NOT default mapping, the mapping for this attribute is taken from the default group.
All survivorship rules are defined in a business configuration for object types.
It's impossible to specify survivorship rules for referenced attributes. The OV values of referenced attributes are calculated by rules of a corresponding relation or a referenced entity which also has its own attributes survivorship mappings.
Survivorship Mapping Parameters
Survivorship mapping parameters are provided in the following table.
Parameter | Description |
---|---|
attribute |
Required. Current attribute URI. |
survivorshipStrategy |
Required. survivorshipStrategy name. |
sourcesForOv |
Optional. List of sources which may be OV. The sources which aren't included in this list will be ignored. |
comparisonAttributeUri |
Optional. URI of simple attribute. Child of nested attribute.
Used for comparison in MinValue ,
MaxValue , and Frequency
strategies only. |
fallbackStrategies |
Optional. List of survivorship mappings. See Fallback Strategiesfor details. |
fallbackUsingCriteria |
Optional. Two options are allowed: MORE_THAN_ONE
(default) and ZERO_OR_MORE_THAN_ONE . |
primaryAttributeUri |
URI of primary attribute. Used only in the
OtherAtrributeWinnerCrosswalk strategy. |
sourcesUriOrder |
Ordered list of sources. Used only in the
SRC_SYS strategy. |
filter |
Filtering criteria. See Filtering for details. |
sortAs |
This parameter is supported only for MinValue /
MaxValue strategies.Contains the type of object that value of string attribute will be cast to - integer, double, boolean, and so on. The default value is the type of the attribute. Allowed values for parameter:
|
SortAs
Some customers
store values of integer, double, boolean and other types in fields that have type
String
in business configuration. Default implementation of
Min
/Max
OV strategies in such cases provides
only comparison of these values with lexicographical
order. To
provide the ability to compare these values for OV calculation with cast to target
types the existing behavior of Min
/Max
calculation
strategy was extended by additional parameter
sortAs
.
Configuration
Example of new Survivorship Group Configuration:
{
"attribute": "configuration/entityTypes/HCP/attributes/ID",
"sortAs": "Int",
"survivorshipStrategy": "MinValue"
}
Examples
Let's consider an attribute ID
that has type as String and two
values with survivorshipStrategy
and MaxValue
.
Examples of configuration | |||
---|---|---|---|
sortAs\OV for MaxValue |
112 | 21 | Explanation |
null (absent) | false | true | values are sorted in lexicographical order,
21 is maximum value |
int | true | false | values are compared as integers, 112 is
maximum value |
sortAs\OV for MaxValue |
112 | 21 | Explanation |
---|---|---|---|
null (absent) | false | true | values are sorted in lexicographical order,
21 is maximum value |
int | true | false | values are compared as integers, 112 is
maximum value |
sortAs\OV for MaxValue |
11.2 | 2.1 | Explanation |
null (absent) | false | true | values are sorted in lexicographical order,
2.1 is maximum value |
float | true | false | values are compared as integers, 11.2 is
maximum value |
int | true | false | values can not be parsed as integers because of
‘.’ in the values. So these values will be
compared as Strings. |
Metadata validation
- 1812
- 1813
For more information, see the table with validation error codes at https://docs.reltio.com/infoandconfig/validationerrors.html.
Common Rules
Survivorship calculation rules include:
- Survivorship strategy: Applies specific rules to determine winner values.
- Filterings settings: Splits all attribute values by defined criteria. Each split set of values has its own winner values, and all calculations are performed independently between split sets.
- Fallback strategy settings: Indicates what strategy must be used to determine the winner if a main survivorship strategy couldn’t determine them or found a lot of them.
- Restrictions of sources for OV: Set by the
sourcesForOv
field. If these restrictions exist, only crosswalks (and values linked to them) from permitted source-systems are used to determine winners, all other crosswalks and values are ignored. So if there are no values from permitted sources, there are no winner values. - Pinned value: Survivorship rules are not applied to attribute values if one of
those values is pinned. All pinned values become OV’s and all attribute’s
survivorship rules are just ignored. Note: If sub-nested attribute is pinned but its parent has OV set as false this sub-nested attribute also will have the OV set as false.
- Ignored value: Ignored values do not participate in OV calculation.
- Crosswalks with end date (delete date): Do not participate in OV calculation just as those crosswalks do not exist.
- Default strategy: If an attribute does not have its own survivorship mapping,
the default survivorship Last Update Date (
LUD
) is applied.
If all crosswalks of value were filtered out because they are end-dated or they
aren’t from sourcesForOv
, such value is ignored and does not
participate in OV calculation.
Filtering
Filtering settings split all values from an attribute to different sets of values using a filter. These sets of values can intersect with each other if the value meets the filter condition for different filters. For each set, the winner values are calculated separately. Each filter condition is specified in separate attribute mappings. If a value is contained in multiple subsets, it can be a winner value in one of the subsets.
If a value does not match any filter condition in the attribute mappings, it goes to
the set which will be calculated by default strategy and also separately from other
sets. Separate mapping without filtering property must be specified for this
strategy; otherwise, LUD
is applied.
Filtering only supports the equals
expression. For the specified
value, all values of the attribute where the operational values are set to true or
false are searched.
A URI for matching any attribute can be used, for example:
- A value from a neighbor attribute on the same level (
FirstName
->LastName
,Identifiers
/ID
->Identifiers
/Type
). - Not a neighbor value from anywhere
(
Identifiers
/ID
->Address
/AddressLine1
) This makes sense only for different entities: OV forIdentifiers
/ID
from one entity with one address will be calculated with one rule, but for another entity with other address it will be calculated with another rule.
If multiple values exist on URI, one required value is enough for the filtering match.
Fallback Strategies
Fallback strategy options are determined by the
fallbackUsingCriteria
and fallbackStrategies
properties on a survivorship mapping.
There are two fallbacks using the criteria:
MORE_THAN_ONE
(default): If a strategy returns two or more winner values, its fallback strategy will use only the winner values and winner crosswalks from the strategy.ZERO_OR_MORE_THAN_ONE
: If a strategy returns zero, two, or more winner values, the logic for determining values used by the fallback strategy is based on the retrieved number of winners.If there are zero winners, then all values from the strategy are considered by its fallback strategy. If there are two or more winners, then only winner values and winner crosswalks from the strategy are considered by its fallback strategy.
Example JSON for Fallback Strategies
{
"sourcesUriOrder":[
"configuration/sources/TWITTER",
"configuration/sources/FB"
],
"mapping":[
{
"attribute":"configuration/entityTypes/Individual/attributes/FirstName",
"survivorshipStrategy":"SRC_SYS",
//step 1: Check the main strategy. According to the ZERO_OR_MORE_THAN_ONE fallback criteria,
//If there are zero or more than one winners, then all the values (if zero values won) or only the winner values (if there is more than one winner) are passed to the fallback section.
"fallbackUsingCriteria":"ZERO_OR_MORE_THAN_ONE",
"fallbackStrategies":[
{
"attribute":"configuration/entityTypes/Individual/attributes/FirstName",
"survivorshipStrategy":"LUD",
//step 2: The strategy used depends on the number of winners from the previous step. If the LUD strategy returns more than one winner, the next fallback strategy will take part in the Operational Value (OV) calculation.
"fallbackUsingCriteria": "MORE_THAN_ONE",
"fallbackStrategies": [
{
"attribute": "configuration/entityTypes/Individual/attributes/FirstName",
"survivorshipStrategy": "MinValue" //this step is required only if the LUD strategy returns more than one winner value (in accordance with the MORE_THAN_ONE fallback criteria).
...
}
]
}
]
}
]
}
sourcesForOv
parameter always narrows the
set of allowed sources in fallback strategy mapping, if parent mapping has the
parameter options as sourcesForOv
= ['src1', 'src2',
'src3']
, then the fallback's mapping must be a subset of parent
mapping; for example, ['src1', 'src3']
; otherwise, fallback will
not consider any operational value.filter
parameter) is not
applicable and is not supported in fallback strategy mapping.Example
Consider the following mapping:
- Main strategy:
OtherAttributeWinnerCrosswalk
. - Fallback strategies chain:
Record-Values Based Source Priority
with winner source type A.Record-Values Based Source Priority
with winner source type B.MaxValue
.
Then, you can start calculating winners step by step.
- Apply
Other Attribute Winner Crosswalk
. It returns five winners.- If the fallback using criteria is
MORE_THAN_ONE
, take five winners and filter their crosswalks to use only winner crosswalks. Then, use them in the next step. - The same thing for
ZERO_OR_MORE_THAN_ONE
criteria.
- If the fallback using criteria is
- Apply
Record-Values Based Source Priority
(source A). It returns 0 (zero) winners.- If the fallback using criteria is
MORE_THAN_ONE
, stop the calculation. The result will be 0 (zero) winners. - If the fallback using criteria is
ZERO_OR_MORE_THAN_ONE
, take the previous five winners with their winner crosswalks, and use them in the next step.
- If the fallback using criteria is
- For
ZERO_OR_MORE_THAN_ONE
only, apply the secondRecord-Values Based Source Priority
. Consider the different results:- If it returns 0 (zero) winners, take and use the 5 previous winners again in the next step.
- If it returns one winner, mark it as the final winner and stop the calculation.
- If it returns two or more winners, take them (only them) and use in the next step.
- For
ZERO_OR_MORE_THAN_ONE
only, apply Max Value. As this is the last strategy in the chain, no matter what the result is, it will be used as the final result (with 0 (zero) or one or more winners) anyway.
Strategy Examples
Example of custom survivorship strategy definition in tenant's configuration
"survivorshipStrategies": [
{
"uri": "configuration/survivorshipStrategies/TwitterSRCSysStrategy",
"parentStrategyURI": "configuration/survivorshipStrategies/SRC_SYS",
"label": "Twitter Custom SRC_SYS Strategy",
"mainSourceType": "configuration/sources/TWITTER"
}
]
survivorshipStrategies
parameter must be placed at the same
level as the entityTypes
parameter in the configuration.Example of record-values based source strategy definition in tenant's configuration
"survivorshipStrategies": [
{
"uri": "configuration/survivorshipStrategies/CleanserWinsStrategy",
"label": "Record values based source priority OV rule (based on ReltioCleanser)",
"winnerSourceType": "configuration/sources/ReltioCleanser",
"winnerSourceAttributes": [
"configuration/entityTypes/Location/attributes/AddressLine1"
]
}
]
Example of attribute mapping with OtherAttributeWinnerCrosswalk
strategy
{
"attribute": "configuration/entityTypes/HCP/attributes/LastName",
"survivorshipStrategy": "OtherAttributeWinnerCrosswalk",
"primaryAttributeUri": "configuration/entityTypes/HCP/attributes/FirstName"
}
Survivorship Groups (Changing Default Survivorship Strategy)
The section survivorshipGroups
could be added to every type in the
configuration. Each survivorship group has a mapping of attribute URIs to
survivorship strategies. One group for a type could be set as default from the API.
That would mean that if the survivorship strategy of a particular attribute type is
defined in the survivorship group, which is default for the type and attribute, a
value would be selected in accordance with the survivorship group. For example, a
type could have a survivorship group, as follows:
{
"default" : true,
"mapping" : [
{
"attribute" : "configuration/entityTypes/Reltio.System.Individual/attributes/MiddleName",
"survivorshipStrategy" : "LUD"
}
]
}
Add a new Survivorship Group
The request creates a survivorship group in configuration type.
POST {TenantURL}/configuration/entityTypes/{entityTypeName}/survivorshipGroups
{
"default" : true,
"mapping" : [
{
"attribute" : "configuration/entityTypes/Reltio.System.Individual/attributes/MiddleName",
"survivorshipStrategy" : "LUD"
}
]
}
In the above example, the new survivorship group would be created that overrides
survivorship strategy of the MiddleName
attribute to
LUD
, and the group would be considered as the default.
POST {TenantURL}/configuration/entityTypes/{entityTypeName}/survivorshipGroups
{
"sourcesUriOrder": [
"configuration/sources/TWITTER",
"configuration/sources/FB"
],
"mapping": [
{
"attribute": "configuration/entityTypes/Individual/attributes/FirstName",
"survivorshipStrategy": "SRC_SYS",
"fallbackStrategies": [
{
"attribute": "configuration/entityTypes/Individual/attributes/FirstName",
"survivorshipStrategy": "MinValue"
},
{
"attribute": "configuration/entityTypes/Individual/attributes/FirstName",
"survivorshipStrategy": "LUD"
}
]
}
],
"default": "true"
}
In this example, the new survivorship group would be created that overrides
survivorship strategy of the FirstName
attribute to
SRC_SYS
and sourceUriOrder
for the group. The
Fallback strategies section means that in case of multiple OV values for this
attribute, the system will try to re-calculate OV (among values already marked as
OV) in order to get the only one.
Update the Survivorship Group
This request updates the present survivorship group in configuration type.
PUT {TenantURL}/configuration/entityTypes/{entityTypeName}/survivorshipGroups/{groupShortUri}
{
"default" : false,
"mapping" : [
{
"attribute" : "configuration/entityTypes/Reltio.System.Individual/attributes/MiddleName",
"survivorshipStrategy" : "LUD"
}
]
}
In the above example, survivorship group uri {groupShortUri}
would
be updated, which overrides survivorship strategy of the MiddleName
attribute to LUD
; therefore, group would not be considered as
default.
PUT {TenantURL}/configuration/entityTypes/{entityTypeName}/survivorshipGroups/{groupShortUri}
{
"sourcesUriOrder": [
"configuration/sources/TWITTER",
"configuration/sources/FB"
],
"mapping": [
{
"attribute": "configuration/entityTypes/Individual/attributes/FirstName",
"survivorshipStrategy": "SRC_SYS",
"sourcesUriOrder": [
"configuration/sources/FB",
"configuration/sources/TWITTER"
]
}
],
"default": "true"
}
In this example, survivorship group uri {groupShortUri}
would be
updated, which overrides survivorship strategy of the FirstName
attribute to SRC_SYS
and sets sourceUriOrder
for
the group.
This request allows you to change both the information about a survivorship group and a strategy for the specified attribute. Unlike the group information that is replaced with the attributes from the request, there is no need to specify all the strategies from the mapping section. Only mappings that are set in the request will be updated in the metadata configuration.
When the strategy in the request requires some extra attributes (for example,
OtherAttributeWinnerCrosswalk
requires
primaryAttributeUri
), they are initially searched in the
metadata configuration. If these attributes are found, their values are taken from
the configuration. If there are no such values, validation error occurs.
The SRC_SYS strategy uses the sourceUriOrder
attribute, that
can be located on a group/strategy/group and strategy levels, so there are some
features referring to updating this attribute. If sourceUriOrder
is
set on the strategy level in L3, but is absent on the same level in the request, it
is taken from L3. If sourceUriOrder
is set on the group level in
L3, but is absent on the same level in the request, it is removed from the
configuration.
Filters in Survivorship Group Mapping
With the Complex OV rule type, you can define survivorship strategy for a nested
attribute based conditionally on values of a sub-attribute. This is accomplished
using the optional filter
property for survivorship group mapping.
Therefore, a survivorship strategy, which is defined in the
survivorshipStrategy
property of the mapping, will be applied
only for attributes which match the filter criteria. In this way, several
survivorship strategies can be leveraged to treat different sub-attribute types. The
resulting winners for the nested attribute are the aggregation of winners emerging
from each strategy.
Examples
Example 1 The developer states that for all identifiers, where the
Identifier.type
= NPI
, the survivorship
strategy must be MinValue
. However, for all identifiers where the
Identifier.type
= ME
, the survivorship
strategy must be OldestValue
. Lastly, use the default
LUD
strategy for all other types.
{
"default": true,
"mapping": [
{
"attribute": "configuration/entityTypes/HCP/attributes/Identifiers/attributes/ID",
"survivorshipStrategy": "MinValue",
"filter": {
"equals": [
{
"uri": "configuration/entityTypes/HCP/attributes/Identifiers/attributes/Type",
"value": "NPI"
}
]
}
},
{
"attribute": "configuration/entityTypes/HCP/attributes/Identifiers/attributes/ID",
"survivorshipStrategy": "OldestValue",
"filter": {
"equals": [
{
"uri": "configuration/entityTypes/HCP/attributes/Identifiers/attributes/Type",
"value": "ME"
}
]
}
}
]
}
Example 2 For Identifiers of type ME, there must be one OV with
MinValue
of ID
. For identifiers of type NPI,
select the OldestValue
. For all others, use
SRC_SYS
.
{
"default": true,
"mapping": [
{
"attribute": "configuration/entityTypes/HCP/attributes/Identifiers",
"survivorshipStrategy": "MinValue",
"comparisonAttributeUri": "configuration/entityTypes/HCP/attributes/Identifiers/attributes/ID",
"filter": {
"equals": [
{
"uri": "configuration/entityTypes/HCP/attributes/Identifiers/attributes/Type",
"value": "ME"
}
]
}
},
{
"attribute": "configuration/entityTypes/HCP/attributes/Identifiers",
"survivorshipStrategy": "OldestValue",
"filter": {
"equals": [
{
"uri": "configuration/entityTypes/HCP/attributes/Identifiers/attributes/Type",
"value": "NPI"
}
]
}
},
{
"attribute": "configuration/entityTypes/HCP/attributes/Identifiers",
"survivorshipStrategy": "SRC_SYS"
}
]
}
Example 3
OldestValue
survivorship strategy for the FirstName
attribute for all HCPs from NY
or TX
states and
Aggregation
for all others.
{
"default": true,
"mapping": [
{
"attribute": "configuration/entityTypes/HCP/attributes/FirstName",
"survivorshipStrategy": "OldestValue",
"filter": {
"equals": [
{
"uri": "configuration/entityTypes/HCP/attributes/Address/attributes/State",
"value": "NY"
}
]
}
},
{
"attribute": "configuration/entityTypes/HCP/attributes/FirstName",
"survivorshipStrategy": "OldestValue",
"filter": {
"equals": [
{
"uri": "configuration/entityTypes/HCP/attributes/Address/attributes/State",
"value": "TX"
}
]
}
},
{
"attribute": "configuration/entityTypes/HCP/attributes/FirstName",
"survivorshipStrategy": "Aggregation"
}
]
}
Example of the OV Calculation of a Winner Entity
- Entity 1: This entity includes the
FirstName
attribute value ofFirstName1
and thecrosswalk
attribute value ofCrosswalk1
- Entity 2: This entity includes the
FirstName
attribute value ofFirstName2
and thecrosswalk
attribute value ofCrosswalk2
- Entity 3: This entity includes the
FirstName
attribute value ofFirstName3
and thecrosswalk
attribute value ofCrosswalk3
FirstName
attribute
value of FirstName1
. The operational value is set to
true
and the FirstName2
operational value is
set to false
. If Entity 21 and Entity 3 are merged with the specified winner as Entity 3, then the
merged entity will have the FirstName
attribute value of
FirstName3
. The operational value is set to
true
and the FirstName1
and
FirstName2
operational values are set to
false
.