No real surprise that I had replies in both of the threads you linked to.  (I am nothing if not opinionated.)

NOTES:
 - You can *read* the files externally.  (They are renamed .ZIP files, what I do is make a copy/expand them with WinRAR in a temp directory/parse each of the resulting files/move on to the next client.)
 - NO changes that you might make to those files will actually appear in Lacerte.  (So the ONLY thing you can do to affect them, is to make all of your "writes" in Lacerte.)  My recollection is several years old, but I believe trying to make changes/save new files into what Lacerte creates corrupts/destroys everything visible inside the tax program on the Notes page for that module/client #.

CUSTOM FILTER:
 - Has a hard character limitation.  If you want to record more than one piece of information, you may need to use delimiters or consistent spacing.  ("code1 | code2 | code3", or "First 8 characters for ODBC, blank, next 5 characters for <something>, blank, next 6 characters for <other>, blank...")
 - Does NOT appear in any built-in Lacerte printout, nor can it be added to them.  (Such as "on the General Information" page, or on a Database Report/client list.)
 - CAN be added to your Client List, and of course F3/Filtered upon.
 - CAN be Exported by selecting on Client List.

MULTI-SORT:
 - Doesn't really work.  Lacerte programs up to TY2018 all sorted by the left-most column.  TY2019 sorts by column header clicks (up/down), just like you see in Outlook email.  But pretty much, inside Lacerte, you can sort by one (1) column.

.

With that said...  we actually already use the Custom Filter field for external info.  (We have a custom object in SalesForce, "TR-######", for "Tax Returns".  We have a similar object for "TP-#####"/Tax Projects.)
 - We instruct all of our Preparers to BLANK that field out whenever they create a copy of a return (such as for ESTimates, TST/test situations, X/amended returns, or whatever); this ensures that a given TR exists ONLY for the tracked return that is actually being filed/billed for.
 - If the return becomes additional work for some reason--Amended, CP2000--then a TP/tax project gets created in SalesForce, so the copy in Lacerte gets the TR# replaced with the TP#.
 * I very much *HIGHLY* recommend adding a "LacerteNum" field into your SalesForce (or other external software) object build.  Preferably force it to be unique.  This is simply the 8-character client number in Lacerte.  You will ALSO need a "module" indicator, because there could easily be a SMITH123 in INDividual, GIFt, Fiduciary, and PARtnership, and the ODBC connection needs to know which one to follow.

You will need to do all of the cross-pollination work yourself, externally.  (Because Lacerte does not reach out to anything.)  So you will need to take your known TR-# in SalesForce, use the LacerteModule and LacerteNum fields to find the correct record in Lacerte, "do ODBC magic" to communicate to Lacerte about it (adding detail over the ODBC, or reading each W-2 on page10/Wages, or whatever), and so on.

Robert