'Process' (Options/Optional) text vs. variables

Process text is 'structural.'
The chosen options are saved in the final document, but are not otherwise preserved for reuse elsewhere.  

Variable text is 'personal.'
It can be saved independently from the document as well as within the final document. It can be reused with any other document.

   The question frequently arises "when do I use a variable and when do I use an <<*Options/Optional*>> text block to hold a spot for a specific term?"

   The answer can generally be determined by answering these four questions:

   1. "Is the content personal to the person or company for whom the document is being assembled, or is the content more structural in nature?"    

When you think of 'variables,' you typically think 'personal' or 'identifying' type of information. Names, colors, quantities, values and the like. A variable is something short and unique to the customer or client, that typically could have an infinite number of responses. It is also something that you would consider saving into a permanent database record.

<*Options*>> text, on the other hand, is something that is document oriented. While the final document is personal to the client or customer, the actual language is likely boilerplate until it is personalized. The choices of text blocks are finite (as opposed to an infinite number of names). While the document is saved for posterity, it is not saved for reuse in a subsequent document (as would a client's name or address, etc).

   2. "When is the most logical time to provide the 'answer' to the question? (Is the information structural, used to create the body of the document?  Or is the information personal or 'finishing' in nature.)

'Options' and 'Optional' text is processed as the document initially is being assembled. If it seems that the text should be 'placed' or 'excised' before personal or 'finishing' information is provided, then think 'Options' or 'Optional'. Otherwise, think variable.

   3. How long is the text.

'Options' and 'Optional' text is, compared to variables, typically much longer. That is why we call them <<*Options/Optional*>> text blocks. Variables are typically short both in name and in replacement values.

  Example and discussion:

Dear [Customer Name].

   Thank you for your order placed on [date of order].  

   Your local representative is [Name of Rep]. [He/She] will contact you within 5 business days to discuss installation.

   <<*Optional*Please note. Due to the special pricing of these items, all sales are final.>>

      [Name of Order Taker]

   In this example, most entries are variables. Each need a 'personal' replacement value in order for the letter to complete. Each variable is short and each calls for information that is personal to an actor. Each answer is something that is appropriate to save into the customer's data record.

   Sometimes all sales are final, sometimes they are not. So sometimes the last line of the letter (above the signature) will remain in the letter and sometimes it will not. Regardless, the text is 'structural' to the letter, not personal to the buyer. Plus, it is (relatively) lengthy. Therefore, it is appropriately an <<*Optional*>> text block.

   A note of assurance: When choosing between using a 'variable' vs. 'options/optional' text, keep in mind that your initial choice matters little in the big picture. Don't fret it. If you choose one and, upon reflection, the other seems the more appropriate, you can readily change it. Switching from <<*Optional/Options*>> text to [bracketed variables] is simple a matter of replacing a few characters in the body of your text. That, quite simply, is the beauty of 'plain text document assembly.'