Moodle custom reports with the report builder

A custom report in Moodle is built from three parts that act in a fixed order. The report source defines the base records, such as users, courses or enrolments, and nothing outside that base can appear in the result. Columns then add fields from related data, so a column can show a course name or a completion date for each base record, but a column does not add rows. Conditions filter the result set, so a condition on a field changes which records survive while the column only displays a value. Before building anything, decide which source is the unit of counting, because every later choice depends on it. Confirm on your installed version which sources, columns and condition operators are offered, since the available list can change between releases.

Custom reports start from a different place than the standard reports and logs. Standard course reports are fixed views built around the questions Moodle's developers anticipated. The logs record a stream of events, which must be aggregated before they describe current state, such as whether a learner is still enrolled. The report builder lets your team choose the base records, the fields and the filters, then save the definition for reuse by others. That flexibility has a cost. A saved report is only as correct as its definition, and it will not warn you when a field it depends on changes meaning after an upgrade or a plugin change. Treat each report as a small specification with a named owner, and review it after every Moodle upgrade.

The builder joins data only along relationships that each source exposes. If the data you need lives in another system, such as an HR feed, a grading export kept in a spreadsheet or a separate analytics database, the builder cannot join it directly. A combined view then needs an integration, or the question moves to a separate analytics stack. Joins can also multiply rows. When a base record relates to several related records, such as several enrolments or several completion entries, each one can produce its own line, and a total then counts the same learner more than once. Check the row count against the source before trusting any summary, and decide whether a multi-value relationship should be collapsed by a condition, a chosen column or a separate report.

Most mismatched numbers trace back to an undefined population before the query is ever checked. Active learners, enrolled users and a cohort sound interchangeable, but each one selects different records. Enrolled users may include suspended enrolments, suspended accounts, staff holding teacher roles and learners whose enrolment has ended. Write the population as a rule with every term defined: which enrolment status counts, whether suspended accounts are excluded, which roles are removed and which date window applies. Agree that definition with the people who consume the report before the first build, so the same rule is reused in every report that reads the population.

Before anyone relies on a report, test it against a list whose status you already know. For illustration, take five to ten users from source records: an active learner, a suspended learner, a learner whose enrolment has ended, a teacher and a user with two enrolments in the same course. Run the report with the defined population and check that each known user appears or is excluded as the rule requires, and that the row count matches the count you expect. Keep the test list and its expected results with the report definition, then repeat the test after each Moodle upgrade or plugin change. A report that passes this check still needs a periodic recheck, because the data behind it keeps changing.

The report builder in Moodle is a good fit for operational and compliance reports drawn from one Moodle database, but it is not the right tool for every reporting need. A separate analytics stack becomes necessary when the question spans systems Moodle does not own, when history must be kept far longer or in far greater volume than the site's day-to-day reporting handles, or when the output must be shared with people who never log in to Moodle. Before you design any custom report, decide which of these cases apply, because the answer determines whether the report builder is the end of the design or only the first stage of it.

The most common trigger is cross-system analysis. A question such as whether completion rates differ by department, job grade or enrolment cohort needs HR or student information data that lives outside Moodle. The report builder can only join what is in the Moodle database, so the HR attributes must first be synchronized into Moodle user profile fields or a custom field, and that synchronization is a design decision in its own right. If the analysis also needs academic records, finance data or data from a learning record store, the work usually moves to a warehouse where those sources can be combined under one set of keys and one set of access rules.

Volume and history are the second trigger. The report builder runs queries against live Moodle tables, and its performance depends on the size of the logs, grades and completion data it must scan, the indexes present on those tables and the database server's capacity. Confirm with your database administrator how many rows the largest log and grade tables hold today, how fast they grow, how long you must retain them, and how long a representative report takes to run at peak hours. If multi-year trend reports or large statistical analyses slow the production site, that is the signal to copy the data elsewhere on a schedule instead of querying it in place.

Exporting to a separate system has real costs. An extract pipeline needs scheduling, error handling, monitoring and a way to recover from partial loads. Every copy of learner data becomes a new place where personal data must be minimized, secured, retained for a defined period and removed when a request for erasure is valid, so the privacy and records teams must sign off on what is copied. Ownership also has to be explicit: someone must be accountable for the pipeline, for the meaning of each field and for keeping the copy consistent with Moodle after upgrades change table structures. If your organization already runs an analytics platform, such as an open-source BI tool or a data warehouse, reuse it before adding another system.

Before you choose an option, ask for a written inventory of the reporting requirements, the data sources each one needs, the volume and retention figures from your own environment, and the owner of each downstream system. Those answers decide whether the report builder can serve the need on its own, whether a scheduled export to an existing warehouse is enough, or whether a broader analytics design is needed. Keep the choice vendor-neutral at this stage, and record the decision so that future reporting requests are assessed against the same criteria.

The effort in a custom reporting project comes mostly from deciding what each report should say, not from building it in the report builder. Plan the work as five cost components. Scoping the reporting questions comes first: who needs the answer, how often, and which decision it supports. Agreeing data definitions across departments follows, because a count of active learners or overdue completions is only as useful as the rule behind it. Building and testing the reports, configuring access and scheduled delivery come next. Maintaining the reports through Moodle upgrades continues for as long as the reports are in use. For each component, ask who on your team and who on the partner side is paid for that work.

The one-time work is front-loaded. Scoping and definition workshops are where most decisions get made, and they take the most calendar time because each department must agree on the same field, filter and date range. The number of stakeholders is the largest factor that raises effort. If two departments define completion differently, the workshop load for a single report can grow quickly. Data sources outside Moodle add a second layer. Joining HR or student information system data to course data needs an agreed extract, a matching key, and a decision on whether the report builder can reach that data at all or whether a separate pipeline is needed. Confirm each external source, its owner and its refresh schedule before anyone estimates the build.

Compliance evidence requirements change the build more than the report layout does. If a report supports an audit, you need to know which users can see it, which audiences receive it, whether personal data appears in the output, and how long exported files are kept. In Moodle, access depends on the report's audience and on the capabilities held by the roles that carry report builder permissions, so every role used for reporting should be listed and reviewed. Scheduled delivery adds a further decision. Emailing a report to a mailbox outside the institution is a disclosure decision that needs its own approval. Record who approved each report definition and keep that record with the report.

Recurring work begins once the reports go live. Report review confirms that each report still answers its original question, that its sources and conditions still match how the business uses the data, and that no one has added columns exposing more personal data than intended. Access reviews repeat on the schedule your policy sets, checking audience membership and removing leavers. Upgrade checks run before each Moodle upgrade. Confirm that the report sources, columns and conditions in use still exist in the target version, and read the release notes for changes to reporting. Treat these activities as a standing part of running the reports, and agree in advance who owns them.

When you ask for a written quote, look for each component listed separately: the reporting questions in scope and the number of reports they cover, the stakeholder workshops with the departments and roles involved, the external data sources and who supplies their extracts, the testing and acceptance criteria, and the access and delivery model, including any recipients outside the organization. Ask what is excluded, such as new reports after handover, data pipelines and analytics tooling. Ask how scope changes are priced and approved, and whether upgrade checks and access reviews sit inside the fixed scope or under a recurring retainer. A quote that does not show these items is difficult to compare with an estimate from your own team.