Survey Invites

This documentation is about inviting users to surveys in the admin panel.

If you navigate to the Assets & Recipients tab in the admin survey menu, you are prompted with a view like the one in the screenshot below. It features these main components:

1. The leftmost column shows the assets (typically applications) for which recipients have already been defined. The progress column shows how many mandatory and optional questions have already been answered.
2. You can look at all the participants that have been invited to the survey on an asset level.
3. You can click "Preview" to see a live version of this particular survey.
4. You can use this section to either manually invite users to this survey and assign them specific assets or you can add users based on the links within the instance, which is the preffered option for batch operations.
5. The dynamic recipients feature allows you to dynamically assign recipients based on a condition query. See detailed explanation in the dynamic recipients / recurrent surveys section below.

On the right side you find options to send Survey Invitation to users. Before you do that you might want to take a look at the email settings.

Once sent out, the Changes tab allows to track which changes were made by which stakeholder

Dynamic recipients / recurrent surveys

Dynamic recipients allow you to automatically assign and manage survey participants based on specified criteria. This feature automates recipient management and enables scheduled recurring surveys.

How It Works

1. Condition query: Define which assets should be included in the survey
2. Add recipient via user link: Specify which link type determines the recipient
3. Recurrent survey period: Set up recurring surveys at your preferred interval

The recurrent survey period resets the survey state, allowing it to be re-sent if it meets the query conditions. However, if a survey is considered complete, no new invitation will be generated.

The Manual completion confirmation setting plays a crucial role:

• Setting it to Always ensures surveys are never automatically marked as complete based on available data
• This guarantees that each survey will be sent out at every configured interval, regardless of data status
• Completion must be manually confirmed by the assigned recipient

This approach prevents surveys from being marked complete prematurely just because all mandatory questions have data filled in.

Configuration Example

In the screenhot above, the survey is configured to:

• Capture all Applications with names containing "_prd"
• Assign surveys to stakeholders linked as owners
• Resend surveys automatically every 1 month

When a new asset meeting your criteria is added to the repository, e.g.:

Asset Type	Properties	Links
Application	Name: CRM_prd Business Criticality: high ...	→ caretaker → max.mustermann@example.com → owner → jane.doe@example.com → runs in → Frankfurt ...

The system will:

1. Detect the asset matches your condition query
2. Add it to the survey scope
3. Assign jane.doe@example.com as recipient (based on owner link)
4. Schedule recurring surveys at your defined interval

Creating e-mail templates and scheduling reminders

Clicking the "Email settings" tab on the top of this page brings you to the page where you can schedule reminders to the survey's recipients and create corresponding e-mail templates. These are the main aspects of this page:

1. Add new reminder templates by clicking "Add sections"
2. Set the e-mail subject and body using placeholders.
3. All placeholders that are available. These can be used to, for example, use the name of the recipient and the name of the assessed asset in the e-mail's subject or body. For asset-specific surveys, you can use all properties of the asset using ${paramElement.X} in the email template. X has to be replaced by the exact property name that you want to use.

In the lower part of the page you can set do the following.

1. Set how many times a given e-mail template should be re-used.
2. Set the exact scheduling of e-mail reminders including the interval.
3. Optionally, select whether the caretaker should receive a CC e-mail when a reminder is sent out. Caretakers are stakeholders that are assigned to a given asset. It is their responsibility to make sure that a given asset is properly documented by another stakeholder, for example an application owner.

Interplay of scheduled emails and manual invitations

Each survey can have a dedicated scheduling for invitation emails and reminder emails. Each participant will first receive an initial invitation, followed by reminders. The text for each can be configured individually using placeholders. Please note that sending invitations manually affects this automated scheduling. Let's assume that:

• We have a survey which is set up to send invitations and reminders every monday.
• The user Anne was part of the initial set of recipients.
• On a wednesday, we add the user Bob and immediately invite them manually.

The situation can be visualized like this:

1. It's a monday. Anne will receive a reminder e-mail. Bob is not yet a recipient, so he will not receive any emails regarding this survey.
2. It's wednesday. Bob gets added as a recipient and is invited via e-mail immediately.
3. On the next monday, the scheduled invitations are sent. Anne receives a reminder (assuming she still has unanswered questions). Bob does not receive a reminder here, because the most recent email we sent to Bob was less than 7 days (the scheduling interval) ago.
4. On the next monday, both Anne and Bob receive reminder emails.

Authentication

Every user needs to authenticate before they can answer a survey. The user account is shared between the main tool and the survey tool but you can use the permissions to control if a user should be able to access the individual components.

Besides the normal user authentication options you can activate the magic authentication in the "email settings" tab for surveys. If this option is activated, every link in the survey invitation and reminder email contains an authentication token which automatically authenticates the current user. Every link is by default valid for 25 hours, but this behavior can be changed in the system configuration. If a user clicks on a link with a expired token, a message is shown that the link is outdated and a new link can be requested by clicking on a button. This will send a new link to the users-email address.