One of the code modernizations that we like is converting Look-ups to Auto-Enters.
There seem to be a number of advantages to this and (other than repeating fields) no disadvantages.
Side note: Supertrim is a custom function (that I should lower case).
This infoG is a bit rough around the edges...but still useful as is and perhaps to spark some additional thoughts.
Happy Monday.
You mean converting a lookup script step into an auto enter by lookup?
We like to convert LUs (a feature on the field definitions level...as shown above) to AEs (also on the field def level...as shown above)
In some cases we replace AEs with Scripted set field flows using pick list...a topic to itself.
I got a new solution where the customer wants reporting based on a 14-days intervall, beginning on a date in the middle of a month, not on the first day of the interval...
How do we get the date of that intervall (first day of each 14-days interval)? Well... create a table with records for those 'milestones' - then do a lookup with the current date (or each other date) with the option to fill in the next lower value if there us no match. Easy...
We have moved to not using schema-level calculations as much as possible. If we convert something, we pull it into our transaction model, and handle everything in a script.
The idea being: If a change is significant enough to trigger other data changes, it should be handled transactionally and be logged. Using an approach similar to Geist Interactive's Karbon, it is usually a fairly easy change to make, and all data manipulation is moved to a single space where it is logged and transaction safe.
