@Levent_KULACOGLU @Cyril_Khamsi
This is in response to Levent’s post. It attempts to explain the problem and what I am doing about it. It is a little complicated so bear with me.
Workflows and Reports can include Attachment and Body templates that display multiple levels of embedded tables. When we are processing such templates we need to construct a “binding context” for each level of embedded table. The “binding context” is what we use to resolve references to the fields of the table within the template.
Consider a three table hierarchy with the table names GrandParent, Parent, and Child. Then consider a workflow template that displays these three tables with GrandParent at the outer level, and Parent embedded under GrandParent, and Child embedded under Parent.
When we processing the Child table embedded template we need to have a three level “binding context” with Child pointing to Parent pointing to GrandParent like this:
GrandParent “binding context”
^ Parent “binding context”
^ Child “binding context”
Recently a customer reported that a field in a workflow template was not being handled correctly. I investigate the problem and discovered that I was not “linking up” the “binding contexts” correctly. The Child “binding context” did not point to the Parent “binding context” and the Parent “binding context” did not point to the GrandParent “Binding context”.
When I fixed that problem, it uncovered a problem in how [_THISROW] is handled within workflow and report templates.
Within expressions [_THISROW] refers to the table that is at the root of the “binding context” hierarchy.
Since the workflow rules were not constructing the “binding context” hierarchy correctly, [_THISROW] was going up one level in the hierarchy rather than to the root of the hierarchy. When I fixed the binding hierarchy problem, that affected how [_THISROW] worked.
This introduced a real dilemma about how to best fix this problem. After a long discussion, it seemed like the best solution was to make use of the new [_THISROW] feature.
We had recently enhanced [_THISROW] to make it much more powerful, but we had not yet announced this new feature.
Here is the enhanced
[_THISROW] syntax:
[_THISROW]
=> Goes up to the top level. This was the only option we offered before this new enhancement. [_THISROW-1] => Goes up one level. [_THISROW-2] => Goes up two levels. [_THISROW-3] => Goes up three levels. [_THISROW-n] => Goes up n levels.
Note that you must write exactly “[_THISROW-n]”. There cannot be any embedded white spaces in the string. The number must be a constant. In other words, the value “n” is a constant number value. It can never be an expression.
This feature is really powerful because you can use [_THISROW-n] in embedded workflow templates to retrieve field values from parent, grandparent, great-grandparent, etc. records. It eliminates the need to add virtual columns that replicate field values in child records when you have a multilevel embedded workflow templates.
I am hoping that relatively few customers are going to be adversely affected by this change. I am trying to work closely with those customers who are affected to help them through the problem. I am sorry I could not think of a better alternative.
LinkedIn
Twitter
