PACE – Personalised Adaptive Communication in Education

1 Summary

PACE extends the existing ILIAS course mail functionality by allowing authorised users to upload an Excel file containing participant-specific placeholder values and, optionally, recipient-selection information. LOGIN is used to match uploaded rows to course members, with a validation and recipient summary shown before sending. This enables scalable personalised communication and educational interventions while allowing the uploaded file to contain only the relevant subset of course participants.

2 Problem Statement

ILIAS already supports personalised placeholders when sending emails to course participants. In the mail editor, predefined placeholders such as the participant's first name, last name or login can be used to generate individualised messages.

However, instructors often have additional participant-specific information that is not stored in ILIAS and therefore cannot currently be used as a mail merge placeholder.

Such information may originate, for example, from:

This is particularly relevant for personalised educational interventions. An analysis may, for example, identify a subset of students who were active in an online learning environment or who would benefit from a particular follow-up intervention. The instructor may want to send these students a personalised email containing information or recommendations specific to each participant.

At present, this requires either sending messages individually or using an external mail-merge system.

This is also problematic in institutional environments in which personalised mass emails cannot be sent through the regular university email infrastructure. At the University of Bern, for example, personalised mass emails through the regular university email system are prohibited. ILIAS already provides the appropriate authenticated course environment and participant identification, but currently lacks a mechanism for combining course mailing with externally prepared participant-specific data.

A possibility to import participant-specific values and use them as custom mail placeholders would therefore be a very useful functionality for scalable personalised communication and interventions within courses.

3 Concept

The existing course mail functionality should be extended by allowing authorised users to upload an Excel file containing participant-specific information.

The uploaded table contains:

The column headers of the participant-specific data become custom mail merge placeholders.

After upload, the additional columns could become available as {{RECOMMENDED_TOPIC}}, {{FEEDBACK}}, and {{NEXT_ACTIVITY}} according to the above example.

An instructor could then write a single common message in which these placeholders are replaced individually for each recipient according to the row corresponding to that participant's LOGIN.

3.1 The uploaded file may contain only a subset of course members

The uploaded Excel file does not need to contain all members of the course.

It may contain only the participants for whom the current communication or intervention is intended. For example, a course may have 500 participants, while an analysis identifies 34 participants for whom a particular intervention is relevant. The uploaded file could contain only these 34 LOGINs.

By default, all successfully matched course participants contained in the uploaded file constitute the recipient group. Course participants who do not occur in the uploaded file do not receive the email.

This makes it possible to define a recipient group directly from the result of an external analysis.

3.2 Optional recipient-selection column

Additionally, the uploaded file may contain an optional column indicating whether a participant should receive the current message.

In this example, only student01 and student03 become recipients. This option is useful when the uploaded dataset contains participant-specific information for a larger population, but only a subset should receive the current intervention.

The exact naming and accepted values of such a selection column can be defined during implementation. A reserved column such as SEND_MAIL would be one possible solution.

3.3 Example workflow

A particularly relevant workflow is the combination with learning analytics or online learning environments:

4 User Interface Modifications

4.1 List of Affected Views

The feature would mainly extend the existing interface for sending emails to course or group members.

The following views and interface elements would be affected:

No new ILIAS object type is required. The feature should be integrated into the existing course/group mail functionality.

4.2 User Interface Details

4.2.1 Upload participant-specific data

Within the mail composition workflow, an additional option should be available, for example:

Upload Personalised Mail Data

To facilitate preparation of the file, ILIAS should also provide a Download Template button. The downloaded Excel template should contain a mandatory LOGIN column prefilled with the LOGINs of all current course participants.

The sender can then prepare the personalised mailing data in one of two ways:

The sender can add further columns to the Excel file. The first row contains the column names. LOGIN is mandatory. All additional participant-specific columns can be made available as custom mail merge placeholders, except for reserved technical columns such as the optional recipient-selection column.

The completed Excel (.xlsx) file is then uploaded to ILIAS.

4.2.2 LOGIN validation

Immediately after uploading the file, ILIAS validates the values in the LOGIN column against the members of the current course. This validation is an important part of the workflow because LOGIN is the key used to associate personalised information with the correct participant.

ILIAS should show a clear LOGIN matching summary before allowing the user to continue. For example:

Participant matching

37 unique LOGINs found in the uploaded file
34 matched successfully to members of this course
3 could not be matched to course participants

Unmatched LOGINs:
login_a
login_b
login_c

Where possible, the validation should distinguish between:

Problematic LOGIN values should be explicitly displayed so that the sender can correct the source data if necessary. Duplicate LOGIN values should not be silently resolved, because different rows could contain different personalised values for the same participant.

