The Search for the Perfect Baguette

It has been a few weeks since the return from our trip to Paris.  We have mostly readjusted.  We will shortly be moving our office from Croton-on-Hudson to the neighboring town of Cortlandt Manor. But there is one area where we feel as great loss; for we miss the perfect breakfast.  In Paris, or rather Boulogne-Billancourt, we had 3 boulangeries (bakeries) within walking distance from our apartment.  Each morning we would make an expedition (two blocks) to the bakery and pick up a fresh baguette (.95 Euros / USD $1.25).  We would also pick up croissant beurre, croissant almonde, pain au chocolat, or brioche.  We would top it with fresh butter, nutella or confitures.  And for the adults, drink it with freshly brewed French Roast coffee. And so, on our return, we sought to reproduce this simple pedestrian breakfast.  The pastries and baguettes were ALWAYS fresh from the oven.  The had delicate crips crusts.  The insides were light and airy, almost delicate.  The bread “snapped” in your fingers and crackled under your teeth.  The croissant were light, flaky and exuded butter.

Well, it hasn’t been easy.  Our local ShopRite (which has everything), sells loaves that are shaped like French bread, but resemble more in texture partially cooked pizza dough.  The bread is soggy to the touch when bought, with a cold clammy texture. When warmed up to get a crispy crust, the bread is hard and tough.  Sharp teeth are required to tear the break.  Rather then melting in your mouth, repeated chewing is required to aid in digestion.

The croissants are even worse.  They “look” like croissant, but the resemblance ends at the external appearance.  The French croissants were layer upon layer of delicious flaky crust, such that you could unpeel the croissant, and eat it layer by layer. The ShopRite croissants were a single undifferentiated mass of dough.  Yes, there were not too dense, and they were buttery, but they had none of the texture and feel of the French version. Once you went beyond to the Almond croissant and the Pain au Chocolate, it got worse.

I then moved on to the local “Gourmet” establishment.  They had a wider selection and variety.  The French breads (when they were available) had a gold crust and crackled when you squeezed them. But the weight of the bread was wrong.  They were too heavy.  The dough was dense and chewy.  They were interested breads, but they lacked the Artisanal flavor and texture we could get in any boulangerie in France.

Part of the reason, I am told, has to do with CULTURE.  In France, the local bakery has two production runs: early morning and mid-day.  The breads are made without any preservatives.  The means that the lucious baguette of the morning is the stale loaf of the evening, fit only for bread crumbs and croutons. And bakeries are located on every other block.  Each morning and each evening the “chefs”, including little chefs, cue up to get the fresh breads out of the oven.  In the U.S. we have “factory-sized” bakeries that ship breads through distribution centers to large markets.  Breads may take 24-48 hours from when they are made to when they show up on your shelve for you to buy on your weekly (not daily) shopping expedition.  In such a food cycle, French bread, with its 12 hour life cycle, would be long dead and stale before it got to your table.

For us, “lost in suburbia”, our option is to take the train to Zaros at Grand Central Station or learn how to make our own bread.  At present, we are decided on the later.  We will begin to yeast our our starter loaf, and put it in the convection oven while the rest of the family does their morning showers.


Sometimes, there are things you want done to your assembled document that HotDocs simply cannot do.  Perhaps you want to check margins for a specific section, re-style an inserted template on the fly or automatically run a custom in-house print macro upon completion.  For these sorts of tasks, the PLAY instruction is what you wish to use.  PLAY will tell your word processor to run a specified macro after your document has been created (ie: after the interview, but before it displays as a document).  If there is more than one PLAY instruction in a template, HotDocs will process them in the order encountered.

The syntax for a PLAY instruction is pretty simple:

«PLAY "MyMacro"»

To insert the PLAY instruction, go to the HotDocs button on your HotDocs toolbar, click “Other Field”, then specify PLAY from the drop down box.  You will be asked for the macro name you wish to run.  Click OK.

Notes About PLAY

If you use WordPerfect, your macro can be stored anywhere. If it is outside the default macro location, then your play instruction must have the full file path.

If you use Word, the macro must be stored in the template itself, or some other template that is loaded and available at the time you assemble your document.  If you are using Word RTF templates, you may optionally associate a specific template via the Component Manager.

HotDocs Instructions – LIMIT

