Workflow-based User Lifecycle Management for Moodle

Niels Gandraß

mail Niels.Gandrass@haw-hamburg.de
globe https://gandrass.de

Moodle Moot DACH 2026

Swiss Federal Institute of Technology Zurich

2026-07-02

Motivation

Why and when do we even want to get rid of users and other content?

gavel Legal construction Technical apartment Organizational

Legal requirements

Let's get trough the boring stuff first ... (1/3)

contract Art. 5 GDPR

1. Personal data shall be: [...]

(e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed;

keyboard_arrow_down

We need to remove old user records and other personally
identifiable information (PII) from our systems
without undue delay

Legal requirements

Let's get trough the boring stuff first ... (2/3)

contract Art. 19 GDPR

The controller shall communicate any rectification or erasure of personal data [...] to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort.

keyboard_arrow_down

Students deleted from the university IDM must be deleted
from Moodle without undue delay

Legal requirements

Let's get trough the boring stuff first ... (3/3)

contract Art. 17 GDPR

1. The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay [if] one of the following grounds applies:

(a) the personal data are no longer necessary [...] for which they were collected;

(b) the data subject withdraws consent [...] and where there is no other legal ground for the processing;

keyboard_arrow_down

Students can't simply request the deletion of exam data or grades.
Deletion can't be a fully automated self-service.

You survived the boring part!

In case you missed the confetti at the MoodleMoot DACH 2025 DevCamp

Technical & Organizational aspects

home_storage Your moodledata/ folder is only getting bigger

chevron_right All uploaded files and submissions are kept for active users

database Your Moodle database grew to a decent size while containing mostly unused data

more_time Certain tasks or database queries take ages to complete

chevron_right Some housekeeping tasks still scale largely with the amount of total user data

database_search Having less data to sift through leaves more time for the interesting tasks

person_search Avoiding name collisions when searching for users

chevron_right Enrolling the correct "John Smith" out of 30 ones can be error-prone

layers_clear Phasing out old content (e.g., question types or activities)

chevron_right Some plugins can only be uninstalled once all usages / instances are deleted

Our Current
User Lifecycle(s)

How users get on and off our Moodle platforms

Different platforms, different user lifecycles

We run a number of Moodle platforms with diverging user management

University Moodles

Used solely by our students
Primary auth method is SSO
One account per university member
Semester-based user creation

Public Moodle

Open to the public
Local accounts and multiple SSOs
Anonymous temporary accounts
Constant user fluctuation

University Moodle

The simple and straight forward case

Public Moodle

The "slightly" more complicated case ...

Key takeaways

tactic It's only simple until it isn't

schema User life cycles can be multi-staged

groups Different user groups may require different life cycles

file_export External systems / events can dictate the flow

all_inclusive There is no simple "one size fits all" solution

User Lifecycles
as Workflows

Using multi-step flowcharts to model the full lifecycle of a group of users in Moodle

The workflow approach

Users progress through different user-defined workflows,
similar to what is known from the Course Life Cycle Plugin

more_horiz
More workflows

Moodle Plugin:
User Lifecycle Management

The Automatic User Deletion plugin grew into a fully-fledged workflow management engine.

Key features

auto_transmission Automatically manages users based on flexible workflows

filter_alt Extensive criteria for selection / filtering users

settings_account_box Various actions to perform on user accounts

security GDPR-compliant deletion of users data

science Dry-run mode for verifying the configuration

monitoring Action log to audit performed actions

construction Highly configurable (time thresholds, auth method, ...)

dynamic_form Dynamic variables (e.g., user names) in email templates

Moodle Plugin:
Automatic User Lifecycle Management
(tool_userautodelete)

Filters and actions

User filters and actions are lightweight and flexible sub-plugins

Filters	Actions
web_traffic Last access passkey Auth method date_range Date range timer Time delay groups Cohort approval_delegation Role assignment account_circle_off Suspension state	account_circle_off Suspend account_circle Unsuspend mail Send Mail delete Delete security Anonymize

Example workflow

Example workflow (edit mode)

Dry-run

Action logs

All actions performed by the plugin are logged in a cumulative fashion.

Specific workflows, steps, and actions can be identified, filtered for, and sorted by.

GDPR-compliant user deletion

Removing the remaining personally identifiable information (PII) after Moodle "deleted" a user

deleted	0
username	johndoe
password	<Password Hash>
email	jd@foo.com
firstname	John
lastname	Doe
institution	Awesome Uni
idnumber	123456789
description	My secret is 1234
phone1	+00 123456789
address	North Pole 1
lastip	10.0.0.42
picture

Moodle user table for active user

arrow_right_alt
Delete
user

deleted	1
username	jd@foo.com.1772113756
password	<Password Hash>
email	<MD5 Hash>
firstname	John
lastname	Doe
institution	Awesome Uni
idnumber	empty
description	My secret is 1234
phone1	+00 123456789
address	North Pole 1
lastip	10.0.0.42
picture	broken_image

Moodle user table for deleted user

arrow_right_alt
Remove
PII

deleted	1
username	DELETED-USER-1
password	empty
email	DELETED-USER-1@localhost
firstname	DELETED
lastname	DELETED
institution	empty
idnumber	empty
description	empty
phone1	empty
address	empty
lastip	empty
picture	broken_image

Moodle user table after PII removal

Upgrading from the automatic user delete plugin (v1)

deployed_code_update

Existing v1.x.x installations can be upgraded to v2.x.x in-place
All previous settings will be reflected by the new workflows filters and actions

You can find all migration details here:
https://moodleuserlifecycle.gandrass.de/changelog/#migrating-from-v1-to-v2

Modeling
Institution-specific Use-cases

Leveraging the workflow engine to support your institutions lifecycles

Using filters, actions, and multiple workflows

You got various user groups that require different lifecycles? We got you covered!

mitre Having multiple workflows allows targeting different user groups independently

rebase_edit Steps, filters, and actions can be combined freely

format_list_numbered Workflows are ordered and follow a deterministic execution model

looks_one User will only ever be in a single workflow at a given point in time

pause_circle Workflows can either be disabled individually or paused globally

vacuum Timeout / user retention can be configured on a per-workflow basis

Creating custom filters and user actions

All filters and user actions are small yet flexible sub-plugins and
can therefore easily be extended according to your specific needs

https://moodleuserlifecycle.gandrass.de/dev

You can find detailed instructions on implementing your own sub-plugins
within the developer documentation!

Contributing

You created something that could help others? Wonderful!

Please feel free to submit a pull request or open an issue over on GitHub

Contributing

You created something that could help others? Wonderful!

Please feel free to submit a pull request or open an issue over on GitHub

volunteer_activism

Thank you!

Quickstart and Resources

I got you hooked and you would like to start exploring the plugin? Nice!

Quickstart

You can find a quick guide on how to install the plugin and
get started with your first workflow in the comprehensive online documentation

https://moodleuserlifecycle.gandrass.de/

Getting the plugin

The user lifecycle management plugin is available on GitHub
and via the Moodle Plugin directory!

https://moodle.org/plugins/tool_userautodelete

https://github.com/ngandrass/moodle-tool_userautodelete

Q&A Session

Now it's time for your questions!

You can find all slides of this talk at
globe https://gandrass.de

Workflow-based User Lifecycle Management for Moodle

Niels Gandraß

Motivation

Legal requirements

We need to remove old user records and other personally identifiable information (PII) from our systemswithout undue delay

Legal requirements

Students deleted from the university IDM must be deleted from Moodle without undue delay

Legal requirements

Students can't simply request the deletion of exam data or grades. Deletion can't be a fully automated self-service.

You survived the boring part!

Technical & Organizational aspects

Our Current User Lifecycle(s)

Different platforms, different user lifecycles

University Moodle

Public Moodle

Key takeaways

User Lifecycles as Workflows

The workflow approach

Moodle Plugin: User Lifecycle Management

Key features

Filters and actions

Example workflow

Example workflow (edit mode)

Dry-run

Action logs

GDPR-compliant user deletion

Upgrading from the automatic user delete plugin (v1)

Modeling Institution-specific Use-cases

Using filters, actions, and multiple workflows

Creating custom filters and user actions

Contributing

Contributing

Quickstart and Resources

Quickstart

Getting the plugin

Q&A Session

We need to remove old user records and other personally
identifiable information (PII) from our systems
without undue delay

Students deleted from the university IDM must be deleted
from Moodle without undue delay

Students can't simply request the deletion of exam data or grades.
Deletion can't be a fully automated self-service.

Our Current
User Lifecycle(s)

User Lifecycles
as Workflows

Moodle Plugin:
User Lifecycle Management

Modeling
Institution-specific Use-cases