P2P

40 P E E R T O P E E R : I L T A ' S Q U A R T E R L Y M A G A Z I N E | S P R I N G 2 0 2 3 buyers, sellers, executors, assets, debts, shareholders, etc.). Furthermore, you probably want the ability to calculate things based upon the number of records entered. For example, if you're automating an estate planning document, you'll need to be able to enter lists of children (possibly), Executors/PRs, beneficiaries, guardians, and trustees. Take children, for example. A highly evolved list function would allow you to enter an unlimited number of children. For each child, you might provide the name, gender, date of birth, and whose child it is (in the case of a married client, a child from a prior relationship or a child of the marriage). From that, you would be able to automatically pull out the list of minors or adults (based on date of birth), the pronouns would all calculate correctly (based on the gender answer), and you would be able to extract separate lists of stepchildren or children of the marriage. Further, the list would be able to automatically count the number of children entered so that it could correctly produce language such as "children are" or "child is." Depending upon the complexity your documents require, you may also want the ability to have nested lists. In other words, lists within lists. For example, assume you have a deed template and you would like the ability for it to handle multiple grantors. Those grantors may be any combination of individuals, married couples, entities or trustees. Further, you may have a limited liability company as grantor and want the ability to have multiple signatories on behalf of any entity grantor (that would be a nested list). In fact, you might have an LLC grantor and signing on behalf of the LLC is a corporation as managing member, and signing on behalf of the corporation are multiple officers. That would be a parent list plus two nested lists, one within the other. Imagine if you had a deed template that could handle any number of grantors and grantees, and also any number of signatories on behalf of the grantors up to four levels deep. Such a template would be able to produce a punctuated list of grantors, plus the appropriate signature lines and acknowledgments, no matter how byzantine the grantor corporate structure might be. In any event, the ability to gather, process, sort, filter and punctuate lists is necessary in most legal instruments, but not all DA platforms offer this capability. This is another capability I view as essential. A B I L I T Y T O C O M P L E T E P D F F O R M S Every platform should be able to produce documents which can be opened in Word. However, you may need the ability to also complete PDF forms. By that, I mean check the appropriate boxes and fill in the blanks based upon how questions were answered in the Questionnaire. Several platforms provide this functionality. A B I L I T Y T O H A N D L E I N S E R T E D T E M P L AT E S For example, assume you need to build 50 templates for various types of pleadings. The caption, signature blocks and certificate of service may be common across all of them. It would be very handy if you could make sub-templates for those items which are simply inserted into the parent templates in the appropriate places. In that manner, editing the one signature block sub-template would automatically update all 50 templates into which it was inserted. F A M I L I A R I T Y W I T H T E M P L AT E D E V E L O P M E N T E N V I R O N M E N T For example, if your office uses Word, then you probably want to choose a platform that allows you to create templates in that environment. If the platform uses its own word processor for template creation, that can be a negative because it may not possess Word's best functionality. Worse, there is always the possibility that your formatting will go sideways if a document created in another platform is opened in Word. Q 1 W H I T E P A P E R S

• Cover