When it comes to REPEATS in HotDocs, LIMIT is one very handy instruction to know how to use.  As its name suggests, it will LIMIT the number of iterations a repeat can hold, by placing the instruction in the dialog script of the dialog you wish to limit.  Please note that this is entirely different to the number of rows shown on a repeating spreadsheet dialog.  LIMIT will restrict a dialog to have only (for example) 3 iterations, where as the rows shown command will allow a repeat to hold countless iterations, but only show a specified number.

The most basic use of LIMIT is to provide a fixed number, such as:


This doesn’t really help you much, unless you are certain your dialog is only ever going to repeat 3 times only.  Here, we can introduce the concept of a user-specified LIMIT.  Lets say we have a dialog named Child DLG that collects some general information about all the kids, as well as a variable named CHLD CNT – asking the user how many children there are.  On Child DLG is a repeating sub-dialog Children RPT – it will repeat once for each child.  In the dialog script of Children RPT, we could have


This is better – we ask them how many kids, then LIMIT the repeating dialog to that number.  This will stop “empty” repeats in our templates where users have clicked forward and answered a field accidentally.  Great.  Lets make it a bit easier to use.  Instead of CHLD CNT as a number variable, lets use CHLD Num MC as a multiple choice variable, with options from 1 to 20.


Now, our user can click the number of kids from a list and our LIMIT instruction converts the multiple choice value to a number value.  Simple, straight forward and user friendly.

The above technique can also be used to dynamically show more rows on repeating spreadsheet dialog dynamically

HotDocs Instruction – LANGUAGE

The Language instruction allows you to design, code and assemble templates in HotDocs in a language other than English.  To be able to use this feature, you must first contact a Lexis Nexis sales representative to obtain a DLL for the language you wish to program with.  HotDocs has DLLs for the following languages:

ENG (English), DEU (German), DES (Swiss German), DEA (Austrian German), FRA (French), NLD (Dutch), ESN (Spanish), ITA (Italian)

Using any of the codes above, the instruction you place in your template is as simple as:


Also with the Language instruction, it is possible to format the thousands and decimal separators.  The following instruction would use the Italian language, set the thousands separator to a period “.” and the decimal separator to a comma “,”.


INSERT template

Not to be confused with the ASSEMBLE command (which queues a template for assembly after your current template has finished), the INSERT command does exactly that – inserts the content of one template into a different template (known as the “parent” template).

This instruction is extremely handy and very under utilised as it is useful for a wide variety of things, not just inserting letterhead!

The INSERT command should largely be used in templates.  There are ways to use the INSERT command inside a computation, but there are limitations and rules that apply.  Allegedly, an INSERT command cannot be placed inside headers or footers in your template however, we have found that it works just fine with footers, which can save some time in some situations.  At any rate, here’s how it works in several different ways –

Template in same location as the template you are inserting into (known as the “parent” template)
«INSERT “Template.rtf”»

Subfolder of location of parent template
«INSERT “SomeSubfolderTemplate01.rtf”»

Full file path for anywhere on your system
«INSERT “T:HDTemplatesLitigationTemplate01.rtf”»

Using a Reference path
«INSERT “^HotDocsLitigationTemplate01.rtf”»

Default Templates folder
«INSERT “Template01.rtf”»

The INSERT statement is quite often used inside IF statements to conditionally insert oeprative parts of documents.  Interstate notices, optional schedules, attached forms etc are all usually INSERTed inside IF statements.

Common Uses for INSERTed Templates

  • All stationery, such as letterheads, faxes and memos, with accompanying headers, footers and page numbering
  • Signing / execution clauses (say, a single “corporate execution” block and a single “power of attorney execution” block)
  • Court headers and footers
  • Boilerplate text such as acceptance clauses, court seals, hearing dates, witness blocks and the like
  • RE lines on letters
  • Schedules

Additionally, INSERTed templates are quite often used simply to segregate content in long templates, so that each template can be tested by itself in isolation to the rest of the template.

Some Off Label Uses

With a bit of effort, it is possible to set up INSERT templates to take parameters.  All you have to do is write your INSERT template with a temporary variable that you SET before you insert.  Here’s a quick example:

INSERT Template Code:

Some random text up here that is boiler plate and always appears regardless of how the INSERT template is used.

«IF OPT UseNotice TF = TRUE»
This notice must be complied with within 14 days unless otherwise specified.

More random text here about something or nothing at all really.

