LISTSERV Maestro 8.1-4 Help

 Forward >> << Back Table Of Contents

System Drop-Ins

A system drop-in acts very similarly to a normal user-defined drop-in in that the system drop-in place holder is replaced with specific content within the mail body just before the message is sent. The difference is that its name and content are not defined by the user. The name of the drop-in is pre-defined, and the content is determined by the system at delivery time, based on the logic within the drop-in.

System drop-in names all start with an asterisk "*". They need to be enclosed in the drop-in opening and closing tags just like normal drop-ins. Drop-in usage also needs to be enabled for the mail content, otherwise the system drop-ins are ignored and will not be replaced. This is the same behavior as normal drop-ins, if drop-ins were not enabled.

For readability purposes, you may write system drop-ins to extend over several lines. Any line breaks and additional whitespace (at locations without syntactical impact) are ignored, as long as the drop-in correctly starts and ends with the drop-in opening and closing tags.

The following sub-sections deal with the currently available system drop-ins:

Deprecated system drop-ins (these are provided for backwards compatibility with existing mail jobs. For new jobs, you should use the Formula Calculation system drop-in instead):

System Drop-In: "From:" Address

This system drop-in is always available.

The drop-in name is:

*FromAddress

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags (for example "{{*FromAddress}}").

It is replaced with the value that was entered into the Supply Sender Information: Email Address field on the Edit Sender Information page of the mail job and can thus be used to merge into the mail content the same address that will appear in the "From:" header of the email.

System Drop-In: "Reply-To:" Address

This system drop-in is always available.

The drop-in name is:

*ReplyToAddress

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags (for example "{{*ReplyToAddress}}").

It is replaced with the value that was entered into the optional Supply Sender Information: Reply-To Address field on the Edit Sender Information page of the mail job. If no value was supplied for this field, then the system drop-in will instead be replaced with the value of the Email Address field from the same page. So this system drop-in can be used to merge into the mail content the same address that will appear in the "Reply-To:" header of the email (if any), defaulting to the address of the "From:" header if no "Reply-To:" address was supplied.

System Drop-In: View in Browser URL

The drop-in name is:

*ViewInBrowserURL

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags (for example "{{*ViewInBrowserURL}}").

It is replaced with a http:// URL that points to a special page which displays the HTML part of the message, so that a recipient who for some reason can not view the HTML message in his mail client, can view it in a separate browser window instead.

In a HTML message which also contains a text alternative part, you can use this system drop-in both in the HTML part and in the text alternative: By including the system drop-in also in the text alternative, you will give those recipients which normally only view the text alternative, the option of using the URL to display the full HTML message in a separate browser window.

The special page will display the HTML message with the same personalized merge values of the recipient as the original email. These merge values are coded into the URL. Therefore, in a mailing with a very large number of merge values (per recipient) and/or values with a very long text, this mechanism of coding the merge values into the URL may not work correctly. Consequently, you should limit the usage of this system drop-in to mailings with a normal number of merge fields, where also the individual merge values are of a normal length.

The URL will have roughly the following format (with different individual values, depending on your LISTSERV Maestro installation and the mail job in question):

http://YOUR.SERVER/list/elex3jha/080102A/84c4b3.vib?...

Note: This system drop-in can not be used together with LISTSERV's conditional blocks (of the style .BB ... .EB), and also not together with the special LISTSERV merge placeholders that begin with an "*", of the type &*XYZ;. Except for &*TO;, &*URLENCODE(...); and &*INDEX;, which are allowed together with this system drop-in.

System Drop-In: Social Media Sharing Links

The drop-in name is:

*SocialMedia

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags (for example "{{*SocialMedia}}").

It is replaced with a list of links to various social media applications that allow the recipient to share the email content via these applications. The list of links will consist of text links, with the applications names, or icon links, if icons are configured. The exact composition of the list depends on which social media applications are enabled on the Social Media Settings page at the moment of delivery, and in which order, and if icons are defined at that moment or not.

If the "Forward-to-a-Friend" feature is enabled for the mail job, then the list of social media application icons will also include an icon for "forward via email". So if the *SocialMedia system drop-in is already included, then it is not necessary to also include the *ForwardToFriendURL system drop-in, for the "Forward-to-a-Friend" feature to work properly (see below).

