Design Notes
These are notes you can input that help you and other production staff understand your confirmation elements logic and purpose. This text is never used in the live form in any way, it is only for internal development.

Form Elements
You can retrieve the runtime values of your form elements using the format:

#{field_name}

That is, for every form field element you have, it has a property of Name/Value. This Name/Value property is what identifies itself as a unique item in FormBoss, which means if you include the Name/Value in a token within the email message body, the runtime value of that field element is returned in place of the token.

An easy way to see how this works is to click on the Dynamic Variable Picker link directly below the Email Message text area. When you do so, a new window appears that automatically creates a valid list of field items. When you click on a field item Name/Value, that element is added to your Email Message.

Let's take the example of an event calendar submission form. Your users will be filling out names, dates, places, and so. The final destination for the event listing will be both web site and printed publication. In most cases this information should have a standard format, using the Email+ module lets you manipulate the field items into the format each requires. You could thus create the final event listing within FormBoss, so that when it comes time to transfer the event listing to the printed publication and web site*, you only need to copy/paste the text from the Email+ email message.

* It should be pointed out this is the exact same principal the SQL+ module uses.

The other obvious advantage of this field is the ability to create HTML formatted messages.

By default, the HTML edit function is disabled. Click the Toggle HTML WYSIWYG button to enable it. Once in HTML mode, create the message as you see fit, remembering the limitations of email formatting, such as image blocking in email clients and style limitations.

Of course when in full HTML mode you still have access to your dynamic variables, again, in the form of #{field_id}. Sprinkle these dynamic variables around the HTML email message in any form you see fit.

PHP Variables
We can retrieve the runtime values of local PHP variables using the format:

${php_variable_name}

You'll notice the syntax is almost identical to that of the Form Elements, only we use a dollar sign ($) and then the braces.

For example, let's say I create a PHP variable like so and place it into the Page PHP Top Code text box:

<?php
$text1 = 'tester text 1';
?>

To retrieve this variable at runtime, I would use the following text in my Email Message text box:

[...]dynamic PHP var: ${text1}

Notice we do not use a dollar sign in the variable name e.g., we use ${text1} not ${$text1}

One final point is that we only have access to local PHP variables, in that we cannot list a variable that has been used a previous page, nor can we use $_SESSION variables. The only valid variables are those we define on the same page as our Email+ module is running.

Combined with dynamic variables, FormBoss Email Plus gives you extraordinary flexibility

The logic takes the form of:

Variable 1 | Condition | Variable 2

For example, let's assume we have a radio item in our form with the Name/Value of opt_1. The radio item has two possible vales, 'Yes' and 'No'. If the value of opt_1 is 'Yes' we want to send an email, if no, we do not.

We would write the Confirmation Condition PHP Code as such:

#{opt_1} == 'Yes'

