I am unable to perform simple actions across tables where computed keys are in use. I have isolated this part of my process to make testing easier. The action is looking to update a column in the returned record, so there should be no issues of the action trying to add a duplicate key. In the case of the LOOKUP event, it passes a blank key value when a composite key is used.
Error when using an ADD process input:
Error when using a LOOKUP process input:
“The record will be retrieved using the primary key. Any additional columns will be used to update the record”. - Okay, but it won’t let me select the composite column as an input…
If I remove the composite key, then everything works fine. This wouldn’t be a long-term option in my use case…
FWIW: the workaround for now was to make the virtual _ComputedKey column a physical column…
Everything works now.
Composite keys aren’t supported for lookup currently. We will update the documentation to make it clear.
Add varb is also not supporting computed_key as well?
Not sure I understand your point, computed_keys are computed, how would you enter those?
You said when we pick up look up as process input then computed key is not able to use to select a single row. So I simply ask led what is going to happen to the ADD as process input
Updated the help article. Can you please take a look and let me know if the example clarifies the answer to your question?
Update is given to clarify to “Computed_Key” is not be used for process input? or something like that? but i could not locate the word of computed_key in this document.
So not sure what was updated actually.
Fixed.
Based on this latest doc, I understand only non-computed key is supported for LOOKUP, but non-computed_key IS supported for ADD, am I correct?
User | Count |
---|---|
17 | |
9 | |
6 | |
5 | |
5 |