4.2.3 Recipient summary

After matching the LOGINs, ILIAS determines the resulting recipient group.

If no selection column is used, all successfully matched course members contained in the uploaded table are selected. For example:

Recipients

Course members: 486
LOGINs in uploaded file: 37
Successfully matched course members: 34
Recipients of this email: 34
Other course members who will not receive this email: 452

If an optional recipient-selection column is used, the summary could instead show:

Recipients

Successfully matched course members: 34
Marked to receive this email: 21
Not selected by the uploaded data: 13
Unmatched LOGINs: 3

21 personalised emails will be generated.

The sender should be able to review the selected LOGINs and, if necessary, upload a revised Excel file, which is then validated again before proceeding.

4.2.4 Confirmation before proceeding

After displaying the LOGIN validation and recipient summary, ILIAS should explicitly ask whether the sender wants to continue.

If unmatched LOGINs are present, this should be clearly highlighted. For example: 3 LOGINs from the uploaded file could not be matched and will not receive an email. Do you want to continue with the successfully matched and selected recipients?

Certain errors, such as duplicate LOGINs with ambiguous participant-specific values or an absent LOGIN column, should prevent continuation until they are corrected.

4.2.5 Custom placeholders

After successful validation, the additional columns should be displayed together with the existing mail merge placeholders. For example:

These can then be used in the subject or body of the email, where technically supported by the existing placeholder mechanism. The custom values are resolved individually according to the recipient's LOGIN.

4.2.6 Optional additional preview

Before sending, it should ideally be possible to preview the fully resolved email for individual recipients. The preview should show the exact message that the selected participant will receive, including both standard ILIAS placeholders and imported custom placeholders.

This is particularly important when participant-specific information such as feedback or learning analytics results is being communicated.

4.2.7 Sending

When the sender confirms the mailing, ILIAS generates an individual message for every selected recipient. Each message combines the common subject and message body, existing ILIAS mail merge placeholders, and custom participant-specific placeholders imported from the Excel file.

Only the values associated with the recipient's own LOGIN may be inserted into that recipient's message. Participants who are not represented in the uploaded file, or who are explicitly excluded through the optional selection column, do not receive the email.

4.3 New User Interface Concepts

The feature should preferably reuse existing ILIAS UI concepts and components: file upload, existing mail composition, existing mail merge placeholder presentation, status and validation messages, tables for reviewing recipients, and confirmation actions.

A possible workflow is:

Open mail composition → Download Excel template / Upload Excel → Validate LOGINs → Review recipient summary → Confirm → Use custom placeholders → Preview → Send.

The download and upload functionality should be integrated into the existing mail composition workflow.

4.4 Technical Aspects

The exact implementation should be discussed with the maintainer of the Mail component. Conceptually, this feature should extend the existing mail merge / placeholder functionality instead of introducing a separate mailing system.

The implementation needs to support:

The uploaded participant-specific data should only be used for the current personalised mailing and should not create permanent user-profile attributes. If personalised mails can be saved as drafts, the handling of the uploaded data should be defined during implementation.

5 Non-Functional Implications

5.1 Security

Uploaded Excel files and their contents need to be treated as untrusted input. Relevant aspects include:

The central security requirement is that participant-specific information must never be associated with the wrong recipient.

Before sending, ILIAS therefore needs to establish an unambiguous relationship:

course member ↔ LOGIN ↔ uploaded row ↔ generated email

Duplicate LOGINs or other situations in which this relationship is ambiguous should prevent sending until the issue is resolved.

5.2 Privacy

The feature may process participant-specific educational information such as individual feedback, learning activity, recommendations, assessment-related values, or learning analytics indicators.

Particular care therefore needs to be taken to ensure that information associated with one participant cannot be disclosed to another. The feature should follow the principle of data minimisation.

Allowing the uploaded file to contain only the target population also supports data minimisation, because instructors do not need to upload information about all course members when the intervention concerns only a subset.

5.3 Accessibility Implications

No specific accessibility implications are expected. The new interface elements should use existing accessible ILIAS UI components and follow the established accessibility requirements of ILIAS.

6 Process Information

6.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

6.2 Contact

Person to be contacted in case of questions about the feature or for funding offers:  {Kinga Sipos}

6.3 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

Interest in funding: To be clarified. (As the University of Bern is currently considering a potential change of its learning management system, it does not plan to invest in further ILIAS development until a decision on the future LMS has been made.)

7 Discussion

8 Implementation

Feature has been implemented by {Please add related profile link of this person}

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

8.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

8.4 Approval

Approved at {date} by {user}.