In other words, we use the token for our field variable like we would in other property boxes, that is, a pound sign (#) followed by the Name/Value of the field in braces. Recall that at run time this token evaluates to the value set by our forms users, which in this case will be the value of the radio button with the Name/Value of opt_1.

We then set the comparison, in this case out comparison is equal too, denoted with the double == sign. Finally, because we know our radio item is a string value that can be 'Yes' or 'No', we wrap the value we want to check for in single tick marks.

On the raw code side, FormBoss wraps the token call in an isset() block, which is further wrapped in the proper PHP if() syntax:

if(isset($_SESSION['qs']["{$_SESSION['entry_key']}"]['opt_1']) && $_SESSION['qs']["{$_SESSION['entry_key']}"]['opt_1'] == 'Yes') { // condition code start

When run, if the users set value for the radio box was 'Yes', we would process this confirmation element.

Using Array Based Form Elements (Checkboxes)
PHP Treats checkbox items a little differently than other elements. The good news is the only element that needs this special attention is a checkbox field. The difference then, is that in order to use checkbox items we need to place an index indicator just after the field Name/Value token.

For example, lets say we have a checkbox field that had the Name/Value: email_condition and has two elements: Recipient A and Recipient A

To process this field in our condition statement we need to append the proper index of the field used for checking the condition using PHP array index format. It may sound confusing, but it's quite simple when you see it:

#{email_condition[0]} == 'Recipient A'

In short, the non-array way would be to simply use:

#{email_condition} == 'Recipient A'

But because we need to check an array index (again, because PHP treats checkbox items as arrays), we simply add the [0] part before the closing brace (}).

How do we know which array index to use (the number part)? In our example the checkbox field has two values; array indexs start with 0, so the first field, Recipient A, is [0], where Recipient B would be [1].

This numbering simply climbs up by 1 for every checkbox item you add.

To: email recipient(s)
In most circumstances you'll simply input a comma delimited list of email addresses. FormBoss will then email a copy of the Form's elements in name=value format.

You can however, get more involved by using dynamic variables, those form values as identified by the id attributes of form element(s) previously defined on form pages.

For example, you could have a text field with an id of user_name. To include the user defined value of this field in your email, wrap the field 'id' in the stndard FormBoss token format like so:

#{user_name}

Now at runtime FormBoss will parse the submitted value of this field element and include it in the list of email recipients.

For best results, it is recommended to include all dynamic variables first, then any hard-coded email address as in:

#{user_name}, sample@yahoo.com

Notice the use of the space between the dynamic variable and the hard-code email. This is not strictly needed, but it does make reading a list of addresses easier.

Note: One requirement you must meet is each dynamic variable must be separated by a space.

New to Build 705, we can now use the handy Email Address Quick Select feature to quickly add saved email address to our To: field. This feature also allows us, as you would expect, to add and remove email address items at will.

SMS Carrier List
New to Build 694, this shortcut field allows us to easily select the most popular email addresses for sending SMS text messages. This allows you to send alerts to your mobile device the same as if you typed a text message directly on your phone.

It is important to note that unlike sending text messages from your phone, FormBoss will by default want to send HTML based messages. For smart phones like Android and the iPhone that have build in HTML capabilities this should be fine. For most other phones however, your message will not be viewable, as these devices do not support HTML content. Thus, as the note below this field suggests, you'll want to click the Send as Plain Text (located below this field), as that way FormBoss will only send plain text messages, which are guaranteed to be viewable by any mobile device.

From
Best supplied as an email address, however, this can be regular text. However, some servers, particularly shared hosting accounts or improperly configured dedicated servers, will need to have an email address only, as if not, the server will automatically append the servers name and domain to any value you input here.

The best method to determine your servers configuration is to simply create a sample form using email and see what happens when you leave the From: field blank. If you do get a domain name and server, contact your web host and ask them how and if you can edit the php.ini file to set a default From: address. The php.ini line looks like:

sendmail_from = me@example.com

This field is dynamic, which means you can assign any field that is not an array to process at form submission time as the emails 'from' property. Each dynamic element needs to be in token form, that is, #{token}, where 'token' in the Name/Value attribute of a form element.

From Name
As of Build 705 we can now use 'pretty' display names for the From Name: field. That is, normally when an email is sent we would just supply an email address to the From: field. Now we can specify a display name for the email as well.

This will show up in the email program's From: field as John Smith instead of jsmith@yahoo.com.

Care should be used when specifying a display name however, as a common spam technique is to use a 'fake' From Name: value.

Subject
The subject line of your email message.

Cc
A list of recipients to Carbon Copy this message on.

Bcc
A list of recipients to Blind Carbon Copy this message on.

Please be aware that due to possible limitations in the PHP mail() command, your Bcc recipients might need to be on different domains. Thus, Bcc's to user1@host.com and user2@host.com may not work as expected. Please be sure to test out the form before deploying in a production setting.

Reply To
This field allows is to set the reply-to property of the email such that when the email is sent, when we click the receivers email client reply button this is the address the email will be set as the send to address.

Email Label/Value | Item Separator
This option has two different meanings depending on what context you use it in. In the case of Simple Email submissions, the content is exactly as described below. However, if you are using the Email+ module, the usage is slightly different. Please see the Email+ module documentation for more information.

FormBoss sends the values of your Simple Email as:

{field label} : {value}

To ease in reading form submissions, by default, FormBoss uses a colon : sign to delimit the {field label} and {value}

For example, a field in formboss that has the label:

Your Name

Entered with 'Matthew' by a user, would like this when sent in an email:

Your Name : Matthew

If you want a different delimiter such as a (pipe |)  (dash -) or any other character(s) include spaces, enter them in this box.

Simple Email Table (Simple Email Only)
Instead of a simple name value pair, you can have have FormBoss create an HTML table that makes reading and manipulating from submissions easier. Please be aware, this checkbox only has an effect with the Simple Email module. This option is selected by default.

Although not widely used now, the table is styled with a CSS 3 nth-child selector, meaning when Email clients finally catch up, alternating rows will have a different color for easier reading.

Send as Plain Text
This option allows you to set weather or not your email message is sent as plain text or HTML. If you do check this box, you should be aware of how the various email settings effect the final output. At very minimum, we'll usually want to check this box when sending SMS messages, as most phones do not support HTML based text messages.

Let's assume we have two fields, Text 1 and Text 2, that hold the values: Value 1 and Value 2. The first two scenarios are when we have the checkbox checked, the second are unchecked (and thus, HTML email).

Scenario 1 - Plain Text With No Simple Email Table
Your email will be sent with each field separated with the the Email Label/Value | Item Separator you choose with each line \r\n terminated as:

Text 1 : Value 1
Text 2 : Value 2
          

Scenario 2 - Plain Text With Simple Email Table
In this case FormBoss will create a "mock" table using \t\t and \r\n elements as:

Text 1		Value 1
Text 2		Value 2
          

Scenario 3 - HTML With No Simple Email Table
In this case FormBoss will create your email with HTML formatting applied. Using the same example input from above, the code created and sent would be:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Test plain text Simple Email</title>
</head>
<body>
Text 1 : Value 1<br />
Text 2 : Value 2<br />
</body>
</html>

Scenario 4 - HTML With Simple Email Table
In this final scenario we will create HTML code that also uses a CSS3 based alternating row colors. The code created would be:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Test plain text Simple Email</title>
<style type="text/css">
tr:nth-child(even) {
background-color:#efefef;
}
.name { font-family:"Arial Black", Gadget, sans-serif }
.value { font-family:Arial, Helvetica, sans-serif }
</style>
</head>
<body>
<table width="100%" border="0" cellpadding="3">
  <tr>
    <td valign="top" class="name">Text 1</td>
    <td valign="top" class="value">Value 1</td>
  <tr>
    <td valign="top" class="name">Text 2</td>
    <td valign="top" class="value">Value 2</td>
</table>
</body>
</html>

One very important rule you must follow when using this feature: Prior to build 550, you MUST create a Simple SQL module before the Simple Email module, or else the uploaded items will not be available for use with the email.

Please note again: you need to check the Send to Database / Temporary Storeage?checkbox and any file upload item you want included with the email message!

Email Character Set (Formerly Email Encoding)
As of Build 710 this field, formerly known as Email Encoding, has been changed in terms of name to reflect its actual purpose: to set the character set of the email, both in terms of HTML charset declarations, and in the actual email body proper.

In most cases the default of UTF-8 will suffice, however, some European customers may find one of the ISO methods will produce better results. Please consult the Wikipedia Entry on Character Encoding for more.

Email Encoding (New in Build 710)
In most cases the default of 8bit will suffice, however, when using standard PHP mail() with HTML messages, we may need to switch this quoted-printable, as sometimes letters will go missing form the email message, or new ones added.

Encode Carriage Returns as HTML?
New to Build 683, this feature lets us encode line breaks and carriage returns as <br/> tags, which is useful if we want to keep a users original formatting. This feature is now enabled by default, though any jobs from older builds will need to have their email fields activated at least once for this setting to be used.

Additional Email Headers [Updated in Build 675]
Use this box to fill in any additional email headers your email client or CRM might require for security or other purposes. As a general rule, we do not want to use quotes (") in this box. Also, if adding more than one custom header, be sure to separate each with a comma!

Email Note:
All email from FormBoss is HTML formatted Unless The Send as Plain Text Checkbox is Checked.

You can use SMTP to send email. There are two main reasons why you would want to use this type of delivery:

1 - Your web hosting provider, be it paid or in-house, doesn't allow the standard PHP email mechanism (mail()) to be used. Most of the time this is for security reasons.

2 - You are on personal computer and want to send test emails in a development environment. Windows and several other OS's aren't configured to send email by themselves, so unless you have a SMTP client of some sort installed or access to an Exchange Server, POSTFIX or so on, you cannot send php mail() on your local machine. Thus, we can use FormBoss SMTP to relay mail to your web hosting provider, bypassing the no email client (MTA) problem.

Use SMTP Delivery
Unless this box is checked, FormBoss will attempt to use the standard mail() command. Checking this box means all mail will be handled via the SMTP module, which means in order for mail to work you will need to configure the additional settings outlined below.

SMTP Server Address (server:port)
The contents of this field will depend on weather your SMTP relay uses authentication or not. If they do (as is the case with Google's Gmail), you will need to supply a domain name and postfix it will a port number, separated by a colon. For example Gmail would use:

smtp.gmail.com:465

If your web hosting provider allows for SMTP relay (they almost always do), your IP address which is dolled out by your provider will act as the authentication mechanism, and thus you may not need to use a secure port, and you can instead use:

smtp.your_host.net

SMTP Username
if so required, this is the user name of your SMTP user account. On Google, this is your email address.

SMTP Password
The password of your SMTP relay.

SMTP Transfer Mode
Select from None, SSL, or TSL. For web service provider SMTP relay's you can generally leave this set to None. For Google Gmail, you would select SSL. Many corporate environments will use TSL.

Show SMTP Debug Info?
Check this box to show detailed SMTP messages, which can help you as your setting up a relay for the first time.