Internal form processing

This section describes the way forms are processed.

Campaign personalization

The campaign personalization occurs at the time that an email is sent. This is the phase in which the form and clickthrough method invocations are executed.

At this stage, the fields are used by passing a string literal to the form and clickthrough methods, and the fields are evaluated for both their name and value.

Internal form processor

The internal form processor receives requests to display a form and works in one of the following ways:

  • The form parameters are all provided in the URL in the personalization template. In this mode, all data comes from the form link. In this case, the options to the form method can be omitted as {}, or usedb can be set as follows:

${form(‘formname‘, {‘usedb’:false}, parameter1, parameter2)}

The form parameters are all provided by accessing the user’s record when personalization occurs. The form processor does not need to retrieve any data as all the data is provided. This is the default, and is the faster of the two ways.

  • In other cases, the form method invocation should indicate that the form processor must retrieve all data from the recipient record. In this case, the form method cannot include any parameters. This is achieved by setting the usedb option in the form parameter as follows:

${form(‘formname‘, {‘usedb’:true})}

In this case, no additional parameters are allowed, as all data is retrieved from the personalization record inside the form processor.

Downtime form processor

When the system is down for maintenance, a downtime form processor displays a predefined response for the given form, or a page indicating that the system is down for maintenance.

Click processor

The click processor is different from the form processor in that it receives a link name instead of to a form name. It is managed in a more compact way by using internal identifiers. The click processor records a click to the given link, and redirects the request to the link’s destination URL, whether an internal form or an external link.

When the click processor receives a request, two things happen:

  1. A counter is incremented for the given link, and

  2. The link URL is obtained and a redirect is issued to the destination URL.

To properly redirect, the click processor might personalize the link with the data it received. For this reason, it is important to send all data that the link URL will require.

The click processor can only personalize three types of code:

  • Link URLs without personalization

  • Link URLs with a form method in which the parameters are the names of the fields sent by the clickthrough method

  • Field values of the form ${datasourcealias.fieldalias}

Downtime clickthrough processor

When the system is down for maintenance, the click processor still records that a click was performed for a given link, and attempts to redirect.

The redirection will succeed if the link URL has no replacements, or the link URL has field replacements of the ${datasourcealias.fieldalias} type.

When the Link URL contains embedded ${form(…)}replacements, the downtime click processor cannot redirect.

About form and clickthrough methods in campaigns

In Mobile SMS campaigns, the form and clickthrough methods return a temporary shortened version of the link. The shortened URL is valid fo a short period of time.

In email campaigns, these methods return a long URL.