A GT project gives rise to the exchange of many messages between the different stakeholders.

Some messages are related to publications (data collection and rendering); others are inherent to the functioning of the platform (account management, instance configuration, etc.)

Messages related to publications

The life cycle of a publication is punctuated by the sending of several types of messages. The sending of messages is activated in the templates, but the writing of messages is generally carried out in the launch actions, which allow the messages to be enriched with data from the publication.

Types of messages in a publication

There are 7 types of messages:

• Launch: issued when the launch action is executed
• First response: first response received for the entity (diffusion axis and additional validation axis).
• Subsequent responses: subsequent responses received for the entity (diffusion and additional validation axis)
• Rejection of response, closed campaign: a new response is received while the campaign is closed
• Rejection of response, questionnaire closed: a new response is received while the questionnaire is closed
• Relaunch
• Campaign closed

The launch, relaunch and closing messages of a campaign are sent following an action of the user manager (launch, relaunch or closing) or the automation.

The other messages are sent automatically by GTServer when a response to the questionnaire is received.

Recipients of the messages of a campaign

The recipients of the messages are designated as follows:

• The correspondent: email address to which the questionnaire has been sent. If the address has been redirected, it is the redirected address.
• The respondent: email address of the person who actually sent the response. This address corresponds to the user’s account (if he/she has an account and has sent his/her response in http) or to the email address that has been validated in GTAnswer.
• The correspondents: all the correspondents for an entity (including the additional validation axis).
• Respondents: all respondents for an entity (including additional validation axis)

The CC and BCC fields of the messages can be filled in automatically by the correspondents, the respondents or a combination of both. In the same way, the main recipient can be chosen among the respondent or the correspondent or both.

Messages sent automatically by GTServer: first response, subsequent responses, rejected response

For each new response received by GTServer, an email is sent depending on whether this response is the first for the entity or a corrective response (new response for the entity) or a rejected response due to a closed campaign or a closed questionnaire.

Field To can receive one of the following values:

• to the correspondent
• to the respondent if not to the correspondent (i.e. if the address validation is not used)
• to both

The CC and BCC fields can receive one of the following values:

• to the correspondents
• to the respondent otherwise to the correspondent
• to both

Notes:

• For the closed questionnaire message, the CC and BCC fields are not accessible.
• You can always put additional CC, BCC via the input box on the right (keywords are also allowed).

Messages sent by the manager or the automation: campaign launch, relaunch and campaign closure

Possible choices for the To field:

• • to each correspondent
  • to each respondent otherwise to each correspondent

• to both
• specific address (from version 3.7 for a reminder message)

Sending to a “Specific address” (available for a reminder message from version 3.7) allows you to specify an email address directly or through a variable (e.g. [[RootAxis1]]) which will be replaced by the value of this field for each entity reminded.

Possible choices for ‘CC and BCC :

• to the correspondents
• to the respondents otherwise to the correspondents
• to both

Use of variables in messages

Variables or keywords designating fields enclosed in double brackets can be used in the body and subject of messages, the CC and BCC fields of messages, or specific TO addresses for relaunch messages.

Generalities

Variables can be used in the messages (or in the names of files produced by qst or xls) to create “dynamic” messages or file names that will be different according to the recipients.

They are written as the field name enclosed in double brackets:

[[FieldName]]

The so-called “system” variables such as the sending date, the receiving date, etc… are proposed by GTServer

In general, variables (system or non-system) can be available in messages (“msg”: subject or body of the message) or the names of sent files (“file”: name of qst attachments or rendering files).

The availability also depends on the context: a date of reception variable cannot be used in a launch message.

Variables corresponding to components of the root of the questionnaire can be used with the hash prefix # (e.g. [[#FieldName]]); these variables will be substituted by the values returned by the correspondents (and not the values sent to the correspondents).

