Token replacement logicSWEAGLE supports the usage of tokens in CDI values. Tokens are referenced keyNames between a tenant-specific prefix and postfix. The default pre and post fix characters are @@. In this example, the value for dbConnectionString will be fully resolved at the time of export by replacing the tokens with the values. keyName reference As a best practice and to keep things simple, we recommend that within a config data set the keyName in the token should appear only once. It doesn't matter "where" the keyName is defined as it can be at the same node, at one of the childNodes to this node or even in sibling or included nodes. If the referenced keyName exists "somewhere" in the config data set it will be used and replaced. What happens if there are multiple occurrences of the referenced tokenKeyName in the dataset? There are multiple scenarios possible and we recommend trying keeping the logic simple by creating smaller config data sets such that token replacement logic is transparent. 1. Along the hierarchy in case the keyName exists multiple times, SWEAGLE will apply a "top-down" logic and use the first value it finds while traveling from the top of the tree to the bottom. Once the referenced keyName is found the replacement thread is finished. 2. Across multiple sibling nodes in case the keyName exists multiple times at sibling levels, SWEAGLE loops through all of them and takes the value for the last occurrence found. So the token with the value at a node with the name "Znode" instead of the node "MyNode". The replacement is stopped In case the keyName was found at sibling level, if not SWEAGLE will continue on the next level along the hierarchy. 3. Direct child nodes and include nodes In case the keyName exists in both direct child nodes and included nodes, SWEAGLE will first loop through the direct child nodes. If the keyName is found the replacement is stopped. If not, it will apply the same logic for all the included nodes. If found in the included nodes the replacement is stopped. If not, it will move on to the next level along the hierarchy. In other words, the "included nodes" (the red box in the picture) are considered "lower" in the hierarchy tree compared to the direct child nodes (blue box in the picture) This means that the referenced keyName in the token will be replaced with the value at the "highest" parent level in case the keyName is found there (= higher in the tree)at sibling level in "reverse alphabetic" order if the keyName is found thereat the include level in "reverse alphabetic" order in case node(s) are included below the node where the token keyName is referencedat the child level(s) of each of the siblings, again in alphabetic order Should you have a use case for any other logic, reach out to us at the support forum. What happens if the referenced keyName in the token cannot be found? There is a base validation policy that will check if all tokens can be replaced with values for every config data set. Should a referenced keyName not be found in the scope of the config data set then an "unidentified token" error will be triggered.