Overall, we find the "smart table search" functionality to be very useful. That said, we have been running into issues with the stated limitations:
"Multi-select elements in your look-up tables will cause the search to fail."
We are using multi-select elements with increasing frequency. Would really like to see these supported, if only in a concatenated list. Correctly designed multi-select elements enable us to build very fast, dynamic forms.
"Text Area Elements that have a 'return' in the data will cause the search to fail."
This one is a huge problem for us, as we tend to use text area fields to show users summary or aggregate data that are best separated by hard returns. Additionally, users often need to be able to have more than one paragraph; long text blocks are, after all what users expect to be able to use the Text Area element for.
"Records used for "look-up" data should be not used for any other purpose (assignment, subform records)"
I would argue that what makes smart tables so powerful is that they can be used to access information entered on previous related forms, as long as there is strict programmatic control over the key value being used to ensure uniqueness (e.g., site number, phone number, tag number, UPC). For example, I have teams of biologists and technicians injecting unique RFID tags into baby fish, collecting biological information, lengths and weights, then releasing them. I then have these and other teams re-encountering the same tagged fish at some point in the future, using a recapture form. They should be able to use the original subform as the smart table behind the recapture form to show them the original release information. This is only one specific example; we have many more, as I'm sure other customers do. Please revisit this as a viable and very powerful use case.
Please sign in to leave a comment.