Note: This system drop-in cannot be used together with LISTSERV's conditional blocks (of the style .BB ... .EB), and also not together with the special LISTSERV merge placeholders that begin with an "*", of the type &*XYZ;. Except for &*TO;, &*URLENCODE(...); and &*INDEX;, which are allowed together with this system drop-in.

System Drop-In: Forward-to-a-Friend URL

The drop-in name is:

*ForwardToFriendURL

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags (for example "{{*ForwardToFriendURL}}").

It is replaced with a http:// URL that points to a special page which allows the recipient to enter one or several email addresses to which he wants to forward the same email as the one in which he found the forward link. This allows your recipients to share the messages that they receive with other people.

Usage of this system drop-in requires the "Forward-to-a-Friend" feature to be enabled and configured for the mail job. It is not enough to only include this system drop-in in the content.

Note: This system drop-in can not be used together with LISTSERV's conditional blocks (of the style .BB ... .EB), and also not together with the special LISTSERV merge placeholders that begin with an "*", of the type &*XYZ;. Except for &*TO;, &*URLENCODE(...); and &*INDEX;, which are allowed together with this system drop-in.

System Drop-In: Personalized Contact Data

This is a group of system drop-ins that allow to you merge your predefined personalized contact data into the mail content, as defined via the menu option Utility -> Personalized Contact Data, Logo and Colors.

The drop-in names are:

*MyAddress
*MyColor
*MyEmail
*MyLegal
*MyPhone
*MyWebsiteURL

These names are case-sensitive and require this exact spelling as well as the correct drop-in enclosing tags (for example "{{*MyAddress}}").

Each of these system drop-ins is replaced with the corresponding value from your personalized contact data.

In addition, the *MyWebsiteURL system drop-in supports the following usage:

System Drop-In: List Name

This system drop-in is only available if the recipient type of the mail job is somehow based on a subscriber dataset or list (any of the following):

The drop-in name is:

*ListName

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags (for example "{{*ListName}}").

It is replaced with the name of the subscriber dataset or list that is used in the job's recipients (which is also the reason why this only works with the recipient types listed above).

System Drop-In: Login URL

This system drop-in is only available if the recipient type of the mail job is somehow based on a subscriber dataset or list (any of the following):

The drop-in name is:

*LoginURL

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags (for example "{{*LoginURL}}").

It is replaced with a http:// URL that points to the login page for the subscriber area of the subscriber dataset or list that is used for the job's recipients (which is also the reason why this only works with the recipient types listed above).

The URL will have roughly the following format:

http://YOUR.SERVER/list/login.html?...

System Drop-In: Subscribe URL

This system drop-in is only available if the recipient type of the mail job is somehow based on a subscriber dataset or list (any of the following):

The drop-in name is:

*SubscribeURL

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags (for example "{{*SubscribeURL}}").

It is replaced with a http:// URL that points to the subscribe page for the subscriber area of the dataset or list that is used in the job's recipients (which is also the reason why this only works with the recipient types listed above).

The URL will have roughly the following format:

http://YOUR.SERVER/list/subscribe.html?...

System Drop-In: Unsubscribe URL

This system drop-in is only available if the recipient type of the mail job is somehow based on a subscriber dataset or list (any of the following):

The drop-in name is:

*UnsubscribeURL

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags (for example "{{*UnsubscribeURL}}").

It is replaced with a http:// URL that points to the unsubscribe page for the subscriber area of the dataset or list that is used in the job's recipients (which is also the reason why this only works with the recipient types listed above).

The URL will have roughly the following format:

http://YOUR.SERVER/list/unsubscribe.html?...

System Drop-In: Profile Edit Page URL

This system drop-in is only available if the recipient type of the mail job is somehow based on a subscriber dataset or list (any of the following):

The drop-in name is:

*ProfileEditPageURL

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags. In addition, inside of the enclosing tags the drop-in name must be followed by a comma-separated list of field names, for example:

{{*ProfileEditPageURL field1,field2,field3}}

Each name in this list must refer to a profile field of the subscriber dataset or list that the recipients definition of the mail job is based on. The field names are case-insensitive.