«IF tmpTE = "Borrower"»
This notice is directed to the Borrower's solicitors and must be complied with within 7 days of the date hereof.
«ELSE IF tmpTE = "Lender"»
This notice is directed to the Lender's solicitors and must be complied with whenever convenient to the Lender.

«IF OPT UseFooter TF = TRUE»
This footer is absolutely pointless except insofar as it demonstrates the concepts of parameters in INSERT templates as applied by the HotDocs document assembly engine.

So all we have really done here is code the INSERT template with some preset variables to hold preset values.  Then, when its time to insert the template, we set the parameter variables prior to inserting the template.

PARENT Template Code:

«SET tmpTE TO "Borrower"»«SET OPT UseNotice TF TO FALSE»«SET OPT UseFooter TF TO TRUE»
«INSERT "OurInsertedTemplate.rtf"»


The humble IF statement is the core of all logic in any programming language, HotDocs included.  IF statements don’t actually do anything but rather, they provide a structure within which other commands are executed.  To bring any intelligence to your document-producing systems, you must understand the IF, ELSE IF and ELSE statements, as they are used everywhere.

I’ll work with a computation for these examples, as it is simpler than the template version, as no chevrons are required.  Lets get some examples happening.  Lets say we have a variable named “Var TE” and Var TE has a value of “Bob”.

Example #1a – the basic IF statement

IF Var TE"Bob"
"His name is Bob"
//this would produce "His name is Bob".

Example #1b – the basic IF statement

IF Var TE"Joe"
"His name is Joe"
//this would produce an error

The above code produces an error because Var TE does not equal Joe (it’s still Bob) and there is no script in place to handle what happens if the variable isn’t equal to “Bob”.

So lets look at how to handle that with an ELSE statement.

Example #2 - IF and ELSE
IF Var TE"Dave"
"His name is Dave"
"His name is not Dave"
//this would produce "His name is not Dave".  In this example - we have some code to run if his name is "Dave", ELSE (readable as "if its anything else in the world..."), produce "His name is not Dave".

This still isn’t ideal.  What if we want to do something specific for Bob OR Dave, but something entirely different if it isn’t either of them?  Lets look at the ELSE IF statement.

Example #3 – IF, ELSE IF and ELSE

IF Var TE"Dave"
"His name is Dave"
"His name is Bob"
"His name is not Bob, nor is it Dave"
//This would produce "His name is Bob". If we set Var TE to the value of "Mark", the result would have been "His name is not Bob, nor is it Dave"

The easiest way to read this stuff when you’re learning is as follows:

IF (Some specific condition is true)
//do something here, for this condition only
ELSE IF (Some other specific condition is true)
//do something different, for this condition only
ELSE (if its anything else in the whole wide world)
//do something different here if nothing previously is true
END IF (close the statement)

In english, it would read exactly as it is typed above – IF something is true, do something, else if something different is true, do something different for this condition only, else if its anything else in the whole wide world, do something here.  It gets tricky, but it is really just a series of “what if this is true” questions and results.

Some things to remember….

1) Every IF statement must have a matching END IF – they are a fixed pair with no exceptions!
2) ELSE and ELSE IF statements can only occur inside an IF/END IF pair.  They do not have matching END IFs themselves
3) Nested IF and END IF pairs must nest “inside” each other.  I’ll use bracketed numbers in place of conditions to demonstrate:

IF (1)
//do something

IF (2)
//do something here
//do something different

IF (3)
//do something different again
//do something weird
ELSE (3)
//do something really weird
END IF (3)


As you can see, IF statements work from the inside out.  It is nearly always best practice to write your IF and END IF at the same time, then move your cursor back and complete the rest of the commands between the IF/END IF pair.  If you open an IF statement and immediately close it, you will not lose where you are up to with code and save yourself substantial time debugging problematic HotDocs code.

Please note: HotDocs will evaluate your IF statements from top to bottom.  In the above example, if IF statement #2 was true AND IF statement #3 was true, HotDocs would only produce #2 – because it will find a true If statement, produce the result and then jump straight to the END IF.  Bear this in mind when designing your code.


These four commands are essential in presenting user friendly and user-proof dialogs in HotDocs.  When designing systems, it is generally best practice to show only those variables that require (or may require) an answer and HIDE or GRAY those that are irrelevant.  HotDocs provides a rudimentary manner to handle this automatically, but if you are designing complex systems, you may need to use these four commands. All of these instructions are used in dialog scripts only.

