Technology—Property

The New Low-Code Document Automation Tools— Can You Really Build an App in a Week?

Technology—Property

Technology—Property Editor: Seth G. Rowland (www.linkedin.com/in/ sethrowland) has been building document workflow automation solutions since 1996 and is an associate member of 3545 Consulting® (3545consulting.com).

Technology—Property provides information on current technology and microcomputer software of interest in the real property area. The editors of Probate & Property welcome information and suggestions from readers.

Imagine that your firm represents a lender who finances residential and commercial property loans. Most of the legal work for these transactions is done on a fixed fee basis and uses the lender’s paper. Your law firm could distinguish itself by demonstrating the capacity to handle multiple transactions while rapidly turning around quality closing packages. A document automation system could reduce the time from term sheet to full lending package down to under five minutes and turbocharge your firm’s profitability.

Most lawyers who are familiar with document assembly software will recognize the truth of the above statement but will be skeptical of their ability to build a document automation app in a week. However, with the new “low-code” cloud-based document automation solutions now available, you can now build such an app in under a week, with a 100 percent return on investment (ROI) in the first quarter after rollout. These systems are easy to deploy. Only the author is required to install any software; everyone else works in the cloud. And, as I will show you in this article, these apps are easy to build.

By way of example, I will look at the low-code solutions offered by three leading vendors: NetDocuments, AbacusNext, and XpressDox. NetDocuments recently released PatternBuilder (https:// www.netdocuments.com/products/ patternbuilder) as a fully integrated document assembly app that can be launched from a Client/Matter workspace inside NetDocuments. AbacusNext has been moving its HotDocs Classic client base to its low-code cloud-based solution called HotDocs Advance (https://www.hotdocs. com/services/smb/). And XpressDox has largely reinvented its advanced software with the release of XpressDox 14 (https:// xpressdox.com/version-14/) a low-code and full-code solution in a single product.

I will not be offering a verdict on which product is better; each system has its strengths and weaknesses. Rather, I will show you the methodology of how to plan for, design, and then build an app on these platforms. Along the way, I will illustrate some different design philosophies in each application.

By way of disclosure, I am a former attorney who has been building document assembly solutions since 1996. As a consultant, I have built complete applications on each of the platforms discussed and at various times earned commissions on the sales of the software.

Getting Started

Building a document assembly app requires planning and effort. The more planning and effort you put into the project, the greater the reward in terms of productivity. Your goal should be to identify those document sets that will yield the greatest ROI. Your first project should be “pre-paid” based on your current business. Run the math. Review time entries, looking at both the total hours as well as the number of days from receipt of the request to delivery of the final binder.

PatternBuilder, HotDocs, and XpressDox are sold on a subscription basis that includes a hosted cloud-based server from which your app will be run. Only the “app builder” or author needs to install any software. Everyone else needs only to log in variously to NetDocuments. com (for PatternBuilder), yourdomain. hotdocsadvance.com (for HotDocs), or us.xpressdox.com (for XpressDox). For an extra charge, you can self-host for HotDocs Advance and XpressDox; but then, you will not be building an app in a week.

On the investment side, in addition to software costs, factor in the time you and your paralegal will spend building the app. On the return side, look at the time savings on drafting; assume you can reduce that time by a factor of 10 (a 90 percent time savings). Also, factor in your increased capacity to handle new business now that your drafter is more productive. And factor in the substantial savings from avoiding workstation deployment, network support, and the cost of configuring and securing a web server. If you run an entrepreneurial law firm with a transactional process, the only real question is why you haven’t started sooner; you are leaving money on the table.

Day 1: Build Your Form Set

In our example, we are going to build a residential loan package. Don’t be too ambitious. Gather the set of forms required for a single state and a single lender. You will need a loan agreement, a promissory note, and a mortgage or deed of trust. Also include the loan guaranty, the corporate certificates, the environmental indemnity, and various other side agreements. You can add share pledges and UCC filing forms to the package. A deal summary and a closing checklist should round out the package. These should be Microsoft Word documents. Ideally, they should be styled with automatic numbering, cross-references, and all extraneous hard returns removed.

In the case of the UCC form, that can be a PDF, but you will want to rename the fields in the PDF so that their names describe the data that would be entered in the form. PatternBuilder, XpressDox, and HotDocs all work with both Word documents and PDF forms.

Mark-Up Variables in the Base

Document. Collect one entire set of documents. Rename the files with a number (to sort them by importance) and a descriptive name (e.g. BNK01 Loan Agr. docx and BNK02 Mortgage.docx). Then start identifying all the merge field locations. For example, replace First National Bank, Inc. with <BANK Name TE>; replace ABC Carpets, Inc. with <BORROWER Name TE>; and replace the loan’s interest rate with <LOAN Interest PCT>. Go through the entire set of documents using a consistent markup. I will often have another Word document open with a table listing all my variables and what information they are replacing. If you are daring, you could try a global search and replace.

Consolidate Alternative Versions.

It is far easier to maintain a system that has one mortgage template with alternative scenarios for a single borrower, married borrower, or entity than it is to maintain separate loan packages for each of these scenarios. A critical review of the documents will reveal differences centered around the preamble that sets out the parties, multiple signature blocks, and then party references (gender and verbs) throughout the document. With low-code document automation, those variations can be easily handled with logic. The beauty of low code is that it does not require learning some arcane computer code; logic rules are built with drag and drop and use simple English.

Moving onto the rest of the package, the addition of logic will handle the minor language differences between a 30-year fixed interest note and a 5-year balloon note with a variable interest rate. Logic will also be used to determine whether to include or exclude a particular certificate or side agreement.

I am assuming that the attorney and paralegal are working together. Though the paralegal may be familiar with the existing forms, the attorney will know whether the differences that show up in the redline will require logic or whether they are artifacts of the legal drafting process that should have been expunged long ago. The attorney will focus on the markup; the paralegal will work with the low-code software and build the actual app.

Add Alternative Language in Brackets

For each type of document, pick one document to be used for your base template. Using Word’s “compare” function, you should be able to quickly identify the differences and the similarities. Identify the paragraphs that are different in each redlined document. Mark the language in the base document that needs to vary with a beginning and ending bracket. You can use Word comments or superscript text to indicate the logic for the inclusion (or exclusion) of that text. Now review the other documents. Where there is language that differs from the base template, determine whether those changes are (1) necessary, (2) an improvement on the base, and (3) if they are alternative language, the logic for the inclusion.

Day 2: Design Your Intake Form

Reread your new base templates. You have already put angle brackets (e.g., “<” and “>”) around each of your variables. You should also have square brackets (e.g., “[“ and “]”) around any optional text with an annotation of the required logic for its inclusion or exclusion. It is time to design the intake form that will be presented to the end user for the app.

Open up an Excel spreadsheet. Create a table with the following column heads: Markup Tag, Dialog, Prefix, Variable, VarType, Full Variable, Prompt, Options, and Notes. In the first column, you put the markup tag that you used for the variable or rule in the template. In the next column, you put in the name of the section (dialog, tab, or page) into which you want to put the variable. PatternBuilder calls them “pages,” HotDocs calls them “dialogs,” and XpressDox calls them “tabs.” They are functionally the same; these sections allow the user to group questions logically, with section headers, explanations, and logic. They are far superior to a dumb list of prompts. And with each of these applications, the prompts themselves can be smart, changing based on the user’s answers.

In the next three columns (Prefix, Variable, and VarType), you are going to put the elements of the final full variable name. The first element identifies the dialog on which the variable will be placed. The second element identifies the variable. The last element identifies the variable type. The full variable column concatenates all three elements into a single variable name. In the prompt column, set forth the question that will be presented to the user. If the question has multiple choices, specify what those choices will be in the options column. Finally, if there is some special logic or condition around the usage of the variable, use the last column to add your notes.

Now, have your paralegal go through the template and review your brackets and braces. If you missed any on this second review, your paralegal should add them to the template now and consult you if there are any questions. For each variable or logical block, make sure there is an entry on the Excel spreadsheet. Group the items by topic into sections. The sections should be divided into those questions that are relevant to all or most forms, and then those questions that are relevant to only particular forms. This will be important later when you build in logic.

As you place questions into sections, also reorder the rows of the spreadsheet so they appear in a logical order that would make sense to the end user. Start with the most important dialogs first; these are the questions that are used on most of the documents. In our example, you would group questions about the lender on the lender dialog, questions about the borrower on the borrower dialog, and questions about the nature of the loan on the loan dialog. These dialogs would appear first. If there are questions that only appear on a guaranty agreement, you would create a separate dialog for these questions and this dialog would have a logic rule that it would appear only if a guaranty was required.

Pay close attention to how you name your variables; the dividend will come later when you start “dragging and dropping” variables to build the master interview. We divide variable names into three parts. The prefix identifies the section where I want to put the variable. The suffix identifies the data type. And in the middle, we put what the question is. For example, the question: “What is the name of the lender?” becomes LENDER Name TE; it is in the lender section of my interview, it asks the name of that lender, and the data type is a “text” variable. By contrast, LOAN Maturity DA would be the loan maturity date in the loan section, and LOAN Interest PCT would be the interest rate as a percentage.

You may need to review the templates multiple times. Once your paralegal has the spreadsheet completed, you should review it; paying close attention to the questions asked and some of the logical rules that would control whether those questions appear in the interview.

Day 3: Build Your Intake Interview

The spreadsheet is your roadmap for building the app. With a well-designed spreadsheet, I usually hand off the app building to someone else who is at a lower billing rate than I am. The roadmap should tell the coder everything the coder needs to know. Here is where the design philosophies of PatternBuilder, HotDocs, and XpressDox differ.

Assigning Variables to Sections.

The first step is to create the variables and assign them to sections.

In PatternBuilder, after you create the blank app, you must first create the pages. Give the page the same name as the section on the spreadsheet. Then add variables to the page, using the data type definition you put on your spreadsheet. All this happens in the cloud. PatternBuilder does have a desktop tool, but that is used primarily for inserting variables and logic blocks into Word documents. All the interview design and configuration occurs in the cloud.

In HotDocs, you need to install and use a desktop application called HotDocs Author. Create a workspace. Add your templates to the workspace. We recommend creating an “Answer Intake” template which would be functionally equivalent to the “ app” in PatternBuilder. For each section, you would add a dialog. For each variable, you would add a “variable,” and then you would drag the variables onto the dialog.

In XpressDox, you also need to install a Word add-in on your desktop. This add-in appears as a toolbar ribbon inside Word. All activity is controlled by options on the ribbon. XpressDox is template driven; all the elements you need are stored on the actual Word document. With the new low-code version, XpressDox uses advanced wizards and hidden text to hide the complexity of the program. Just click the New Question button and follow the prompts. After you have created your questions, launch the Manage Interview wizard. All your questions will appear. Add tabs for each section; then drag the questions into the appropriate tab. As you add more questions, they will appear on the general tab, from which they can be reassigned to other tabs.

Apply Logic to Sections and Variables

The strength of the low-code solution is the ability to add complex logic without learning a new programming language. PatternBuilder, HotDocs, and XpressDox each take a different approach to add logic to the interview.

In PatternBuilder, you add logic to the page or the individual variable. For example, if you have a page of questions on limited guarantees, you would include a question: “Is anyone guaranteeing the loan?” If the answer is yes, then the page of questions on limited guarantees appears. Adding this rule is a matter of flicking the switch to “conditionally display” the page. You then choose the question and the answer that would trigger the display. To add logic to a question, you would flick the switch “show if” to yes and then add your logic rule. For more complex logic such as multiple questions, you would create a logic block, give it a name, and then use that.

In HotDocs, you can take two approaches: relevance or scripting. If you choose relevance, the application will look at the logic inside the templates and then gray or hide questions that are deemed irrelevant. In the case of the limited guaranty, if that language in the template is surrounded by the question, “Do you need a limited guaranty?” and if that question is answered “no,” none of the limited guaranty questions will appear. If you choose scripting, then it will be up to the author to write a script for the entire dialog that includes “Hide and Show” instructions. Scripting gives you exceptional control over the interview.

In XpressDox, the default engine uses relevance. With the Manage Interview wizard, you choose which questions go on which tab and the order they appear. All the logic is handled based on the usage of those variables in the templates. If a question is needed, then it appears automatically. If none of the questions in a section is used, then the whole section disappears from the interview. If required, additional scripting can be used to conditionally force relevance even though a question is not actually used in the document.

Test, Test, and Test.

In all three programs you can run a test assembly to see what the interview looks like in operation. I recommend testing the interview as a standalone and refining your questions, so they make sense in context. Please try not to change the underlying variable name. Changes in variable names require careful consideration because they may lead to additional changes elsewhere in your app.

Day 4: Code Your Documents and Upload

Once your intake interview is built, it is time to convert your markup into functional templates. This is where these low-code programs shine. If you are consistent in your markup, conversion is a mix of (a) search and replace, (b) drag and drop, and (c) highlight and tag. Your Excel roadmap should show you what markup tag you used in the template and also what field or rule you wish to use in its place.

Replacing Fill Points.

It is best to replace the markup tags in several passes. Work your way through the spreadsheet.

Start with simple fill-point variables such as names, addresses, dates, and amounts. Replace each of these brackets with the new one from your intake sheet.

In PatternBuilder, there is a Word plugin and an online editor. If your templates have outline numbering or special formats, you must use the Word plugin. For quick and dirty templates with no formatting requirements, you can use the online editor. Both the Word plugin and online editor have a side panel that gives you access to all the variables in your app. From there it is a matter of dropping the variables in place in the document. If your markup has the same name as the variable, you can run a wizard that automatically replaces those markup tags with PatternBuilder variables.

In HotDocs, there is a desktop application (HotDocs Author) that has a workspace explorer to manage the templates, a component studio to manage the interviews, and a HotDocs field editor as a Word plugin to handle inserting variables. Once you have created the master interview, all your variables should be available in the field editor. Highlight the text and choose “placeholder.” You must choose the type of variable field before you can find your variable on the list. If the variable doesn’t exist, you can create it directly from the sidebar in Word.

In XpressDox, there is a full desktop install, but there is no need to leave Word to do any of your work. Everything you need is in the Word plugin ribbon. You have access to a command assistant which contains both your data elements and all available commands. If you have named your fields with prefixes denoting the section or dialog where they are placed, you would have a nicely sorted dictionary of all available fields. If you forgot to add a question, just click on the “New Question” button and define the prompt and variable name.

Add Rules to Conditional Text.

Once all the fill points are done, turn to the conditional text. This is where you will integrate the scenario logic you captured on Day 1 to set off the alternate paragraphs.

In PatternBuilder, conditional text needs to be placed in a logic block. Inside that logic block, you can have other logic blocks. You then insert the logic block with its formatted text into the template. While nested logic is supported, it can sometimes be hard to build and maintain these complex logic structures.

In HotDocs, conditional text is controlled by a begin logic tag and an end logic tag in the actual Word template. Highlight the conditional text. Then, under action items, choose “Create a conditional region”. Choose your condition type, select your variable and define the rule. There is support for complex conditions, as well as the ability to nest multiple layers of logic. For reusable blocks of text, you can also use Insert templates surrounded by conditions.

In XpressDox, the conditional text is similarly controlled by begin and end logic tags in the Word template. Complex and nested logic is also supported. Just highlight the conditional text block and click on the “IF BLOCK” button. Select your variable from the list and choose the condition. The correct code is added to the template. If you need to revise it, you can just edit the text of the rule directly. Like HotDocs, there is support for conditionally inserted templates. You can insert templates as a signature block or letterhead that contain variables that are passed into the block at runtime, thereby simplifying the template design.

Calculated Variables and Text, Number, and Date Formatting.

Finally review the template to address special formatting requirements, such as expressing amounts formatted as dollars or in words. There may be capitalization requirements. In some cases, you may have dates or amounts that are derived from other questions. For example, if you have a loan amount and an interest rate, you might want to calculate the monthly principal and interest payments. If you have a closing date and a term of the loan, you might want to calculate the maturity date and the last payment date.

In PatternBuilder, there are logic blocks that define values, others that define conditional expressions, and others that define resulting blocks of text. These are built within the app with an expression editor. For a conditional expression, just choose the variables you want to test and the values you want to test for. If there is an additional condition, just click on “Add Expression.” When you are done, give the logic block a name, and you can use it anywhere in the app. As for formatting text, dates, numbers, and currency, when you add the variable to your template, there is an option to apply formatting that depends on the type of variable. Just choose what you want to be done and drop the variable in place.

In HotDocs, you can choose to create logic blocks called “computation variables,” or you can simply just type the logic into your template. The computation variables make sense if you want to reuse the logic in multiple places; otherwise, using the IF BLOCK wizard to build your logic string is easier. As for text, date, and number formatting, there are format examples that handle everything from special dates, to current, to capitalization. If there isn’t one that meets your requirements, you can create a computation that has parameters and does whatever you need.

In XpressDox, like HotDocs, you can choose to create logic blocks called a script that contains all your rules; you can use the If Block wizard, or you can simply type the logic of the rule. Script blocks are particularly powerful in XpressDox as they can contain local variables, parameters, and formatted text. You can also choose “Edit Fill Point” at any time to add formatting to a variable, with a full range of formatting options.

Day 5: Build Package Wizard, Run Your Tests, and Refine Rules

Up to this point, you have built a master interview and several individual templates. It is not yet an application. You need to tie together the interview and templates into a single app. To do so, you will need to understand what rules determine whether or not a document should be included in the package. You need to build a document wizard that tells the program which documents to assemble.

Picklist Versus Logic.

The choice to do a picklist and define logic depends on the level of sophistication of the end user. The picklist is the easiest way to both create and present a document wizard. Users can be presented with a series of checkbox variables, one for each document, with the name of the document to be assembled. If the user checks the box associated with a particular document, then that document will be assembled into the package. But what if the user is unsophisticated and doesn’t fully understand which documents are required for the loan package? In this case, you would ask a series of questions about the type of loan and the parties. Based on the answers to those questions, the correct set of documents for the package would be chosen.

Single Document Versus Separate Documents.

In defining a wizard, you also need to define what the output will be. If all your templates are Microsoft Word documents, you can merge them into a single Word document and output them to Word or PDF. Alternatively, you can produce a series of individual Word documents. In XpressDox and PatternBuilder, you can set the name of each of those output documents. In HotDocs, output documents get the filename associated with the template. If you have a mix of pdf forms and Word documents, you would need to choose to output separate documents. Depending on your desired output, your app design would change.

In PatternBuilder, you would create a page early on, maybe even the first page, where you would ask which documents the user wants to prepare. If you were doing rule-based document selection, your first pages would define the type of loan, the type of property being financed, and the nature of the parties. Based on these answers, certain pages would appear and on the final pages, you would place conditions on the assembly of individual templates. Because PatternBuilder is integrated into the NetDocuments workspace, you can also automatically file the output documents directly into the ClientMatter workspace. Because PatternBuilder doesn’t at present support inserted templates as HotDocs and XpressDox do, however, you are limited to producing individual documents.

In HotDocs, you would build an Answer Intake template to hold the interview questions. You then could add a series of ASSEMBLE instructions if you wished to have a bundle of individual documents. Alternatively, you could create a master template with INSERT instructions to merge the chosen templates into a single output.

In XpressDox, the best practice would be to create a master template. That template would contain an InsertTemplate instruction to insert the full text of the template into the master document or it could use MergeTemplate instructions, which would merge the template as a separate document, using the answers given in the master interview. Once the documents are assembled, there is the ability to dictate the name of the documents and the folder in which to put the documents. Recently, integration was added to file documents back to NetDocuments workspaces directly.

Are You Ready to Get Started?

The new low-code, cloud-based document automation solution can make it possible for more attorneys than ever to access the power and efficiency of document assembly. With the ability to quickly create smart interviews and code smart templates, there is no excuse not to be using a document assembly system. Using the above instructions will allow you to easily and quickly create a legal document package of any type. The end result will be quickly seen in improvements on the bottom line and in the smiles of your satisfied clients. In answer to the question: “Can you really build an app in a week?” I would most definitely say “Yes!”

Published in Probate & Property, Volume 37, No 1 © 2023 by the American Bar Association. Reproduced with permission. All rights reserved. This information or any portion thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.