Skip to content

mooDesk — a digitalMood product

A help-desk product built for Moodle. It runs inside the platform, with the accounts, roles and permissions it already has. We define, design, build, license, document and support it ourselves.

The mooDesk ticket queue: a filtered list of tickets, each with its status, priority, category, requester and assigned agent.
mooDesk · the agent's ticket queue (demo data)

Each role has its own interfaces.

The agent's queue is not the manager's dashboard with fewer buttons: several views of the same data, each shaped by what that role has to do.

The mooDesk dashboard: active tickets, SLA breaches and compliance, resolution times, and tickets over time.
The manager: dashboard, SLA compliance, trends
The mooDesk knowledge base: a search field, categories with their article counts, and a list of articles.
Everyone: the knowledge base, searchable by category

It runs inside the platform, and connects to what is around it.

mooDesk runs inside Moodle, on the platform's own permissions, privacy API and global search; its connections — email ingestion, reply by email, webhooks and a REST API — leave the platform to the mailbox and to external systems.

What we built

What building it shows: product definition, design and engineering as one piece of work, inside a platform an organization already runs on.

  • It runs inside the platform people already log in to.

    A Moodle local plugin: the same accounts, the same roles, no separate login.

  • Three roles, three editions, documented workflows.

    Requesters, agents and managers. Tickets, queues, SLA targets and a knowledge base, documented in public.

  • Each role has its own interfaces.

    Queues, saved views, dashboards and supervision views, designed per role.

  • It uses the platform's own mechanisms.

    Moodle's permissions, privacy API and global search, not copies of them.

  • It connects to the systems around it, and shows what happened.

    REST API, signed webhooks with a delivery log and retries, email in and out.

  • It is verified on Moodle 4.5, 5.0, 5.1 and 5.2.

    A test matrix across PHP 8.2–8.4 on MariaDB and PostgreSQL. Versioned releases.

  • Privacy obligations are handled inside the platform.

    Data export, anonymizing erasure and retention schedules, through Moodle's privacy API.

  • It is packaged, documented and supported as a product.

    Editions by license key, public documentation, known limitations disclosed, a public support channel.

What this page does not show

  • Moodle is the context of this proof; no attributable example on another platform yet.
  • It shows how we build and release an extension across platform versions, not an upgrade of someone else's customizations.
  • Our own product is the example: no client example, no figures about who uses it.
  • Privacy is handled with Moodle's mechanisms; this is not a statement about any jurisdiction's law.

Who builds this

digitalMood is a product design and engineering company. The same product definition, design and engineering go into new products and into the platforms organizations already depend on.

How we work

If what this page shows is relevant to a product you are building or a platform you run, that conversation is here.

Start a conversation