GRAY Var //grays Var, prohibiting data entry, but displaying the value (if any)
UNGRAY Var //UNgrays it, allowing data entry
HIDE Var //completely hide the variable
SHOW Var //opposite of HIDE

Here are some examples that should be fairly self explanatory…

//hide the company type, only showing it if relevant.
HIDE PARTY Entity Company Type MC
IF PARTY Entity Type MC"Company"
SHOW PARTY Entity Company Type MC
REQUIRE PARTY Entity Company Type MC

//calculate a total amount, but gray it so it isn't editable
//allow them to manually change it if they REALLY want to
IF SALES Grand Total Change TF = TRUE

Instead of using a variable name, you can also substitute the “ALL” parameter….

GRAY ALL //grays everything on the dialog
UNGRAY ALL //ungrays everything

When building a system to really lockdown data entry, you may wish to write a dialog script something like this to force entry of everything in the correct order…


IF ANSWERED ( PARTY Entity Type MC//must have a type before we allow name entry
IF PARTY Entity Type MC"Company"
SHOW PARTY Entity Company Type MC
REQUIRE PARTY Entity Company Type MC
SHOW PARTY Entity Company Number TE
IF ANSWERED ( PARTY Name TE//must have a name before they can proceed further
//more SHOW/REQUIRE pairs here

All of these commands are dynamic as of HotDocs 6, which is a major step forward.  Whilst they may look like eye candy, these instructions serve to produce better and more accurate documents every time, simply by forcing/prohibiting better data entry.  When combined with REQUIRE, you really can obey the rule that “if a variable is visible, it must be answered and if it is invisible, it is irrelevant”.  When your systems can follow this rule, your users do not have to have any knowledge of what they are working with or understand the sometimes complex concepts behind the scenes – all they need to know is that if it CAN be answered, it SHOULD be answered and if it cannot be seen, don’t worry about it. Apps for Lawyers

What if you could access your network from ANYWHERE and at ANYTIME?  What if you could check your calendar, check your task list, do your billing and access all your documents? What if you could do this WITHOUT A NETWORK?  What if you could do it WITHOUT a Server, without a terminal server, and without any network infrastructure at all?  What if the entire network was IN THE CLOUDS.  Wouldn’t that be great (for you that is)?  What if this cloud-based system was infinitely customizable, and infinitely expandable?  What if you could purchase “plugins” and other packages to extend the functionality of the database? What if there was a network of consultants who could assist you?  What if there were hooks into Web-based document assembly applications like EXARI? What if I told you this system was already built and opened for business last month.  Take a look at AdvologixPM.

AdvogixPM is a Application.  It is built on  This platform is used by almost every Fortune500 corporation.  It is a cloud-based application that was designed, originally, to make a “mobile salesforce” truly mobile. Rather than replicating databases (which could be stolen or lost), it was designed as a complete and secure CRM (Customer Relationship Management) system that allowed salesmen and women to track leads, manage accounts, post documents,track calls and emails in a centralized hosted environment on the Web.  What turned this from a hosted CRM into a world-shaking application was the open API that built.  To make the system acceptable to large sales organizations, enabled users (with privileges) and developers to add new fields, add new reports, record types, dashboards, analyses, and ANYTHING they wanted.  They then let developers “package” the customizations and created a marketplace where those packages could be “given away” or “licensed”.

So where does this affect lawyers who, by their own classification, are not in the sales business?  The answer is AdvologixPM.  The infrastructure of Salesforce already meets many of the needs of lawyers.  What is missing are MATTERS, and support for practice-specific details that lawyers want to know about their clients.  Further, the system does not natively support client billing.  What Advologix has done is stand on the shoulders of giants and build a Legal Practice Management system on top of Salesforce.  It is, indeed a complete and comprehensive system.  It does what a practice management system should do, and does it quite well.  And you don’t have to worry about backups, network services, remote access or anything.  All you have to worry about is paying your Monthly user fee. The fee will be more than you pay annually for your current practice management solution software.  The difference, arises, however, if you look at TCO (Total Cost of Ownership).  No server; no need to apply software updates, no installation costs, and worldwide access.

Now where the application gets interesting for me and my clients is in two areas.  First,it is infinitely customizable.  If a client comes to me with a bankruptcy practice and wants to track special creditor details in a table, I can modfy the application to add the necessary table and fields.  And, if I do a good enough job, I can package up those modifications and “license” them to another client.  They could make the changes themselves, or they could leverage my expertise in data gathering, workflow and document assembly in that field. The second place where it gets interesting.  Exari has released a application NDA Generator on Exari.  Here we are leveraging a world-class web-based document assembly engine with a world-class CRM system, none of which needs to be installed on a server that we manage.

There are some TRADEOFFS when you program a application.  There are somethings about the way the application works, what some tables are called that you cannot change.  Since the core application was designed by someone else, you are limited to working with what that company has built.  As a result, you will not have the spartan and intuitive design appeal of a RocketMatter or a Clio practice management system that was designed from the ground up as a practice management system.  You will need to look closely at what Advologix has done to Salesforce, and weigh what additional modifications you can make and compare them to both Client/Server applications (like Time Matters, Amicus Attorney and PracticeMaster) and to RocketMatter and Clio offerings.  The good news is there are a lot of innovative solutions out there for to choose from.  And now there is one more.


Another HotDocs instruction model that does exactly what it sounds like, FORMAT allows you to specify the formattin of a “list style” RESULT.  Rather than explain, I’ll simply provide 2 examples which demonstrates everything you’ll ever need to know about FORMAT.

Lets have a repeating dialog named “Party RPT” that has a single variable on it – PARTY Name TE.  Lets produce some differing results with FORMAT, presuming that we have 3 names in our list:

Example #1

FORMAT "a, b and c"
//the RESULT is Seth Rowland, Rose Rowland and Ian Burrows

Example #2

FORMAT "a-b-c"
//the RESULT is Seth Rowland-Rose Rowland-Ian Burrows

All it is doing is specifying the format in which a list style result is accumulated and represented.


The HotDocs instruction “FILTER” is one that I use in almost every system that I’ve designed.  Its purpose is exactly what it sounds like – to filter (a repeat), based upon a certain criteria, so that the data output from the repeat is reduced – only the repeats that match the filter come out.  Like most instructions, it is best explained by example.

Lets say we have a repeating dialog named “Party RPT” that collects information regarding, well, parties in our fictitious matter. A party can be a corporation or individual (PARTY Entity Type MC), but never both. Throughout our system, we are constantly required to insert a sequence of all party names, as well as a sequence of all corporation names.  While we COULD use REPEAT instructions in our templates, this will not work in repeating templates, nor repeating sections.  So lets use the filter command to meet our requirements AND simplify code (its much easier to pre-calculate such lists instead of coding them in every template!).

Party RPT (dialog)
PARTY Name TE (name of party)
PARTY Entity Type MC (type of entity - individual or corporate).

GEN Parties All Names TE (list of all names of all parties)
GEN Parties Corp Names TE (list of all corporations only)

So lets do our “list of all parties” first – this would go in a computation…

FORMAT "a, b and c"
SET GEN Parties All Names TE TO RESULT

That’s it – all done.  Very simple, and now GEN Parties All Names TE contains something like “Seth Rowland, Basha Systems LLC, Ian Burrows, Routine Automation Pty Ltd and John Doe”

Now, lets use our FILTER instruction to slim that list down to only the companies.  Here is our filter computation, named “fil Party Companies CO”

PARTY Entity Type MC = “Corporation”

That’s it – a straight forward test: is the party entity type a corporation? yes/no.  So lets use this, again in a computation…

FILTER fil Party Companies CO
FORMAT "a, b and c"
SET GEN Parties Corp Names TE TO RESULT

GEN Parties Corp Names TE now has a value of "Basha Systems LLC and Routine Automation Pty Ltd".

Filters are absolutely fantastic, as they allow you to eliminate a lot of repetitive code and variables.  Take a litigation system for example, with Plaintiffs, Defendants, Third Parties, Plaintiffs by Counterclaim, Defendants by Counterclaim.  You COULD have a separate repeat for each of these parties.  Alternatively, you could have a repeat for Plaintiffs, with a checkbox to indicate that they are also optionally a defendant by counterclaim – then use filters on this variable.  Taking it one step further, you could simply have a dialog Parties that contains ALL parties in the matter, then use multiple-choice, multiple select variables to specify all the roles that a given party may have.  Another example is real estate documents – a given party may be a borrower, but optionally a mortgagee.  If it is an investment property, they may also be a lessor/landlord.  Occassionally, they may ALSO be a caveatee.

Filters allow you to collect information once centrally and then filter it in various ways to produce exact results.