The drop-in is replaced with a http:// URL that points to the external profile edit page of the subscriber area of the subscriber dataset or list that that the job's recipients are based on (which is also the reason why this only works with the recipient types listed above).

The content of this page (i.e. which fields appear on the page and which do not) is defined dynamically by the field list in the drop-in, so the page for the example above would contain only the fields FIELD1, FIELD2 and FIELD3, all other profile fields would be hidden. The email field or any fields that are hidden or read-only must not be included in the field list.

The URL will have roughly the following format:

http://YOUR.SERVER/list/editProfileExternally.html?...

System Drop-In: Job ID

The drop-in name is:

*JobID

This name is case-sensitive and requires this exact spelling as well as the correct drop-in enclosing tags.

It is replaced with the ID of the mail job in which the drop-in is used.

Formula Calculation

This system drop-in allows for the combining of merge fields from subscriber data with other merge fields, number-, text- or boolean-constants, sets of values or even predefined functions, into a formula that will then be calculated individually for each recipient to determine an individual drop-in replacement text for that recipient.

Example: A supermarket chain has a customer-card bonus-point system where customers are awarded points for every purchase. After collecting a certain number of points customers can swap points for bonus items, where the more interesting items require more points. If the recipient data contains a column "CURRENT_POINTS" that contains the currently collected points for each subscriber, normally only the value "&CURRENT_POINTS;" could be merged into the content, and then probably give a table of what bonus items are available for how many points. Now, with a calculation formula, more dynamic content can be merged like "You currently have X many points, which means that you only need Y points more to get the free widget or only Z points more to get the free trinket!".

The "name" of this drop-in is a directive with the following syntax:

*Calc FORMULA

The directive is case-sensitive and requires this exact syntax as well as the correct drop-in enclosing tags.

It is replaced with the result of the formula. If the formula contains merge-fields, this result will be calculated individually for each recipient and may therefore differ from recipient to recipient.

See here for a detailed description of formulas and their rules.

Important: A formula that is used in a *Calc system drop-in must return a result of type Number or Text (it must not return a result of type Boolean, Text Set or Number Set). Also, in case of a return value of type Text, this text must not exceed 900 characters.
If the formula returns a wrong type or a text that is longer than 900 characters, then this will cause a delivery error of the mail job.

Example:

It is beyond the scope of this page to give all the possible examples for which formulas can be used. Here is just one simple example where a merge-field value (a number) is used in subtraction formulas with constant numbers to calculate the replacement values.

It should be noted, though, that formulas offer many more features, for example all the standard operators like +, -, *, / and % (modulo), which can be used in any combination and even be nested with parenthesis. Formulas can also work on text strings and there are a number of pre-defined functions, such as Abs, Min, Max, Random, Substring, etc.

Looking back to the example given above, with the supermarket bonus-points, assume that the number of required points for "widget" is 300 and the number of required points for "trinket" is 500. Depending on the value of "CURRENT_POINTS" there are four groups of customers:

In combination with LISTSERV's conditional blocks, the following personalized content can be created (indentations for readability only):

	.BB (&CURRENT_POINTS >= 800)
	.* Content for recipients eligible for both goodies

	Wow! You have already collected &CURRENT_POINTS; points!
	This means you are already eligible to get both Widget and
	Trinket! Get them while they are hot!
	After getting your goodies, you'll still have
	{{*Calc &CURRENT_POINTS; - 800}} points left!

	.ELSE
	.BB (&CURRENT_POINTS; >= 500)
	.* Content for recipients eligible for widget or trinket

	Congratulations! With your &CURRENT_POINTS; collected points
	you are eligible to get either widget (after which you will have
	{{*Calc &CURRENT_POINTS; - 300}} points left) or trinket
	(which will leave you with {{*Calc &CURRENT_POINTS; - 500}}
	points).

	.ELSE
	.BB (&CURRENT_POINTS; >= 300)
	.* Content for recipients eligible for widget only

	You are on track! For your &CURRENT_POINTS; you can already
	get Widget (which will leave you {{*Calc &CURRENT_POINTS; - 300}}
	points or you can collect {{*Calc 500 - &CURRENT_POINTS;}} more
	points to get Trinket!

	.ELSE
	.* Content for recipients eligible for no goodies yet

	Keep going! You already have &CURRENT_POINTS; collected!
	Only another {{*Calc 300 - &CURRENT_POINTS;}} points to go and
	you can get your own free Widget!
	Or {{*Calc 500 - CURRENT_POINTS;}} more points and you can
	get the free Trinket!!!

	.EB
	.EB
	.EB

Check if User Drop-In Has Content

This system drop-in allows you to check if a given user drop-in actually has a non-empty content or not. The system drop-in itself will always be replaced either by the text "true" or "false" (without the quotes), depending on if the referenced user drop-in has a non-empty content or not.
A non-empty content is a content with at least one non-whitespace character in it. I.e. all content which is either totally empty or which contains only whitespace characters (like space, tab, linebreaks, etc.) is interpreted as empty.

This system drop-in is usually used in a conditional block where its result (which is always either "true" or "false") is used in the condition to decide if a conditional block shall be included in the mail or not. That way, it is for example possible to include a certain block only if a given user-drop is actually non-empty, or the other way round, include a certain block only if the user drop-in is empty.

The "name" of this drop-in is a directive with the following syntax:

*HasContent(NAME)

Where you replace "NAME" with the name of the user drop-in to check (do not specify the name of another system drop-in). The directive is case-sensitive and requires this exact syntax as well as the correct spelling of the user drop-in name and the correct drop-in enclosing tags.

Examples:

Assume that you have an auto-repeat job with a user drop-in called "DailyQuote" that pulls its content from a file. The job is sent on a daily basis and the content of the drop-in file is also updated daily, so that each day there is a different quote included. Only on some days there is actually no content at all for this drop-in. Now assume that in the part of the mail where this drop-in is included, there is also some short intro-text, which is however only supposed to appear if the user drop-in is actually not empty. Also if the user drop-in is empty, a suitable replacement text should appear instead. For this a conditional block with the *HasContent system drop-in can be used (indentations for readability only):

	.BB {{*HasContent(DailyQuote)}} = true
	.* Included only if the "DailyQuote" user drop-in has content
	Here comes the daily quote:
	{{DailyQuote}}
	.ELSE
	.* Included if the "DailyQuote" user drop-in is empty
	Sorry, but we do not have a quote for you today.
	.EB

Assume that you have a job with a user drop-in called "Sample" that is included at some location in the mail job, where the drop-in also sometimes is empty. In case that it is empty, there is supposed to appear a certain alert text at another location in the same mail job. For this too a conditional block with the *HasContent system drop-in can be used (indentations for readability only):

	.BB {{*HasContent(Sample)}} = false
	.* Included only if the "Sample" user drop-in is empty
	Warning: The sample drop-in was empty!
	.EB

System Drop-in: Multiple Selection Fields

This system drop-in has been deprecated. It is still provided, but only for backwards compatibility with existing mail jobs.
Please use instead the Formula Calculation system drop-in {{*Calc}}, with the "Count" and "SetToStringWithMaxLen" functions, as well as the "=", "<>", "<", "<=", ">" and ">=" set comparison operators.

This system drop-in is only available if the recipient type of the mail job is a target group of the type "Based on Subscriber Dataset" or "Based on Subscriber List".

This system drop-in allows you access to the values of a multiple selection profile field of such a subscriber dataset or list. Since only datasets and lists of this type may contain multiple selection fields, this is also the reason why this system drop-in only works with recipients of the described type.

Normally, multiple selection fields cannot be used for mail-merging. For example, if you have defined a field called "HOBBIES" that is of the type "multiple select" and that allows the subscribers to select one or several hobbies, then you can not include &HOBBIES; in your mail text because normal mail-merge can only deal with single-value fields and would simply not know how to merge in the possible multiple selections from this field.

Instead, this system drop-in has been introduced to allow you to merge the information from a multiple selection field into your mail text.

The syntax of this drop-in starts with *Multi followed by specific descriptive text depending on the operation. There are three different versions, each giving you access to the multiple fields in different ways and are explained in the following sub-sections:

Multiple Selection Field Count

This system drop-in has been deprecated. It is still provided, but only for backwards compatibility with existing mail jobs.
Please use instead the Formula Calculation system drop-in {{*Calc}}, with the "Count" function.

The "name" of this version of the drop-in is a directive with the following syntax:

*Multi FIELD_NAME count

The directive is case-sensitive and requires this exact syntax as well as the correct drop-in enclosing tags.

Replace "FIELD_NAME" with the name of the multiple selection field you want to address.

It is replaced by the number of selections that each subscriber has made from the available choices of the profile field with the name "FIELD_NAME".

Example:

{{*Multi HOBBIES count}}

For a subscriber who has selected five different hobbies from the list of available hobbies, the drop-in is replaced with the value:

5

For a subscriber who has not selected any of the available hobbies, the drop-in is replaced with the value:

0

Multiple Selection Field Enumerated

This system drop-in has been deprecated. It is still provided, but only for backwards compatibility with existing mail jobs.
Please use instead the Formula Calculation system drop-in {{*Calc}}, with the "SetToStringWithMaxLen" function.

The "name" of this version of the drop-in is a directive with the following syntax:

*Multi FIELD_NAME separated by "SEPARATOR"

The directive is case-sensitive and requires this exact syntax as well as the correct drop-in enclosing tags.

In addition, further optional parameters may be appended to customize the behavior of the directive. See below for details.

The drop-in is replaced by a textual enumeration of the selections that each subscriber has made from the available choices of the profile field with the name "FIELD_NAME", where the different enumerated choices are separated with the given "SEPARATOR" string.

Additional optional parameters available:

Note: If you want to use both the "default" and the "more" optional parameter, you must use them in this order, first "default", then "more".

Examples:

Assume a subscriber who has selected the hobbies "Cycling", "Poker", "Windsurfing", "Bird Watching", "Web-Browsing" and "Swimming".

The drop-in

{{*Multi HOBBIES separated by ","}}

is replaced with

Cycling,Poker,Windsurfing,Bird Watching,Web-Browsing,Swimming

Note that there is no space after the comma separator, since none was included in the separator string of the directive. If instead the drop-in is specified as follows (note the space after the comma):

{{*Multi HOBBIES separated by ", "}}

then it is replaced with the much nicer looking

Cycling, Poker, Windsurfing, Bird Watching, Web-Browsing, Swimming

For the sake of this example, assume the above string is too long for the 800 characters threshold, and is overstepped by "Bird Watching", the replacement would then be abbreviated with the standard ellipsis token, like this:

Cycling, Poker, Windsurfing, ...

If that isn't suitable, a custom ellipsis token can be specified:

{{*Multi HOBBIES separated by ", " more "and others..."}}

which would be replaced as follows:

Cycling, Poker, Windsurfing, and others...

Or, to give even more information, this could be specified:

{{*Multi HOBBIES separated by ", " more "and #COUNT more"}}

which would be replaced with:

Cycling, Poker, Windsurfing, and 3 more

since for the example subscriber there were 3 hobbies ("Bird Watching", "Web-Browsing" and "Swimming") omitted from the enumeration.

Now, assume a subscriber who has not selected any hobbies. The drop-in

{{*Multi HOBBIES separated by ", "}}

will then be replaced with:

 

It's replaced with nothing (or an empty string).

If instead something needs to be displayed for this type of subscriber, the directive as can be specified as follows:

{{*Multi HOBBIES separated by ", " default "<no hobby selected>"}}

which is replaced with:

<no hobby selected>

This would only apply to all subscribers who actually do not have any of the hobbies selected - for all others the drop-in would still be replaced with the enumerated list, as described above.

To combine these examples, assume the situation where it's expected that some subscribers have selected no values at all, some have selected a few values and some have selected a lot of values that could possibly result in an enumeration that is too long. The drop-in can be specified as follows:

{{*Multi HOBBIES separated by ", " default "<no hobby selected>" more "and #COUNT more"}}

remembering that if both "default" and "more" are supplied, "default" must come first and "more" second.

The result would then be a combination of what has already been explained above. For subscribers with only a few selected values, the correct comma (and space) separated list is used for the replacement, for example:

Cycling, Poker, Swimming

For subscribers with "too many" values, the abbreviated list with the customized ellipsis text is used for the replacement, for example:

Cycling, Poker, Windsurfing, and 3 more

And for subscribers without any selection the customized default text is used for the replacement:

<no hobby selected>
Multiple Selection Field Advanced Set-Operators

This system drop-in has been deprecated. It is still provided, but only for backwards compatibility with existing mail jobs.
Please use instead the Formula Calculation system drop-in with the "=", "<>", "<", "<=", ">" and ">=" set comparison operators (or use the function "Count(&FIELD;)=0" to check for the empty set).

The variants "*Multi NAME count" and "*Multi NAME separated by" of the multiple selection field system drop-in offer access to the number of selected choices and allow all of them to be displayed in an enumerated list. However, what if content needs to be displayed depending on the choices the subscriber made, without displaying the choices themselves? For that case, the advanced "Set-Operators" that are described in this sub-section have been created.

These set operators are not trivial to use, but they are very powerful and allow for a lot of creative mail-merging and conditional content creation. Before leading into the rather "dry" description of this drop-in, first here are descriptions of a few scenarios that are possible with this system drop-in:

Scenario: "For all subscribers who have among their selected hobbies any of the following: [hobby list here] show a certain 'special-feature' text about those hobbies."

Scenario: "For all subscribers who have among their selected hobbies the hobby "Rock Climbing", include an advertisement about Yosemite N.P. but do not include anything special for all other subscribers."

Here is some background that needs to be covered first:

The set operators are based on the mathematical concept of a "set". A "set" contains one or more elements (or can even be an empty set) and two "sets" can be compared in various ways to answer questions like:

For the purpose of a multiple selection field, the two sets that are present are the following ones:

With these two sets given, LISTSERV Maestro then offers four different set-operators, to compare these two sets. The four available operators are:

Now that the origin of the two sets has been discussed, and what operators are available to compare them, the question is: How does this help in the context of the "*Multi" system drop-in?

The answer lies in the four available operators. They are all of the "check" type, meaning that they all yield a result that is either "true" or "false".

In the context of the system drop-in, advantage is taken of this to use the operators to compare the two sets and then replace the drop-in with a certain text, depending on the result of the comparison. If the result is "true", the drop-in is replaced with customized "true"-text; if the result is "false", the drop-in is replaced with a different customized "false"-text instead.

This way, the drop-in can be used for some very powerful replacements, which will be illustrated with examples further below. First, here is how the drop-in is actually written:

The "name" of this version of the drop-in is a directive with the following syntax:

*Multi [not] FIELD_NAME OP COMPARE_SET ? "TRUE_TEXT" : "FALSE_TEXT"

The directive is case-sensitive and requires this exact syntax as well as the correct drop-in enclosing tags. Note: the square brackets around the word "not" are not actually part of the syntax but are used to denoted that the word "not" itself is optional. It can either be included (without brackets) or just left out altogether.

Checking for "Empty Sets"

Even though it is not possible to specify an empty set as the compare set, the selections a subscriber has made for a certain multiple value field can still be checked to see if it is empty (nothing selected) or not.

This can be done with the "is empty" operator, which looks like this:

*Multi [not] FIELD_NAME is empty ? "TRUE_TEXT" : "FALSE_TEXT"

If this special "empty set" operator is used, then the system drop-in is replaced with the "TRUE_TEXT" for all subscribers who have not selected any choice for the given multiple selection field, and the "FALSE_TEXT" will be used for all subscribers who have at least one choice (any choice) selected. (Or the other way round if the optional "not" qualifier is also included).

Note: Even though mathematically the "empty set" is always a subset of every other conceivable set, with regards to the "subset" operator in LISTSERV Maestro this is not so. In LISTSERV Maestro, if a subscriber has not selected any choices (the first set = the "empty set") then the subset operator will always yield "false".

Examples:

The following describe a few scenarios which could arise in "real life" and explain how they map onto the set operators, and then show the system drop-in for that scenario.

Scenario: "If the subscriber has selected exactly the hobbies 'Swimming', 'Cycling' and 'Poker' (and no others), use one text for replacement, if not, use a different text".

This is a check of the type "equality". If the set of hobbies selected by the subscriber (=first set) is equal to the set that contains the hobbies "Swimming", "Cycling" and "Poker" (=second set), the check will be "true", otherwise it will be "false". The corresponding drop-in looks like this:

	{{*Multi HOBBIES = "Swimming", "Cycling", "Poker" ?
	"Use this for subscribers with exactly the given hobbies" :
	"Use this for all other subscribers"}}

Scenario: "If the subscriber has selected only hobbies from the list 'Swimming', 'Cycling' and 'Poker' (not necessarily all of them, but no others), use one text for replacement, if not, use a different text".

This is a check of the type "subset": If the set of hobbies selected by the subscriber (=first set) is a subset of the set that contains the hobbies "Swimming", "Cycling" and "Poker" (=second set), the check will be "true", otherwise it will be "false". The corresponding drop-in looks like this:

	{{*Multi HOBBIES <= "Swimming", "Cycling", "Poker" ?
	"Use this for subscribers with only the given hobbies" :
	"Use this for all other subscribers"}}

Scenario: "If the subscriber has selected at least the hobby 'Swimming' (and probably additional hobbies), use one text for replacement, if not, use a different text".

This is a check of the type "superset": If the set of hobbies selected by the subscriber (=first set) is a superset of the set that contains only the hobby "Swimming" (=second set), the check will be "true", otherwise it will be "false". The corresponding drop-in looks like this:

	{{*Multi HOBBIES >= "Swimming" ?
	"Use this for subscribers with at least the given hobby" :
	"Use this for all other subscribers"}}

Scenario: "If the subscriber has selected any of the hobbies from the list 'Swimming', 'Cycling' and 'Poker' (not necessarily all of them, and probably others), use one text for replacement, if not, use a different text".

This is a check of the type "intersection". If the set of hobbies selected by the subscriber (=first set) intersects with the set that contains the hobbies "Swimming", "Cycling" and "Poker" (=second set), the check will be "true", otherwise it will be "false". The corresponding drop-in looks like this:

	{{*Multi HOBBIES & "Swimming", "Cycling", "Poker" ?
	"Use this for subscribers with any of the given hobbies" :
	"Use this for all other subscribers"}}

Scenario: "For all subscribers who have not selected any of the choices from the list of hobbies use one text for replacement. For all subscribers who have selected at least one hobby use a different text".

This is a check with the special "is empty" operator: The corresponding drop-in looks like this:

	{{*Multi HOBBIES is empty ?
	"Use this for subscribers without any hobby selected" :
	"Use this for all subscribers with at least one hobby"}}

Combination with Conditional Blocks

The special set-operator system drop-in described here is especially useful when used in combination with LISTSERV's conditional blocks.

For the "raw" drop-in, one text must always be supplied to be used as a replacement for subscribers who fulfill the condition and also one text to be used as a replacement for all other subscribers.

But there are also possible scenarios like: "If the subscriber has 'Diving' among their hobbies, include an advertisement for the newest scuba gear. If not, then don't include anything at all."

Or there can be scenarios where the text to be included in the "true" or "false" case is rather involved (for example, several paragraphs of text). This is usually not possible in the drop-in itself.

For those scenarios, a combination with conditional blocks is the right solution. The advantage here is that system drop-ins is replaced before the content is evaluated for conditional blocks. The result of a system drop-in replacement can then be incorporated into a LISTSERV condition.

In the system drop-in, just specify two very simple values to be returned in the "true" and "false" cases, for example "1" and "0", then use a LISTSERV condition to check for either of these values, and conditionally include the desired content or not.

Examples:

Scenario: "If the subscriber has 'Diving' among their hobbies, include an advertisement for the newest scuba gear. If not, then don't include anything at all." can be written as:

	.BB ("true" = "{{*Multi HOBBIES >= "Diving" ? "true" : "false"}}")
	The advertisement text for the
	Scuba gear goes here...
	.EB

Scenario: "If the subscriber has selected any of the hobbies that appear in this week's specials (which are "Cycling", "Poker" and "Diving"), then include some HTML-paragraphs of text telling them about the particular special. If not, include some other HTML-paragraphs of general text." can be written as:

	.BB (1 = {{*Multi HOBBIES & "Cycling", "Poker", "Diving" ? "1" : "0"}})
	<h1>Weekly Hobbies Special</h1>

	<p>Did you know that our current Weekly Hobbies Special covers
		some of the hobbies you are interested in?</p>

	<p>Check it out at...</p>
	etc...
	.ELSE
	<h1>General Text</h1>

	<p>General text goes here...</p>
	etc...
	.EB
© 2002-2017 L-Soft Sweden AB. All rights reserved.