I am suggesting a complete removal of the text description screen and instead utilize the data entry fields that are mostly already there to populate any policy or commitment. There is a chain of title screen, an encumbrance screen and exception screen. There are fields in other screens that house needed info. for these two products, and perhaps others. Instead of having to enter the info. TWICE - once in the appropriate screen that houses the data for future reference and a second time in the text description fields to populate your product, have the product pull from the appropriate fields in the file just as they do with say the borrower's name or like the documents when we generate those pull from fields. This would save a heck of a lot of time, cutting it in half, and eliminating the need for that text description screen which isn't very user friendly.
Text Description is badly named. It does not fit in the normal flow when producing policies. Also, exceptions do not populate unless the Text description is visited and every dropdown tab visited and saved! Exceptions should automatically load for all policies and editing would be to remove or add anything unusual. As it is now, policy exceptions DO NOT populate and there is a danger of issuing policies without exceptions printed if the Text Description isn't visited. Terrible!!!!!
You can request support remove unwanted extra screens for your system. I don't have the chain of title , encumbrance, or exception screen.
I do utilize the text description screen. Well, I should say that my bot does. I have preprogrammed a bot to use the information sent back from my search to click and fill in all the areas needed. It takes the things that can change from file to file such as names, dates, amounts, etc and combines them with the standard language we use in our commitments. Like this:
Record proper release of the [name of document] dated [date], executed by [if purchase, use seller name, if refi use buyer name], in favor of [lienholder], in the sum of $[amount], of record in [book and page or instrument number] Register's Office for [name of county] County in TN.
Actually what should be done is ”title policy description” should be renamed “Title” and text descrption moved under that heading and called “commitment requirements/exception” or something similar. We never Use chain of title, exception or encumbrances as fund members get their commitments from the branch office That are imported into title policy info and “text description“
eclosing does need to make use of long standing relational database pracitces - for example:
instead of copying text from one table to another (example: lender name , when you change anything in the contracts it doesn’t automatically update the same info in the file you are in because they field in the dataentry screen doesn’t related that field in the contacts table and instead of just copying the over and from that table and dropping it in to this one. To update it, you have to change the lender to something else and back to get it to update).