Access to variables when editing messages and file names is usually done by right-clicking in the GTAnswer editing dialog box (the # suffix will have to be added manually, however).

Variable Type	Source Data	Use Case
[[FieldName]]	Field present in the kernel of the launch action or Field present in the root of the questionnaire AND fed by a table associated with a compartment	– Subject and body of messages, direct recipients (To), CC and BCC of messages – File names for restitutions
[[#FieldName]]	Field present in the kernel of the launch action or Field present in the root of the questionnaire This variable is replaced by the value returned in the response (can be calculated by a formula in the questionnaire)	– Subject and body of messages, direct recipients (To), CC and BCC of messages Cannot be used for launch messages
[[System Variable]]	Generated by GTServer	– Subject and body of messages, direct recipients (To), CC and BCC of messages – File names for restitutions Some variables can only be used in certain messages (for instance, Answer’s Reception Date can’t be used in launch message)

Different copy recipients depending on the entities

The CC and BCC fields of the messages can refer to fields of the kernel or the root compartment, with the syntax [[FieldName]], but cannot refer to system variables.

This can be useful to associate different copy recipients depending on the entity: a field in the kernel or root will contain the copy recipients (separated by commas and not semicolons), this field will be used as a variable (in double brackets) in the CC or BCC field.

The copy recipient can even depend on the response sent in the questionnaire (use the prefix # in the variable).

Dates display

The dates/times can be generated in the time zone of the GTServer service account.

This option is enabled in the GTServer instance configuration (via GTAdmin)

List of system variables

Here is the list of variables provided by GTServer.

Variable	Description	Availability	Remarks
MODEL_NAME	Nom of the template	msg, file
MODEL_FILE	Template’s file name	msg, file
DATE_LAUNCH	Publication launch date/hour	msg	In the time zone specified in the instance
DATE_ANSWER	Answer submission date/hour	msg	In the time zone specified in the instance
DATE_RECEPTION	Answer reception date/hour	msg	In the time zone specified in the instance
DATE_REFUSED	Answer’s refusal date/hour	msg	In the time zone specified in the instance
DATE_ARRETE	Statement Date	msg, file	In the GTServer’s server locale
ANSWER_STATUS	Answer’s validation status	msg	In french, one of the following – En attente (Waiting) – Validée (Validated) – Invalidée (Invalidated) – Pas de réponse (No Answer)
PUBLISH_URL	Publication URL	msg	url allowing users to access documents via GTWeb. Required if “HTTP Check” option is set.
PUBLISH_SETUP (deprecated)	Answer Setup’s URL	msg	url to download the Answer update when GTWeb is installed and the Setup Answer.exe file is in the GTServer installation
VALID_COMMENT	Answer’s validation comment	msg
VALID_VALIDATOR	Validator Name	msg
VALID_TIME	Validation Date/Hour	msg	In the time zone specified in the instance
URL_INSTANCE_PARAMS	URL allowing to add instance parameters in GTAnswer	msg	/td>
URL_INSTANCE_ANSWER	Document URL	msg

Notifications

The notifications appear on the home page. They are also sent by email unless the user has asked to stop receiving them in the account settings.

Notifications on the home page

Notifications are linked to publications. They are sent to users who have at least a read right on the entity concerned. They respond to the following events:

• New publication
• New draft
• New response
• Validated response
• Invalidated response
• Publication closed

Notification messages cannot be edited.

Account creation message

The account creation message is a special case: it is not directly linked to a template or an entity and does not appear in the notifications. It is the message sent by an account creation action and must contain at least the information allowing the user to configure the instance in his client:

• The configuration link: variable [[URL_INSTANCE_PARAMS]]
• The user’s login : variable [[USER_LOGIN]]
• The temporary password, which the user has to change at first login: variable [[USER_PASSWORD]]

Was this article helpful?

0 out Of 5 Stars

5 Stars		0%
4 Stars		0%
3 Stars		0%
2 Stars		0%
1 Stars		0%

5 Submit

How can we improve this article?

How Can We Improve This Article?

Name

Email

Submit