How can we help?
Search for answers or browse our knowledge base
Informal collection workflows
By their very nature, the collection processes via Excel workbooks are not fixed: the people who enter, validate and transmit data, as well as the data circuits between these people, are generally not formally defined. The respondents are not necessarily centrally known (and the maintenance of a central address book is not necessarily desirable), and the flows are not even necessarily homogeneous between the entities surveyed.
When migrating to the Gathering Tools suite, some of the informal aspects of Excel collection can be preserved. Some of these aspects are described in this article.
Diffusion and Collection: Overviews
Input Delegation
When a response is entered into a GT questionnaire, it can be saved to be completed later, or the qstx file can be forwarded (by email or other file transfer means – file sharing, etc.) to another person who can also complete the response or even forward the response.
By using GTAnswer’s email address validation, it is possible to obtain the email addresses of the people who actually transmitted the response rather than just the email addresses of the correspondents, the initial recipients of the questionnaires.
Diffusion axes
The diffusion axes of the questionnaires have three main functions
- Cutting out the data when it is sent
- Convenience of viewing by manager, with additional validation axes.
- Integration comfort (last response per entity), with additional validation axes.
Diffusion axes and additional validation axes
The questionnaires are sent via diffusion axes that allow the entities to be determined. This distribution method may not be sufficient to describe the respondent population:
The persons actually entering the responses are not the persons to whom the initial questionnaire is sent. The entities issuing a response may not be centrally known in advance.
In the case where one person is the only contact for the collection of many entities, sending a reduced number of questionnaires may be appropriate.
Additional validation axes: Determination of response entities by the respondent
The use of additional validation axes allows responses (and follow-up of these responses) to be obtained at a finer level than the entities addressed directly by mail with GTServer.
By using one or more additional validation axes (corresponding to one or more components in the questionnaire), the responses in GTClient will be automatically separated according to the return values of this field: the response entities are determined by the respondent. Corrective responses (new response for an entity of an additional validation axis) will be handled automatically when viewing responses and when integrating.
Caution: the additional validation axes can be entered directly or by formula, but in all cases they must return string data (the TFMT flag must be used when the input component is created or the formula must return a string).
The cutting of the data by the additional validation axis should not lead to any intersection of the input perimeters (see Partial Responses). For example, if one respondent answered for the Production and HR departments in the same questionnaire and the other for the Trade and HR departments.
The breakdown of the data by the additional validation axis remains global to the questionnaire (no different levels according to patterns, transpositions or multi-tabs)
In GTAnswer, the visualisation of campaigns with additional validation axes introduces a subtlety: the monitoring graph no longer includes the indicator of the number of pending entities. As entities are created dynamically, it is not possible to determine the total number of entities in advance. This also implies that the answers will never be in the discussion thread of the initial questionnaire: indeed, the validation axes cannot receive an empty value. A new thread will therefore be created for each new entity, and the launch message will be copied into it.
Visualisation axes
The visualisation axes are chosen in the root of the questionnaire at the design of the launch action and make it possible to see the values of the axes/visualisation fields entered or calculated in the questionnaire during the follow-up of the responses without modifying the definition of the entities (defined by the additional diffusion and validation axes).
The most frequent uses correspond to :
- a pre-visualisation of certain results of the questionnaire without having to open it
- a visualisation of an entity status in the framework of an informal workflow (the switch to a different status is made by the formulas or the input in the questionnaire)
Examples
Example 1: the entities are not centrally known
A questionnaire is sent to agencies and addressed to the departments of these agencies. The departments and persons who have to fill in the responses for these departments are not known precisely.
A questionnaire can be sent to a correspondent for each agency, who can then list the agency’s services (in a pattern for example) and transfer the questionnaire to a person in each of the services. These people can then choose the service that concerns them and transmit the response to GTServer via GTAnswer.
It is possible to restrict the service choices for a given respondent.
In GTAnswer, the answers are differentiated per agency and per department.
Example 2: Personal data questionnaire
The gtvalidmailaddress() function can be used to identify respondents’ email addresses (or user accounts). This function can be placed in a GT control (via the gtcontrol declaration function in Excel when importing into Design).
It can also be specified as a value for one of the additional validation axes or a visualisation axis.
Responses in the thread will then be automatically visualised (and/or validated) by collected email addresses. A respondent can always provide corrective responses.
Example 3: Reduction of the number of questionnaires sent
You want to collect information by branches and units (both of which can be known at the time of the campaign launch). The questionnaires are sent to one person per branch, who then transfers the questionnaires to each unit.
However, some branches have more than 20 units. In order not to overload the mailbox of the initial correspondent for the subsidiary, it may be appropriate to send a questionnaire for the subsidiary concerned with an additional validation axis, which is the unit.
The initial correspondent will only have to forward the single email received to each of the people in charge of the response for each unit.
Compared to sending as many questionnaires as there are subsidiaries and units, this method of distribution and collection is a little more complex to implement if the questionnaire is pre-filled (the data included in the questionnaire concerns the entire subsidiary, whereas the data to be presented for each unit will generally be restricted to the unit).
Example 4: Alert questionnaire
The aim is to collect the various alerts, remarks and suggestions made by the company’s employees. A single entity (the company) is created and a single questionnaire is sent. The questionnaire can be stored in a file share (network share, web share, etc.). An additional validation axis is created by using a free text component in the questionnaire designating the subject of the remark.
A person wishing to issue an alert opens the questionnaire, enters a subject and transmits the response. This person can issue a corrective response for the same subject by entering the same wording in the subject component.
If email validation is requested, the sender of the remark can be identified; otherwise, the responses will be anonymous.
If we do not want the alerts to be differentiated by subject, we can also use the date of transmission of the response as an additional validation axis: this date will be a control in the questionnaire containing the formula =Now() to be converted into text since it is an additional validation axis, therefore, rather in a form similar to =Year(Now())&”-“&Month(Now())&”-“&Day(Now()).
A second additional validation axis involving a component containing the gtvalidmailadress() function may also be specified to differentiate responses by individual sender.
A visualisation axis (GT>=3.7) may indicate a status or validation state of the response.
Example 5: Visualisation of responses over time: intermediate responses
We wish to centrally display the progress of the response as it is being made (without the responses being considered as final).
A component specifying whether the response is an intermediate response or not (checkbox type) allows the response to be centrally sent without all the constraints being checked on the questionnaire. This component is used as an additional validation axis (via a formula calculating a string from the check box).
As long as the correspondent does not consider the answer as complete, the box is ticked, the answer can be transmitted and the information can be viewed/tracked in GTAnswer.
Once the response is finalised, the box is unchecked and the response must check all constraints to be transmitted. The two sets of intermediate and final responses are clearly differentiated in GTAnswer.
This operation can be extended to several levels of intermediate responses, allowing the tracking of individual responses.
Partial responses and response circuits
Partial responses
Partial responses are cases where the response sent by the user only fills in some of the fields/rows ( patterns) of the final response, without a final general response with all the filled-in fields/rows being actually sent with GTAnswer.
Partial responses are possible, simply use all responses during integration (first panel of the integration action), then make a selection according to more detailed criteria if necessary.
Allowing partial responses is generally not recommended, as it implies, among other things
- not having an overall view of the response for a given central entity (except after the integration). This implies a difficulty in managing corrective responses
- not being able to carry out all the consistency checks at response level
Corrective responses and partial responses
Corrective responses can be implemented if an explicit or implicit subdivision of the questionnaire data is made.
For example, a questionnaire listing all the products sold in a month by an entity without distinguishing between these different sales will not allow the correction of information provided in previous transmissions for the same campaign.
On the other hand, if an order number is specified, it can be used as an update key (deletions can be made by a checkbox per order specifying that it should be deleted). The central display of the general response will remain problematic as long as the responses are not integrated (to bring into play the rules of precedence by date and by order number).
In all cases, general constraints cannot be applied in the questionnaire at the time of entry.
“Partial” response using an additional validation axis
When a certain discipline (or constraints defined in the questionnaire) isolate the scopes of entry of each of the sub-respondents for an entity, an additional validation axis can be constructed by identifying the scope of entry (this could be a set of units by concatenating the combination of units for example). The responses are not really partial: the perimeters of capture specified for the addressed entity define “sub-entities”.
Response circuits
Partial responses are difficult to manage and are generally not recommended.
By using the questionnaire alone and without allowing partial responses, it is not possible to have a star-shaped input/response circuit where each respondent sends the completed questionnaire for the part that concerns him or her to the person responsible for transmitting the response. It is not possible to consolidate data from several documents with GTAnswer.
If the data of a questionnaire has to be entered by several people, there are different possibilities:
- Excel input matrix for a star or cycle response scheme
- Discipline in the framework of a response cycle
- Adaptation of the questionnaire to the user within a response cycle
Excel input matrices in a star response scheme
Each respondent uses an Excel input matrix (an Excel workbook prepared to import data into the qst) to enter data and sends this matrix to the person responsible for responding with GTAnswer.
When the data entered by each person is limited to a set of compartments (patterns, multi-tabs and transpositions) for which he/she is the only one to provide this information, the consolidation of the Excel input matrices will be done simply by successively importing these different matrices into the questionnaire.
In effect, several Excel input matrices can be used to import the data into GTAnswer directly, provided that the field names for import declared in each input matrix exist only in that input matrix. The Excel field names can also be calculated according to the data entered and return an error value (e.g., #ref!) to tell GTAnswer that this field is not to be imported. See Import multiple input matrices.zip.
Excel input matrices cannot be used to import data within multi-tabs of the questionnaire.
Several Excel input matrices cannot supply the same questionnaire pattern. When importing into a pattern, all existing data in the pattern is first deleted before importing new data from Excel.
However, several patterns with the same structure can be created to import one data entry matrix data (see Import multiple data entry matrices.zip).
The person answering the questionnaire can also consolidate the Excel input matrices by collecting the data in Excel, possibly manually. This solution is generally not recommended because of its unreliability and/or maintenance costs: consolidations must be done manually, automations with Excel macros pose maintenance concerns.
Disciplined cyclical response circuit
The principal correspondent receives the questionnaire and can then pass it on to the first data entry person, who completes it and passes it on to the second, and so on until it returns to the principal correspondent.
However, all correspondents can modify all the information in the questionnaire and centrally transmit the response at any time. The use of locks and constraints in the questionnaire (see next paragraph) is an interesting alternative.
Adapting the questionnaire to the user in the framework of informal exchanges
In the framework of exchanges of the questionnaire(s) within the entity being surveyed, it is possible to modify the functioning of the questionnaire according to the user by applying locks, constraints, etc., to either or not authorise access to certain data, to either or not authorise the transmission of the response by the user, etc.
The application frameworks are varied: local validation with or without additional axes, disciplined response circuit, etc.
What can be controlled in the questionnaire based the validated email address?
- Who enters which components of the questionnaire?
- Who validates?
- Who transmits the response?
- What are the delegations for input and transmission?
- What is the mechanism for changing the status of the response?
The implementation is based on the use of email address lists designating the persons authorised to carry out such and such an operation in the questionnaire. If the email address returned by gtvalidmailadress() is not part of the list of email addresses authorised to perform such and such an operation, components can be locked or calame constraints can be activated.
These authorization lists can be supplied centrally (when the questionnaire is launched) or even completed by the entity’s main correspondent when the questionnaire is received (during integration, these completed lists can be reused for the next campaign, which makes it possible to delegate rights management to the main correspondent).
Locks (gtlock) will prevent certain people from modifying the values of certain components.
Calame constraints (gtconstraint) can prevent certain users from filling in inconsistent sets or from transmitting the response (if the user cannot transmit the response).
Formulas will be able to modify a response status, which can be viewed directly with the visualisation axes.
By using the recipient overload for the relaunch and the keywords between double brackets in the messages, the manager can send the questionnaire with the last answer to all the people who have to modify the data for the next status.
What can’t be controlled dynamically in the questionnaire?
- The addition and deletion of rows in a pattern (a transposition can be used to simulate the pattern).
- Opening the questionnaire
- Viewing the values of specific components (although white-on-white formatting is possible, selecting the cell in the document will allow the data to be viewed).
- Forcing people to answer or to pass the questionnaire to the right person at the right time. No IT tool can force a person to perform an action yet (and this is probably a good thing…).
Example 1: Questionnaires with local validation
The initial correspondent for the entity receives the questionnaire.
If this person is the person to validate, he/she passes the questionnaire to the person to enter. The latter can fill in the data in the questionnaire but cannot transmit the response: a Calame constraint prevents the response from being transmitted if the user’s email address is not on the list of email addresses authorised to transmit the response (this list is centrally defined and filled in when the campaign is launched). The user must send the questionnaire to the validator (initial correspondent), who can then send the response.
The operation can be extended to several levels of validation provided that the choice of validation level (level 1, level 2, etc.) is limited to the persons concerned, that the users pass on the questionnaire containing the last response to, and coordinate with each other (in the same way as they would do with an Excel workbook undergoing different levels of validation).
If the initial correspondent is the data entry person, he/she fills in the questionnaire, but cannot send the response and, therefore, sends the questionnaire by email to the person who has to validate (and who can send the response).
It is also possible to use drafts for this type of flow.
Example 2: Delegation on additional validation axes
The questionnaire is sent to the main correspondent of the entity; each entity includes a list of sub-entities, the sub-entities for the response is chosen via a drop-down list. The list of sub-entities for each entity can be defined centrally or by the main correspondent.
The main correspondent defines the persons authorised to fill in the data for each entity by listing the email addresses for each sub-entity. He/she can then transmit the questionnaire to the persons in charge of data entry for the sub-entities.
The transmission of the response can go through the initial correspondent, which allows a first validation before reception by GTServer.
The follow-up of the responses for the sub-entities brings a significant comfort in the case of numerous sub-entities.
Example 3: Delegation of a questionnaire divided into input blocks
A questionnaire can be divided into fields whose data can only be modified by certain correspondents (e.g., HR section, finance section, etc.).
For each of the fields, an authorisation list is created, grouping the email addresses that can modify the components of this field. Locks are created on each of the fields verifying that the user’s email address belongs to the authorization list for that zone.
The main correspondent transmits the questionnaire to the first respondent who completes his part, then transmits the questionnaire to the next correspondent, etc., until the initial correspondent is reached for transmission to the main office.