LISTSERV Maestro 11.1-2 Help Table Of Contents

Subscriber List Definition

  • To access the subscriber list definition wizard, open the subscriber list overview of the desired list. Then select Open List Definition from the menu (or go via the right-click menu of the list node in the subscriber warehouse tree).
  • To create a new standalone subscriber list, select New Subscriber List... from the menu (or go via the right-click menu of the Subscriber Lists node in the subscriber warehouse tree).
  • To create a new subscriber list in an existing list group, first select the desired list group node. Then select New In List Group Subscriber List... from the menu (or go via the right-click menu of the list group node in the subscriber warehouse tree).

The Subscriber List wizard lets you define the settings of a subscriber list or edit an existing list.

Note: A subscriber list is only fully editable while it is "empty", meaning that there are no subscribers on the list. For a non-empty list, only certain settings are editable.

For a Hybrid Subscriber List (which augments the features of a standard subscriber list with the advanced features of a LISTSERV list, covering advanced use cases such as email discussions groups), the wizard has eight pages:

General, List Type, List Options, Posting Restrictions, Topics, Profile Fields, Profile Field Details, and Summary

The top row of the wizard displays links to these 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).
Choice Description Customization Syntax
Max. Number of Rows Limits the maximum number of rows in the radio grid. Columns are added as necessary to be able to include all choices defined by the profile field.
Default: If there are more than four choices then the default is "3"; if less choices, the column/row count is chosen to create as "compact" a layout as possible. 		maxrows="[NUMBMER]"
Rows as Needed, Max Columns Limits the maximum number of columns in the radio grid. Rows are added as necessary to be able to include all choices defined by the profile field.
Default: If there are more than four choices then the default is "3"; if less choices, the column/row count is chosen to create as "compact" a layout as possible. 		maxcols="[NUMBMER]"
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.
Choice Description Customization Syntax
Same for All Defines that one CSS class shall be used for all rows in the table that surrounds the grid. rowstyleclass="[TEXT]"
Alternating Defines that two CSS classes shall be used alternatively for odd/even rows in the table that surrounds the grid. Two input fields appear:
Field Description Customization Syntax
Even Rows Defines the name of the CSS style class (or classes) that shall be assigned to every even row in the HTML table which surrounds the grid. evenrowstyleclass="[TEXT]"
Odd Rows Defines the name of the CSS style class (or classes) that shall be assigned to every odd row in the HTML table which surrounds the grid. oddrowstyleclass="[TEXT]"
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:
Choice Description Customization Syntax
Inside the Grid as First Value "No Selection" is the first radio button in the grid. defaultvalueposition="first"
Inside the Grid as Last Value "No Selection" is the last radio button in the grid. defaultvalueposition="last"
Separate Row Above "No Selection" is the first radio button in the grid and is rendered in a separate row on top of all other choices. defaultvalueposition="above"
Separate Row Below "No Selection" is the last radio button in the grid that is rendered in a separate row below all other choices. defaultvalueposition="below"
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.

Subscriber Name or LISTSERV List "Full Name" Definition

This tab only appears if there is at least one profile field of Text type defined (other than the EMAIL field of the list group) either in the profile fields of the subscriber list or in the shared profile fields of the group.

For a standard announcement list, the screen optionally allows you to define what value to use as the recipient name in the To field of all mailings to this subscriber list.

A Hybrid Subscriber List is backed by a LISTSERV list which commonly provides a Full Name (consisting of at least a first name and last name) for each subscriber. LISTSERV Maestro allows for following this good practice with the help of this tab, which optionally allows the definition of what value to use as the Full Name for this Hybrid Subscriber List.

The value that is to be used as the name can be a single Text type profile field (containing the recipient's name), or it can be a combination of several Text or Single Select type profile fields (but at least one Text field). If a combination of several fields is used, then they will be appended to each other in the given order with a separating space between each.

Example: If you have a FIRST_NAME field, a LAST_NAME field, and a single select Title field, then you might want to specify all three in the following order:

TITLE
FIRST_NAME
LAST_NAME

so that the correct full name, including the title, is assembled for each recipient.

Note: If several fields are appended to construct the full name, then they are separated by a space. However, if one of the fields is optional and there is no value provided, then no additional space will be inserted, so between two values in the full name, there will only ever be a single space (unless more spaces have been specified somewhere "inside" of a value).

To define a profile field to be included in the name definition, select it in the Profile Fields field (left selection box), then click the "->" button to move the field into the Full Name Fields field (right selection box). To again remove a profile field from the name definition, select it in the right box and click the "<-" button. To change the ordering of the profile fields in the right selection box, select a field in the box and then click the Move Up or Move Down link.

To aid with the selection of profile fields for the name, the table at the bottom of the tab shows details about all the profile fields.

If only a single text field is selected as the name field and it must be enforced that subscribers need to actually enter their full name (consisting of at least a first and a last name) into this field, then this is done in two steps:

  • First, select the given name field as the single name field on this tab here, as described above.

  • Second, on the Input Field Validation tab assign an input validation of type Full Name to the name field, as described in the following section.

Additional issues when importing a LISTSERV list into a Hybrid Subscriber List:

When importing a LISTSERV list, you have the option to also import the subscriber names from the original list into the Maestro Subscriber Warehouse. This option is only available if there exists at least one suitable profile field into which the subscriber names can be stored. If no suitable profile field exists, then the subscriber names are ignored during the import of the subscribers (and the full name definition tab is not available).

Therefore, if you plan to also import the subscriber names, you first have to create such a suitable profile field on the Profile Fields screen, so that the full name definition tab is available on the Profile Field Details screen. A suitable profile field is a field of the Text type, which is either optional, mandatory, or read-only.

If at least one suitable profile field is available, you then have two choices on the full name tab for how to handle the names of the subscribers that are already on the list:

  • Ignore subscriber names during the import: The subscriber names from the LISTSERV list (if any) are ignored. Only the subscriber addresses and their subscription options are transferred into the new Hybrid Subscriber List.

    Use this option if you have created any additional profile fields on the Profile Fields screen that are theoretically suitable to contain the subscriber names (which is why the system makes the full name tab available), but which you plan to use for other purposes, i.e. you are not interested in importing the subscriber names even though this would theoretically be possible with the profile fields you have created.

  • Store imported subscriber names in: The subscriber names from the LISTSERV list (if any) are also transferred into the new Hybrid Subscriber List and are stored in the specified profile field. To specify the profile field that will contain the subscriber names, select it from the drop-down menu. This menu contains all suitable fields. In this case, you may also want to define the special "Full Name" validation on this profile field (on the Input Validation tab of the same wizard page). This validation then makes sure that any new subscribers are required to enter a valid full name (see below). This is optional.

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.
    The input will only be accepted if the subscriber input can be interpreted as a valid date according to the chosen format. Note that for an optional field an empty input is also accepted.

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
© 2002-2023 L-Soft Sweden AB. All rights reserved.