Tag Types
For each tag, you must select a Tag Type. The following table lists the available options, their purpose, and usage:
Field | Description |
---|---|
Copy to Code | The tag value is copied into the specified category code field. Normal validation rules are applied just as if the value was typed into the field. If the data needs to be converted to another value before it is inserted into the code field, use the Map Type and Map Group options on the tag definition. |
Comment to End | Indicates that the tag value contains a multi-line, free form comment entered by the user of the Web form. During clean up, all lines are copied from this tag line to the end of the email message body. Therefore, It is essential that this be the very last tag contained in the email. |
Comment to Tag | Indicates that the tag value contains a multi-line, free form comment entered by the user of the Web form. During clean up, all lines are copied from this tag line until another tag is found. This occurs even if the tag is not defined in the tag list. Use of this type of tag is discouraged since the user may accidentally match tag value syntax in the comment block, causing incorrect processing. If this is used, your Web form developer is advised to take steps to ensure that the user is unable to include the tag delimiter as part of the text. |
Copy Multi-Line to Code | This is a combination of Copy To Code and Comment To Tag. It allows a multi-line comment to be copied into a Survey Question with an Answer Type of Text, or to the Instructions field on an address record. For more information about Answer Type, see the Survey Question Fields section on page Defining Survey Questions. Do not use this option to copy information into a standard category code because a carriage return/line feed combination is inserted between each line, which cannot be edited by the normal user interface. |
Year Part | See below. |
Month Part | See below. |
Day Part | See below. |
Combined Name | Indicates that the tag value contains some combination of the following name fields: Title, First Name, Middle Initial, Last Name, and Suffix. The system will make its best effort at splitting the value into the appropriate fields. However, you should enter the Last Name value in the To Category for this tag to work properly. Combining these values in a single field on the Web form is not a recommended practice. It is better to include each of these items as separate fields in order to ensure accurate processing. |
Email (Parse) | Indicates that the email address is to be extracted from the full value. For example, the emaill address |
Email Name (Header) | Similar to Combined Name, but the sender's name is extracted from the email headers rather than from a tag. This can be used when the Web form does not place the email address into a tag, but rather "simulates" sending the email from the user. It can also be used for direct emails (emails sent directly to an email account rather than created by a Web form). |
Email Address (Header) | Indicates that the sender's email address is to be extracted from the email headers rather than from a tag. This can be used when the Web form does not place the email address into a tag, but rather "simulates" sending the email from the user. It can also be used for direct emails (emails sent directly to an email account rather than created by a Web form). |
Combined City, ST ZIP | Indicates that the tag value contains some combination of the following name fields: City, State, Postal Code. The system makes its best effort at splitting the value into the appropriate fields. Therefore, no value needs to be specified for the To Category for this tag. Combining these values in a single field on the Web form is not a recommended practice. It is better to include each of these items as separate fields in order to ensure accurate processing. |
Combined City Next Line | Indicates that the tag value contains an address line, followed by City, State, and Postal Code on a separate line with no tag. Example: The To Category must specify a destination for the address line (typically Address1). The other values are split up as described in the previous option. |
Phone Extension | Indicates that this field contains a phone number extension, without the main part of the phone number. The system appends this value to the phone number field on the Emplifi Agent address. Keep in mind the following:
|
Survey Run ID | Used to specify a Survey Run ID to import Survey Questions into. The Survey Run ID itself should be specified in the Set To Code column of the tag definition. |
Append To Code | If the target column already has a value, this value is appended to it. This only works for categories defined with a type of String. For more information , see Category Types. |
Append With Blank | This is similar to the Append To Code option, except that a single blank space is inserted before appending each value. |
Set Fixed Code | Use this option to create default values for the Import Form. The value in the Set To Code column is copied directly to the To Category. No tag name needs to be entered. When using this type to set a default value for another field that the user may not have specified, make sure the sequence number on this tag rule displays before the rule for the user-entered value. If that value is present, it overwrites the default. If it is not present, it is ignored, and the default specified here is still used. (If the sequence values were reversed, this value would always overwrite any user-entered value.) |
Inactive Tag | This setting specifies that no processing should be performed for the tag value, except for the Clean Type option, which still applies. |
Month, Day, and Year Parts
These tag types are used when a date value has been split up into three different parts: month, day, and year. The three values are merged back into one value and placed into a category code whose category type is either DateTime, or Date with a format of "mm/dd/yyyy" (or "dd/mm/yyyy," depending on your locale). For more information about category types, see Category Types.
When using these Tag types, make sure to observe the following:
When defining the tags, make sure to set up their sequence values so that they are processed in the following order: month, day, year.
Make sure each tag indicates the same value for its To Category.
For month and day, the values can be either one or two digits, with or without leading zeros.
For the year, the value can be either one, two, or four digits. See below regarding information on one- and two-digit years.
If Year is not specified, it defaults to 1970.
If a time value is also required, it should be placed in the email immediately following the year value (without a tag). This inserts the time properly.
Handling of 1- and 2-digit Years
We recommend that you work with your Web form designers to ensure that all dates are sent with four-digit years, to avoid any ambiguity.
If that is not possible, you can enter a value in the Missing Value field on the tag definition of the "Year Part" tag to instruct Emplifi Agent how to handle the year. The following logic is used:
The date is never more than 100 years in the past. The logic uses a 100-year rolling calendar.
A positive value entered in this field instructs Emplifi Agent that the date can fall that many years into the future. Adding this number to the current year gives the high end of the range.
A negative number indicates that the date is never in the future. The current year is used as the high end of the range. (Any negative number has the same effect regardless of its value.)
The following table shows some examples:
Value On The Form | Current Year | "Missing Value" Field | Allowable Range | Year Calculated by the System |
---|---|---|---|---|
19 | 2017 | +3 | 1921-2020 | 2019 |
19 | 2017 | +1 | 1919-2018 | 1919 |
18 | 2017 | +5 | 1923-2022 | 2018 |
18 | 2017 | -1 | 1917-2016 | 1918 (a negative number indicates that a future date is not allowed) |
45 | 2017 | -17 | 1901-2000 | 1945 |
02 | 2017 | 0 | 1918-2017 | 2002 |
35 | 2017 | +15 | 1933-2032 | 1935 |
35 | 2017 | +19 | 1937-2036 | 2035 |
The logic works similarly for 1-digit years (also not recommended), except that a 10-year rolling calendar is used, instead of a 100-year calendar.