The institute had to build a pool of authorised trainers from partner countries, and the system it had bought was designed for employees, not for candidates working through an accreditation pathway.
A trainer profile carries pedagogical qualifications, subject matter credentials, delivery experience by audience and method, operational experience in migration, and language levels on a six point European scale. None of that maps onto an employee record. Performance had to be reviewed by a monitor and by students, against courses actually delivered rather than internal job goals. And the institute already ran eleven plugins in its staging environment, each of which had to keep working.
Every change landed in a companion plugin and a custom theme, so the institute keeps its vendor licence, its updates, and its support line.
We worked from the institute’s own trainer profile, performance review and training forms, mapping every field onto the HR data model and marking where the model had to be extended rather than bent.
A custom plugin on top of the HR module adds the fields the pathway actually needs: topics qualified to train, trainings authorised to deliver, course delivered, and monitor and student averages. Unused tabs such as leave, compensation and performance goals are hidden from view.
Custom recruitment fields, certificate attachments and the applicant photo now transfer to the employee profile on hire, and the welcome email includes password setup exactly as a manually created account does.
A custom theme exposing the HR module outside the admin, with four distinct views for HR manager, recruiter, trainer and public visitor, plus a grid based page system the institute can rearrange itself.
Email templates for hiring, training assignment, to-do changes, performance reviews and goals, delivered through the institute’s existing transactional mail setup.
We defined which HR fields flow to Moodle, and worked alongside the identity plugin vendor and the Moodle provider through the SAML integration so a newly authorised trainer exists in both systems.
The finished environment moved to production with the vendor licence transferred, and a signed addendum covered the further field and tab changes the institute identified once it was using the system.
Trainers apply, get assessed, get authorised and get deployed through one record, and reach their courses without a second login.
Initial configuration became a step by step flow tailored to each role, surfacing only what is relevant at each stage instead of every option at once, so a new administrator reaches a working setup without wading through settings that do not apply.
Dense, form heavy screens gave way to a clearer visual hierarchy, consistent components and contextual guidance, so staff at any technical level can tell what a setting does and why it matters without asking.
Settings are organised by role and function rather than by technical category, so an administrator finds the controls for their own day to day work without needing a model of the system underneath.
The institute had already chosen its platform. The engineering question was not what to build instead, but how far a product can be extended before it stops being maintainable.
Engagement note, weLabs delivery team
Tell us where the friction is. We will map it with you and propose a clear place to start.
