The default traversal strategy ('directed') gives the required results when you depict a set of assets that are related through some kind of (data) flow or dependency. For nodes in the flow section, and the edges between them, you can paraphrase the ‘directed’ traversal strategy as "keep on walking and don't look back". But when the relation represents a link to context rather than flow, the edge between two nodes should always be traversed, even if the related node is upstream of a downstream node, or vice versa. You can also regard an edge between a flow node and a context node as bidirectional: it should always be traversed.
This notion becomes clearer when you look at the following example.
When the flow depicts transformations of table columns, the tables that contain the columns, and the business terms that are related to them, provide context to the columns. The context nodes are always relevant, regardless of whether the column was encountered while going upstream or downstream. The context nodes are always added to the diagram.
For this traversal strategy, you can assign a node in the diagram view to be a context node.
Consider the following example diagram view:
This view contains flow only.
An example diagram for this view is below:
We started from the Order amount USD asset.
Now assume that you also want to see to which tables these columns belong.
You could add a relation from column to table to the view (in other words, a downstream edge), but this relation would only be considered on the downstream side, and if we add the column/table relation in the reverse direction, it would only be considered on the upstream side. To solve this problem, we designate the Table as a context node, so that the relation from Column to Table is always traversed, both for Columns that are upstream as well as downstream.
Resulting in the diagram below:
Both upstream and downstream Columns show the Table that contains them. The edge from Column to Table was always traversed.