List Group Definition
- To access the definition wizard for a list group, open the list group overview of the desired group. Then select Open List Group Definition from the menu (or go via the right-click menu of the list group node in the subscriber warehouse tree).
- To create a new list group, select the Subscriber Lists node on the subscriber lists overview in the subscriber warehouse tree on the left. Then select New Subscriber List In New List Group... from the menu (or go via the right-click menu of the subscriber lists node in the subscriber warehouse tree).
The list group wizard lets you edit the settings of an existing list group.
Note: A list group is only fully editable while it is "empty", meaning that there are no subscribers or any lists in the group. For a non-empty group, only certain settings are editable.
The wizard has four pages: General, Profile Fields, Profile Field Details, and Summary.
The top row of the wizard displays links to these four pages. The page that is currently open is highlighted. Depending on the choices made on some of the wizard pages, other pages may become disabled or may be shown in different versions. If a wizard page is disabled, then it means that this page is not necessary with the current choices and can safely be ignored.
Profile Field Details Page: Input Controls, Lookup Tables, Derivation Rules, Input Validation and Other Settings
This screen may have several different tabs, which are described below. Not all of these tabs are always present, and when only one tab would be present, the screen is shown without tabs.
Input Controls
For each subscription profile field, you can define the visual appearance of the input control that is associated with the field.
LISTSERV Maestro uses the subscriber's email address not only as target address for email but also as unique account name when the subscriber logs in to the subscriber website. This has the effect that two different types of input controls are used on the subscriber website for the subscriber email address: The "Login Address" input control and the "EMAIL" input control, with the latter only being used when the subscriber views the email address as part of the subscription profile.
Thanks to this distinction, you can configure two different sets of visual details for the email address input.
Similarly, the Maestro subscriber website provides special input controls for the password that is associated with each subscription, either assigned automatically by Maestro during subscription and later defined by the subscriber, or specified already during subscription by the subscriber.
To summarize: For the email address and password, there are four different special input controls, and each of them can be given specific (and different) visual attributes. Depending on the type of list that you are editing, additional special input controls may be available.
Login Address: (Not available for lists in a list group.) This is the input control for the registered subscription email address and is used to identify the user who is trying to login. Note: The EMAIL input control defines the visual appearance of the email address input control when it is used to define the subscription email address, both during initial subscription and when the user changes the subscription profile.
Login Password: (Not available for lists in a list group.) This is the input control for the registered subscription password and is used to verify that the password is correct for the given login address.
Subscribe Password: (Not available for lists in a list group.) This is the input control to define or change the registered subscription password.
Password Confirmation: (Not available for lists in a list group.) This is the input control to confirm the supplied subscribe password, used in the usual fashion to protect the user from mistyping the subscribe password.
List Topics: (Only available for Hybrid Subscriber Lists with LISTSERV list topics.) This input control allows the user to pick from the topics that are configured for the list.
Subscription Status: (Only available for lists, not for list groups.) This input control allows the user to temporarily disable email delivery.
Subscription Type: (Only available for Hybrid Subscriber Lists.) This input control allows the user for example to only receive standard LISTSERV list postings in weekly or daily digest form, if possible.
Email Header Style: (Only available for Hybrid Subscriber Lists.) This input control also only applies to standard LISTSERV list postings and allows the user to configure special attributes of the delivered list messages.
Hide Subscription Option: (Only available for Hybrid Subscriber Lists.) This input control allows the user to configure if the subscribed address shall be visible when other list subscribers query LISTSERV for a list of subscribed addresses.
For each of the available input controls (the special input controls above and one input control for each subscription profile field), the screen allows you to define its visual aspects:
Input Control: This is the name of the input control, i.e. either its special name (see above) or the database name of the associated subscription profile field.
Label: Defines the label next to the input control. Try to use short labels and make use of the description (see below), if necessary. By default on wider screens, the label is shown to the left of the input control (this is why short labels cause less problems). On a narrow screen, the labels are shown on top of the input control.
Description:
Allows you to supply an additional textual description.Show As:
Describes what type of input control is used to render the field.
Directly on-screen, the properties described above are shown in read-only fashion. To edit the visual aspects of an input control, click on the associated Edit link.
This opens the Edit Input Control dialog. Edit the visual aspects in this dialog and click [OK] to submit your changes or [Cancel] to close the dialog without saving. Note: For some types of fields, the input control can not be changed (e.g. the password fields are all shown with the type "Password Field").
Input Control Settings
The settings you supply in this dialog define the details about how the input control is shown on the pages of the public subscriber website.
For some of the input controls, the pages of the subscriber website explicitly represent the associated field with a placeholder in the customized HTML code. These placeholders, in turn, support customization by attribute/value pairs, allowing you to define different visual appearances for different pages. If you do not perform such explicit attribute/value customization in the HTML code of the page, then the settings you define in this dialog apply instead, consistently for all pages that may show the associated field.
To assist you in the case that you plan to define deviating visual appearance for some of the input controls, the lists below contain the necessary details under "Customization Syntax". This information is included even if the style setting in question belongs to a field that is never mentioned explicitly as a placeholder. The standard profile fields are examples of this, these fields are included dynamically on the pages that must show them, which means that you can not customize their visual appearance through attribute/value customization in the code, you must use the settings here on this screen.
Available Types of Input Controls
The following list describes the input control types that are available for the various types of fields or subscriber options.
| Type of Input Control | Description | Customization Syntax |
|---|---|---|
| Standard Edit Field | Field is rendered as a free-text input field. | |
| Checkbox | Field is rendered as a checkbox. | type="checkbox" |
| Drop-Down Menu (Single Select) | Field is rendered as a single-value dropdown list. | type="dropdown" |
| Multi-Selection List | Field is rendered as a multiple-value dropdown list. | type="list" |
| Array of Radio Buttons | Field is rendered as a list of radio buttons. The buttons are arranged in a grid whose visual aspects can be customized further. | type="radiogrid" |
| Array of Checkboxes | Field is rendered as a grid of checkboxes. The checkboxes are arranged in a grid whose visual aspects can be customized further. | type="checkboxgrid" |
Style Attribute Settings
The following lists describe all available default profile field style attribute settings. Depending on your chosen type of input control and other settings, the input control edit screen contains only a subset of the full lists below.
| Setting | Description | Customization Syntax | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Input Field Size | Defines the size (in characters) of the edit field. | size="[NUMBER]" | ||||||||||||||||||
| Size of Multi-Selection List | Defines the vertical height of a drop-down menu with multi-select enabled. | maxrows="[NUMBER]" | ||||||||||||||||||
| CSS Class | Defines the name of the CSS style class (or classes) that shall be assigned to the edit field. | styleclass="[TEXT]" | ||||||||||||||||||
| CSS Class (If Field Enabled) | Defines the name of the CSS style class (or classes) that shall be assigned to the edit field if the field appears in an enabled context. | enabledclass="[TEXT]" | ||||||||||||||||||
| CSS Class (If Field Disabled) | Defines the name of the CSS style class (or classes) that shall be assigned to the edit field if the field appears in a disabled context. | disabledclass="[TEXT]" | ||||||||||||||||||
| "Yes" Option Text | Defines the text of the dropdown list choice or the radio button that corresponds to the boolean "true" value. | yes="[TEXT]" | ||||||||||||||||||
| "No" Option Text | Defines the text of the dropdown list choice or the radio button that corresponds to the boolean "false" value. | no="[TEXT]" | ||||||||||||||||||
| "Yes"/"No" Options Order | Defines the ordering of the two dropdown list choices or radio buttons. | order="noyes" order="yesno" |
||||||||||||||||||
| Grid Orientation | Defines the orientation of the grid of radio buttons or checkboxes. | order="horizontal" order="vertical" |
||||||||||||||||||
| Radio Button Separator | The value of this attribute defines the text that shall be rendered for a separator between radio buttons. | separator="[TEXT]" | ||||||||||||||||||
| "Please Select" Option | Defines the text of a third choice that is shown as the first choice of the dropdown list and which acts as a "reminder" choice. The user is not allowed to submit the page while this choice is still selected. | select="[TEXT]" | ||||||||||||||||||
| "Yes"/"No" Options Alignment | Defines how the radio buttons are aligned in respect to each other. | align="horizontal" align="vertical" |
||||||||||||||||||
| Array Size |
Defines how the array dimensions are determined, either by limiting the maximum number
of rows (and use a growing number of columns to show all options) or by limiting the
maximum number of columns (and use a growing number of rows to show all options).
|
|||||||||||||||||||
| CSS Class for Grid Table | Defines the name of the CSS style class (or classes) that shall be assigned to the HTML table which surrounds the grid. | tablestyleclass="[TEXT]" | ||||||||||||||||||
| CSS Class for Grid Rows | Defines how CSS styling with one or two classes is applied to each row in the HTML table which surrounds the grid.
|
|||||||||||||||||||
| CSS Class for Grid Cells | Defines the name of the CSS style class (or classes) that shall be assigned to each cell in the HTML table which surrounds the grid. | cellstyleclass="[TEXT]" | ||||||||||||||||||
| Position of Default Value |
If the profile field is an optional profile field, then one of the choices is the "No
Selection" choice. This attribute defines where in the grid the "No Selection" choice is to
be rendered. Available choices are:
|
|||||||||||||||||||
| Only used if the profile field is the source field for another field (single- or multiple
select), where the lookup table subset that the other field displays depends on the value selected in this profile field,
and the subscriber who views the page has JavaScript disabled, so a change in this field
is not recognized automatically but must be submitted manually by the subscriber. In this situation, the profile field is displayed either as enabled, so that the subscriber can change its value and then must click an "apply" button. Or it is displayed as disabled, so that the subscriber must first click a "change" button before the field is enabled and the value can be changed. |
||||||||||||||||||||
| "Apply" Link Text | The text that is used for the "apply" button that is shown with the profile field control when the profile field is
enabled and its value can be changed. The "apply" button needs to be clicked to submit the changed value. Note: The button is not visible if the subscriber has JavaScript enabled, in which case the submit happens automatically as soon as the subscriber changes the selection. |
applytext="[TEXT]" | ||||||||||||||||||
| "Change" Link Text | The text that is used for the "change" button that is shown with the profile field control when the profile field is
disabled and the "change" button needs to be clicked first before the field's value can be changed. Note: The button is not visible if the subscriber has JavaScript enabled, in which case the fields is always enabled and its value can always be changed. |
changetext="[TEXT]" | ||||||||||||||||||
| "Apply/Change" Link CSS Class | Defines the name of the CSS style class (or classes) that shall be assigned to the "change" or "apply" button (if visible,
see above) that is shown with the profile field in some situations. Default: "lsoft_lma_maestroFakeLink small" (as defined by the style sheet) - i.e. the two classes "lsoft_lma_maestroFakeLink" and "small" (the first class "lsoft_lma_maestroFakeLink" makes the button look like a normal link instead of a button). |
applychangeclass="[TEXT]" | ||||||||||||||||||
| "Subscription Active, Receive Mail" Text | The value of this attribute defines the text that shall be displayed for the "Subscription Active" choice. | mailtext="[TEXT]" | ||||||||||||||||||
| "Subscription Suspended, Do Not Receive Mail" Text | The value of this attribute defines the text that shall be displayed for the "Subscription Inactive" choice. | nomailtext="[TEXT]" | ||||||||||||||||||
Hybrid Subscriber List Settings
The following settings only apply if the selected list is a Hybrid Subscriber List. Similar to the various other subscriber choice option settings, these settings define the text with which certain LISTSERV list subscription options are presented as a choice (in the form of a drop-down option or radio button, see above) to the list subscribers.
| Setting | Associated LISTSERV List Subscription Options | |
|---|---|---|
| For "Acknowledge Style" Option: | ||
| "No Feedback" Text | NoAck NoRepro | |
| "Short Confirmation" Text | Ack NoRepro | |
| "Copy of Message" Text | NoAck Repro | |
| "Copy of Message and Short Confirmation" Text | Ack Repro | |
| For "Subscription Type" Option: | ||
| "HTML-Format Digest" Text | Digests NoIndex MIME HTML | |
| "MIME-Format Digest" Text | Digests NoIndex MIME NoHTML | |
| "Plain Text Digest" Text | Digests NoIndex NoMIME NoHTML | |
| "HTML-Format Index" Text | Index NoDigests MIME HTML | |
| "Plain Text Index" Text | Index NoDigests NoHTML | |
| For "Email Header Style" Option: | ||
| "Normal LISTSERV header" Text | FullHDR | |
| "Normal LISTSERV header, with List in Subject" Text | SubjectHDR | |
| "Full LISTSERV header, with individual To:" Text | Full822 | |
| "Short LISTSERV header, with individual To:" Text | Short822 | |
| "Short headers" Text | ShortHDR | |
| "Second LISTSERV header in email body" Text | DualHDR | |
| "Sendmail-Style (preserves original header)" Text | IETFHDR | |
Legacy Layout Note: If the list or list group already existed before your system was upgraded to the current version, Maestro still supports the legacy mechanisms that have been in place to show input fields to your list subscribers on the subscriber website. Some of the special input controls above (or, more precisely, the ability to customize their visual appearance) did not exist in previous versions, which is why Maestro only lists a subset of the special input controls described above while your list group is using the legacy layout. In addition to this, many of the special visual attribute customizations have been managed by Maestro differently in earlier versions, but this legacy mechanism is still supported and is also still used while your list group is using the legacy layout. In other words: If you did supply special default profile field style attributes for your list fields, then you will still see these attributes being used by Maestro and you will also still be able to modify these attributes similarly to how they have been used before.
To fully benefit from all available special input controls and the recent mechanism to configure visual attributes for responsive behavior on narrow screens, you should consider converting your list group to use the new public subscriber area website layout. More about the public subscriber area website.
Selection Field Sources
This tab only appears if there are profile fields of the Single Select or Multiple Select type in the subscriber list or group. In this case, for each of these fields, the lookup table must be specified that is used to define the values that the subscriber may select from.
The tab displays the name of each such profile field together with a drop-down menu that contains all lookup tables that can be used together with the profile field. Select a lookup table from the drop-down menu to associate it with the corresponding profile field. The description of the selected lookup table appears beneath the drop-down menu so that the selected lookup table can be verified as the desired one.
This step needs to be performed for each profile field that has one of the two types listed above.
It is possible to assign the same lookup table to several different profile fields (if that is desired).
Note: Only lookup tables that are using the encoding "ASCII" or that are using the same encoding as was specified for the dataset (or in case of a list, the encoding that was specified for the dataset the list belongs to) can be selected.
For a dataset that already contains subscribers or lists, or for a list that already contains subscribers, the lookup tables assigned to already existing profile fields can no longer be changed. If a new field is added to such a dataset or list (on the Profile Fields page), then the lookup table for this new field can be assigned, but the lookup tables of the other fields still cannot be changed.
Lookup Tables with Subsets
If a lookup table has subsets defined, and such a lookup table is selected for one of the profile fields on this tab, then the following additional options become available.
Just below the drop-down menu where the lookup table is selected, a second drop-down menu with the label Value subset to display becomes available. Select from this second drop-down menu the lookup table subset that the profile field in question will actually display to the user. If you select <Full List of Values>, then all values from the selected lookup table will be displayed by the profile field. If, however, you select one of the subsets from the drop-down menu, then only the values from the lookup table which are elements of the selected subset will be displayed by the profile field.
If there are several single- or multiple-select fields defined, of which at least one is a single-select field, then the second drop-down menu will have the additional choice of <Depends on other field>. This choice allows you to dynamically change the lookup table subset that is displayed by the profile field, depending on the user choice in another (single-select) profile field. This is best explained with an example:
Imagine a list that is marketing various online services in the United States, where each subscriber is supposed to be able to individually decide which services he/she is interested in and which not. The easiest solution for this would be to set up a lookup table called "Services" with an entry for each available service. Then, include a multi-select profile field in the list so that each subscriber can pick exactly those services he is interested in.
However, assume that for legal reasons some of these services can not be offered in certain states. In the above scenario, all subscribers would still be able to pick from all entries in "Services"; therefore, we would potentially send offers about certain services to subscribers that live in a state where these services are not available in the first place.
Here lookup table subsets come to the rescue: First, we need a second lookup table called "States", which lists all states in the USA. Then, we add another profile field (single-select in this case) to the list, which uses the "States" lookup table.
Next, we define several subsets in the "Services" lookup table, where each subset groups together the services that are available in certain states. At worst, we would have to define one subset per state (if the available services in all states are different). However, more likely many states have the same group of available services, so for each of these groups, we create on subset (with a meaningful name).
Finally, we edit the definition of the existing multiple-selection field so that it does not always display all of the "Services" entries, but only a subset. And, the subset that is displayed depends on the new "State" single-select field. Simply put, the state that is selected will determine what services are available for selection, which means that a subscriber can never select a service that is not available in his/her state.
This final step of defining that the "Services" multiple-select field will only display a certain "Services" subset, depending on the selected value in the "States" field, happens here on this tab.
For this, you select the mentioned <Depends on other field> choice from the second drop-down menu. By this, you tell the system that the subset (for the selected lookup table) that is to be used for display may vary depending on the choice in some other field.
As the next step, you now define which other field will be the source field for this dependency. Select the source field that the subset depends on from the third drop-down menu, the one with the label Displayed subset depends on selection in field (this third drop-down menu appears once you select the "<Depends on other field>" choice in the second drop-down menu).
And, as a last step, you finally need to tell the system how this dependency will be defined. To do so, click on the Define or Edit link that appears right below the third drop-down menu, once you have selected a source field name.
This opens the Dependency Mapping dialog where you can define the dependency mapping between the values of the selected source field and the subset that is to be displayed by the profile field for which you are currently defining the settings. The dialog shows a table where each possible value in the source field (which is always a single-select field) is displayed in the left column. The right column displays an associated drop-down menu for each value. For any given value, the selection in the drop-down menu defines, which lookup table subset will be displayed by the profile field, if the associated value from the left column is selected in the source field. The available choices are:
- <Empty List>: If selected, then the profile field will
display an empty list, if the associated value is selected in the source field.
- <Full List of Values>: If selected, then the profile field will
display the full list of lookup table values (i.e. no subset, but all values), if the associated value
is selected in the source field.
- Any Subset Name: If one of the subset names is selected, then the profile field will display only the lookup table values which are elements in this subset, if the associated value is selected in the source field.
Once you have defined the dependency mapping, click [OK] to close the dialog and save your changes, or click [Cancel] to close the dialog without saving.
Derivation Rules
This tab only appears if there are profile fields of the Derived type in the list group or subscriber list. In this case, for each of these fields, the rule must be supplied that defines how LISTSERV Maestro shall derive the value for the field. Such a rule is called Derivation Rule.
The tab displays each derived field together with its current derivation rule. Click on the associated Define or Edit link to define/edit the rule for a field.
This opens the Derivation Rule dialog:
Depending on your profile fields, you may have one or two options to define the derivation rule. If you have two options, then the dialog displays two radio buttons that allow you to choose between the two options. Once you have selected an option, you can then provide the details for that option. If you have only one option, then the dialog only displays this single option, without any radio buttons, so you can immediately provide the details for that option.
-
Mirror secondary lookup table value of a single-select field: This option is only available if among your profile fields there is at least one field of type Single-Select, and the lookup table that is assigned to this field is a table for which secondary columns have been defined (see the advanced settings of a lookup table for details about secondary columns).
The single-select profile field itself always displays the main value from the associated lookup table. A derived field however can be used to display the values from one of the secondary columns in the lookup table. In such a situation, the derived column "mirrors" the selection of the single-select field, but for display it picks the value from a specific secondary column, instead of from the main column, like the single-select field itself does (see also the example below).
Select the name of the single-select field that you want to mirror from the Mirror value of field drop-down menu. Once you have made this selection, you can then select the secondary column from which the value names shall be used from the Use secondary value drop-down menu.
Example: The subscriber profile shall contain a single-select field where the subscribers select the region they live in (for example, their country). Each of these regions shall have a specific service phone number, and each subscriber shall automatically see the correct service number for his/her region. To accomplish this, follow these steps:
-
Create a "Region" lookup table, with all available regions as the main values. Add a secondary column called "Service Number" to the lookup table and fill it with the corresponding service phone numbers for each region.
Note: Values in the secondary columns do not have to be unique. Therefore, it would be no problem if some regions have the same service number.
-
In the list (or list group) itself, create a single-select field called REGION, and then assign the "Region" lookup table to this field. Each subscriber can now select the region he lives in, which is stored as part of his/her profile.
-
Create a read-only derived field called SERVICE_NUMBER. Define the derivation rule of this field as "Mirror secondary lookup table value of a single-select field", with "Mirror value of field: REGION" and "Use secondary value: Service Number" as the settings.
Now, when a subscriber selects his/her region for the REGION field, the derived SERVICE_NUMBER field automatically reflects the service phone number for the selected region. And since this derived field is read-only, it is displayed to the subscriber in his/her profile, so that he always has this information available. And should the subscriber change his/her region, his/her service phone number is automatically adjusted accordingly.
Note: Only the single-select fields that are defined in the same object as the derived profile field are available in the "Mirror value of field" drop-down menu. This means that if the derived field is a shared list group field, then it can only reference a single-select field that is also defined in that list group. If the derived field is a field of a subscriber list, then it can only reference a single-select field in the same subscriber list. It can not reference a single-select field from the list group the list resides in.
-
Calculate value with the formula below: This option is always available. Simply enter the calculation formula that Maestro shall evaluate to determine the value for the derived profile field. This can be any kind of formula, using all available formula features.
The formula can be a constant formula, which would mean that all subscribers have the same value in this derived profile field. However, a formula as a derivation rule is most useful if it is (at least partially) based on other profile fields, and thus not constant. In such a case, each subscriber has an individual value in the derived profile field (although not necessarily a unique value), as the formula is calculated individually based on the values of his/her profile fields.
For example, the following formula would extract the domain-name part from a list group subscriber's email address and store it in the derived field:
Substring(&EMAIL;, IndexOf(&EMAIL;, "@") + 1)
(This could be useful for all kinds of analyses, like reporting over how many subscribers have their accounts at the various ISPs or organizations, or similar.)
Note: In the formula, you can only reference other profile fields that are defined in the same object as the derived field itself. This means that a formula of a derived field in a list group can only reference other fields from the same list group. It can not reference fields from any lists in the list group. And, a formula of a derived field in a subscriber list can only reference other fields from the same list. It can not reference fields from the list group the list resides in or fields from other lists. A derived field can however reference other derived fields, as long as this does not create an endless recursion of references. I.e. a chain like "DERIVED1 references DERIVED2 references DERIVED3 etc." is possible, a recursion like "DERIVED1 references DERIVED2 references DERIVED1" is not possible.
When you are finished editing the derivation rule, click [OK] to save your changes, or click [Cancel] to close the dialog without saving.
When to Use Derived Fields and When Not
Derived fields require additional storage space in the system database and additional processing power by the server when their values are calculated. Therefore, a derived field should only be used if there is actually a need for it. Some situations where a derived field seems like a solution can actually be solved without a derived field, in which case this other solution should usually be preferred.
You should also be aware that you can always add an additional derived field to an already existing subscriber list, even if there are already subscribers on the list. Therefore, you should usually refrain from creating a certain derived field if you have any doubts about if you will later actually be using this field. Instead, you should only add it once it turns out that you actually require it.
A derived field is the correct solution for the following situations:
Include Field in Subscriber Profile: The value of the derived field is supposed to appear as a visible value in the subscriber profile, so that the subscriber can view this value on the corresponding profile page in the subscriber area.
For example, a derived field that displays the service phone number that matches the country that a subscriber has selected. For this, a "read-only" derived field is the correct choice (in contrast to a "hidden" derived field, which a subscriber does not see in the profile).
Include Field in Tracking Reports: The derived field is supposed to be available in a Recipient Details tracking report (for a job with either personal or anonymous tracking).
For example, a derived field that extracts the domain name from the subscriber's email address would allow a tracking report that can show you how many recipients clicked on a certain link (or opened the email, etc.), broken down by recipient domains. For this, usually a hidden derived field is the correct choice (although you can also use a read-only field, if you also want to display the value in the subscriber profile, see above).
Include Field in Demographic Breakdown Reports: The derived field is supposed to be available in a demographic breakdown report of a list group or subscriber list.
For example, a derived field that extracts the domain name from the subscriber's email address would allow a demographic breakdown report that can show you, how many subscribers you have per subscriber domain. For this, usually a hidden derived field is the correct choice (although you can also use a read-only field, if you also want to display the value in the subscriber profile, see above).
Include Field on Browse/Edit Page: The derived field is supposed to be included in the subscriber list on the browse/edit page, so that you can see the various values there, and also filter the list over these values.
For example, a derived field that determines the zodiac sign depending on the value in another profile field that contains the subscriber's date of birth. For this, either a read-only or hidden derived field is the correct choice (depending on if you want this value to also be displayed in the subscriber profile or not, see above).
In contrast, a derived field is usually not the correct solution for the following situations:
Mail Merging: A certain derived value is supposed to be included as a merge value in the body of an email message. For this, you should not use a derived field (unless you also need the derived field for other situations anyway, see above). Instead, simply include a *Calc system drop-in in your email message, with the same calculation formula that you would also have used for the derived field.
Target Group Condition Tree: A certain derived value is supposed to be used to filter the recipients in the condition tree of a target group. For this, you should not use a derived field (unless you also need the derived field for other situations anyway, see above). Instead, simply use the same calculation formula directly in the condition tree that you would also have used for the derived field.
Input Field Validation
This tab only appears if there are any profile fields of the Text type (other than the EMAIL column of the dataset) or Number in the dataset or subscriber list. In this case, the tab allows for optionally defining additional input validation rules for each of these fields.
The tab displays the name of each such profile field together with a drop-down menu containing the possible input validation types.
For Text Fields:
- Accept all values: No validation will be applied, all text input is valid (with a maximum length of 100, which is imposed by LISTSERV Maestro). Note that for some encodings, like UTF-8 or asian language encodings, the maximum character length may even be less than 100, depending on the specified value.
- Full Name: Input will only be accepted if it can be interpreted as a valid "Full Name", meaning a first name followed by a last name. To fulfill this requirement, the input must consists of at least two text strings separated by at least one space character. Examples for valid "Full Names" include: "John Doe", "Frank N. Furter", "Dr. Dolittle" but also "a b".
- String length range: Text input will be validated so that the entered text is no shorter than the supplied minimum length and no longer than the supplied maximum length. Minimum and maximum length can both be the same value, in which case the entered text must have exactly the given length. Any input that does not fall into the given length range is not accepted. The given minimum must be 1 or more, the given maximum must be 100 or less, and the maximum must not be less than the minimum. Note that for an optional field an empty input is also accepted.
- String length minimum: Text input will be validated so that the entered text is no shorter than the supplied minimum length. Any input that is less than this value is not accepted. The given minimum must be between 1 and 100 (including). Note that for an optional field an empty input is also accepted.
- String length maximum: Text input will be validated so that the entered text is no longer than the supplied maximum length. Any input that is greater than this value is not accepted. The given maximum must be between 1 and 100 (including). Note that for an optional field an empty input is also accepted.
For Number Fields:
- Accept all values: No validation will be applied, all number input is valid (in the range of -9223372036854775808 to 9223372036854775807, which is imposed by Maestro).
- Number range: Number input will be validated so that the entered number is not less than the supplied minimum and not greater than the supplied maximum. Any input that does not fall into the given range is not accepted. The given minimum must be less than the given maximum. Note that for an optional field an empty input is also accepted.
- Number minimum: Number input will be validated so that the entered number is not less than the supplied minimum. Any input that is less than the minimum is not accepted. Note that for an optional field an empty input is also accepted.
- Number maximum: Number input will be validated so that the entered number is not greater than the supplied maximum. Any input that is greater than the maximum is not accepted. Note that for an optional field an empty input is also accepted.
For Date Fields:
- Date with format: Input will be validated as a date (day,
month, and year) according to the date format specified. For the date format, four different
formats are available:
- yyyy-mm-dd: Year, followed by month, followed by day, separated by a hyphen.
- mm/dd/yyyy: Month, followed by day, followed by year, separated by a slash.
- dd/mm/yyyy: Day, followed by month, followed by year, separated by a slash.
- dd.mm.yyyy: Day, followed by month, followed by year, separated by a dot.
For a list group that already contains subscribers or lists, or for a list which already contains subscribers, then the input validation of already existing profile fields can no longer be changed. If a new field is added to such a list group or list (on the Profile Fields page), then the input validation for this new field can be defined, but the input validation of the other fields still cannot be changed.
Default Values
Each field that is listed here has a Define link. Click the link to define the default value for the given field. (For fields of the Single or Multiple Select type, before the default can be defined, a lookup table must first be assigned on the Selection Field Details tab.)
If the field is of the Multiple Select type (or "visible", which is a variation of Mandatory), then a default will have to be supplied before leaving the wizard. For optional fields (or "read-only" or "hidden", which are variations of Optional), a default doesn't need to be supplied.
Maestro uses default values for two purposes:
- Imported Data: When importing data from an external database or file