Moodle custom certificates for completion and CPD records
The Custom certificate plugin adds a certificate activity to a Moodle course. The activity is built from a template, issued automatically when the course rules are met, and can be checked later with a verification code. Academy managers, training teams and compliance leads usually need this for one reason: a learner who completes a course or earns CPD hours needs a document that proves it, and that document should come from the learning platform rather than from a spreadsheet and a mail merge. The plugin is a community plugin installed alongside Moodle core, not a built-in feature. That means it has its own release cycle, and each Moodle version needs a plugin version that supports it. Check the plugin's listing in the Moodle plugins directory against the exact Moodle release you run, and confirm the feature list for that release in the plugin documentation before you commit to a design.
Start the design with the template, because every certificate you issue will show whatever the template shows. List the fields your accreditor or sponsor requires, such as learner name, course title, completion date, CPD hours, and any statement about accreditation or the awarding body. Confirm that wording with the body that needs the record, not only with your own team. Then decide who owns the template. A single edit to a shared template changes every certificate issued afterwards, so compliance or the academy lead should approve changes through a documented process. Also confirm which fields the plugin can pull from the user profile and the course, and whether it can produce the hours figure from your data or whether that has to be entered by hand.
Issue rules depend on Moodle's own completion settings. Configure activity completion and course completion first, then attach the certificate to the course so it is released only when those criteria are met. Test the full path with a dedicated learner account: enrol, complete every required activity, and check the certificate appears with the right data. Decide in advance how you will handle retakes, late completions, manual overrides by a tutor, and learners who leave and return. Confirm how the plugin records the issue date, whether it can issue a second certificate for the same course, and what happens to existing certificates if a course is later changed.
A verification code is only useful if the verifier gets the answer they need, and it exposes personal data. Confirm how the plugin generates codes, whether verification is available without logging in, and exactly what a verifier sees, such as the learner's name, course and issue date. Agree that list with your privacy and data protection contacts before launch. Issued certificate records sit in the Moodle database, so they belong in the same backup and retention plan as course data. Each Moodle upgrade is a point where the plugin can break, so test the plugin on a staging copy of your site before changing the production version. Ask any implementation partner to confirm compatibility with your target release, the test plan, and who maintains the template after handover.
Which certificate options fit completion and CPD programs
This table compares the configuration choices that shape a Moodle certificate: course scope, how release is triggered, how learners receive the PDF and whether CPD hours appear on the template. Read each row for the situation it suits and the administration it adds, then confirm the exact setting labels on the Custom certificate plugin settings page of your Moodle version.
| Choice | When it fits | Administration cost |
|---|---|---|
| Single-course certificate | One course awards one certificate, such as a short compliance course or a single CPD event. | One template and one set of issue rules to maintain. Each course needs its own activity added and checked. |
| Multi-course program certificate | A learning path or CPD programme requires several courses before a certificate is issued. | Requires a consistent way to confirm completion across courses, usually through course completion settings or a reporting view. Expect more testing when a course is renamed or retired. |
| Completion-based release | Learners should receive the certificate automatically once the defined completion conditions are met. | Completion tracking must be configured and tested in every course before launch. Errors in completion rules produce missing or early certificates. |
| Manual release | A trainer, accreditor or administrator must approve each award, for example after a practical assessment. | Ongoing staff time per learner. Document who may release certificates and keep a record of approvals. |
| Learner download from the course | Learners should retrieve their certificate themselves whenever they need it, from the course or their profile area. | Low setup effort. Support requests increase when learners cannot find the link, so publish a short instruction in the course. |
| Certificate emailed as PDF | Learners should receive a copy in their inbox at the point of issue, or the organization wants a sent-record. | Needs a working outgoing mail setup and a check of spam filtering. Bounced or lost emails generate reissue requests. |
| CPD hours or credit values on the template | The certificate must state hours or credits for professional bodies, employers or regulators. | Values must be entered and kept current per course or program. Any change to accredited hours requires a template review and reissue decision. |
| No CPD values on the template | The certificate only confirms completion and no hours or credit are claimed. | Lower maintenance. Make sure learners and employers are not told that hours are attached, since the document will not show them. |
Setting up certificates in a test course first
This sequence takes a Custom certificate setup from version checks through a verified test issue, so the organization approves the wording and issue rules before any learner receives a certificate. Each step ends with a check you can record, and the final step is the owner's sign-off.
Confirm Moodle and plugin version compatibility
The platform administrator confirms the Moodle version the site runs and the Custom certificate plugin release that supports it. Check the plugin's compatibility statement on the Moodle plugins directory and confirm it names your exact Moodle version. Also confirm the server meets that version's PHP and database requirements. For Moodle 5.1, the release notes require 64-bit PHP 8.2 or later and the web server document root must point to the public directory. Done when you have written down the Moodle version, the plugin version, and the server checks that passed.
Install the plugin on a staging copy
The administrator installs the plugin on a staging copy of the production site, not on live. Use the site administration interface to install the plugin from the plugins directory or upload the package, then complete the database upgrade it requests. Review the plugin settings and the capability assignments that control who can add certificate activities and manage templates. Done when the plugin appears in the plugins overview, the notifications page shows no errors, and the staging copy loads normally for an editing teacher and a student account.
Enable completion tracking for the test course
The course administrator turns on completion tracking at site level if it is off, then enables it in the test course settings. Set activity completion conditions on each activity or resource that counts toward the certificate, such as a required quiz pass or a marked-complete page. Keep the conditions the same as the planned production course so the test reflects real issue rules. Done when the course completion report shows a status for each test user and the activities that count toward completion are listed as required.
Design the certificate template
The course designer builds the certificate template with the organization's logo, colors, signatory details and layout, using the plugin's template editor. Insert the learner name and date placeholders and draft the certificate wording and the CPD statement with the content owner. Keep the wording in plain language and avoid promises the course cannot back up. Done when a preview PDF for a placeholder learner shows the branding, wording and placeholders in the right positions on the page, with no clipped text.
Add the certificate activity and issue conditions
The course designer adds the certificate activity to the test course and attaches the template. Set the issue conditions to match the completion rules from step three, including any grade threshold, the date rules for issuing, and whether learners can re-download the file. Confirm the verification option is set as planned, since the verification code depends on this setting. Done when the activity shows the conditions in its settings and a test learner who has not finished the required activities sees that the certificate is not available and cannot receive it.
Run a test learner through the full path
A tester enrols a student account in the test course and completes every required activity in the order a real learner would. The tester then opens the certificate and downloads the PDF. Check that the learner name and issue date are correct, that the PDF renders without missing fonts or images, and that the verification code is present if it was enabled. Repeat with a learner who stops one activity short. Done when the completed learner receives the correct PDF and the incomplete learner does not, and both results are recorded in a short test log.
Obtain owner sign-off before go-live
The accountable owner for the certificate, such as the training lead or compliance owner, reviews the test PDF, the certificate wording, the CPD statement and the issue conditions. The owner approves in writing, and the approval names the template version and the Moodle and plugin versions tested. Any change after approval goes back through the test path in step six. Done when the signed approval is filed with the test log and the team has a go-live date agreed in writing.
Protecting verification codes and learner records
Certificates tie a learner's name, a completion date and a public code together, so the controls around templates, issuing, verification and stored records matter as much as the design of the PDF. The cards below list the decisions to make and the checks to run before a certificate program goes live.
Who can edit templates
Template editing and issuing are separate permissions in a Custom certificate setup, and a template change alters every certificate generated from it afterwards. Review which roles can edit templates at site, category and course level, and confirm that course administrators cannot change the wording, logos or signatory names on a credential they did not design. Record who approved each template version, because learners and employers will rely on that wording.
Who can issue and reissue
Issuing can happen automatically when a completion rule is met, or manually by a trainer, and reissuing replaces or duplicates a credential for a learner. Decide which roles may issue manually, whether reissue is allowed, and how a reissue is recorded so an earlier certificate can be traced. Test these permissions with a non-administrator account before release, since course-level roles often inherit more than their owners expect.
How verification codes are generated and checked
The verification code is the link between a PDF and the issue record, so its generation and lookup must be understood before any certificate is shared externally. Confirm how the plugin creates codes, how long they are, and whether they can be guessed or enumerated. Test the public check with a valid code, an altered code and a code from another site, and confirm the page reveals only the fields the organization has approved.
Personal data on each PDF
Each issued PDF typically carries the learner's full name, the course title, the completion date and sometimes an identifier or grade. Map every field on the template against your data minimization rules and decide which values are required on the document. Note that a PDF stored in file areas or emailed to a learner becomes a separate copy, so retention for generated files needs its own rule rather than relying on the database.
Retention of generated copies
Generated PDFs may sit in Moodle file storage, in backups, in learner downloads and in email archives, each with a different lifetime. Agree how long issued files and the issue log are kept, who can delete them, and what happens to records when a learner account is deleted or a course is removed. Confirm the chosen periods with your records schedule and legal team before the first cohort receives a certificate.
Backing up the issue log
The record of who was issued which certificate, and when, lives in the Moodle database rather than in the PDFs. Include that table in the same backup schedule, retention and restore tests as the rest of the database, and confirm that generated files in the data directory are captured by the same job. Run a restore into a test environment and check that a verification code still resolves to the right learner after recovery.
Public verification pages and privacy notice
A verification page is reachable without signing in, so it is a public-facing surface even though it shows only a small set of fields. Compare the data it displays, the search behavior and any logging of lookups against your organization's privacy notice and your lawful basis for publishing credentials. Involve your data protection lead before enabling the page, and document the review so the decision can be explained later.
Keeping the certificate plugin aligned with each Moodle release
The Custom certificate plugin is maintained separately from Moodle core, so every Moodle upgrade needs a plugin version that declares support for the target release. Before you plan any upgrade, open the plugin's entry in the Moodle plugins directory and confirm its supported Moodle range. Treat that check as the first gate in the plan. If no plugin version covers your target release, the upgrade date depends on the plugin maintainer, not on your team. Record the current Moodle version, the target version and the plugin version you intend to install, and keep that record alongside your certificate templates and issue rules so the three stay in step.
Support windows set the pace of planning. Moodle 4.5 is a long-term support release with security support until 4 October 2027. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027, and Moodle 5.2 has security support until 4 October 2027. Decide which release line your institution will run through the period you expect to keep certificates in circulation, then confirm the plugin supports that line. Check these dates on Moodle's releases page before each planning cycle, because a release that is in general support today moves to security-only support on a published schedule.
Each major release can also change the server stack. From Moodle 5.1, the web server document root must point to the new /public directory rather than the main Moodle folder, and sites that miss this change may show directory listings or errors. Minimum PHP and database versions also change by release. For example, Moodle 5.3 requires 64-bit PHP 8.3 or later and PostgreSQL 17. Ask your platform team to check the web server configuration, any reverse proxy or load balancer rules, and the PHP and database versions against the target release before the Moodle upgrade is scheduled, since a server change may need to happen first.
Test every plugin update on staging before production. Build a staging copy from a recent production backup, including the database and the data directory, so that existing certificates and issue records are present. Upgrade Moodle core if the staging copy is behind, install the matching plugin version, and run the upgrade. Then test the functions that learners and auditors depend on: issue a certificate from a completion rule, download the generated file, check that the template fields render correctly, confirm that a verification code resolves to the right record, and review the scheduled tasks that the plugin adds. Repeat the test after any template change.
A plugin that lags behind a core upgrade can block the upgrade itself. Moodle checks each plugin's declared version requirements during the upgrade process, and an incompatible plugin can stop the upgrade partway through. Plan a fallback for that case, such as a maintained fork or a temporary removal of the certificate rules with a documented record of issued certificates. When you request a quote, ask the partner to include the plugin compatibility check, at least one full staging rehearsal of the core and plugin upgrade, and the handling of certificates issued under the old version.
What to confirm before promising certificates to learners
A certificate promise is only as strong as the environment behind it. The checks below cover the plugin, the wording, the verification path, external enrolments and the records an auditor will ask for, and each one has to be confirmed in your own Moodle site before learners are told a certificate is available.
Plugin support for your exact Moodle release
Confirm that the version of the Custom certificate plugin you plan to install lists support for the exact Moodle release you run, including the point release. Moodle 5.1 and 5.3 have different PHP and database requirements, and a plugin built for an earlier branch can fail after an upgrade. Check the plugin's compatibility notes against your target release before scheduling the upgrade, and test the template and issue rules on a staging copy first.
Template capacity for required wording
Confirm that the certificate template can carry every statement your accreditor or regulator requires, such as the awarding body name, hours or credit value, accreditation reference and validity period. Measure the longest required text against the page layout and print or PDF output, and check that the template supports the fonts and language your learners need. The accrediting body sets the wording, so get the approved text in writing before the template is built.
Verification with your domain and HTTPS
Confirm that the public verification link resolves on your production domain, uses valid HTTPS with a certificate your learners' browsers trust, and is not blocked by a reverse proxy, login redirect or a CDN rule. A verification code that works only on an internal hostname gives an employer or regulator nothing to check. Test the link from outside your network after every change to the web server or certificate.
Learners enrolled through external systems
Confirm how certificates are issued to learners who arrive through SSO, an external database, LTI or a web services feed. Check that each of these learners is matched to the correct Moodle user record, that completion is recorded for them, and that the issue rules fire for them the same way they do for manually created accounts. Learners who are created, renamed or merged by an external system can end up with certificates on the wrong profile.
Exporting certificate records for audit
Confirm that issued certificate records, including learner identity, course, issue date, template version and verification code, can be exported in a form an auditor can read without database access. Check whether the plugin keeps a record of revoked or reissued certificates and whether the export covers certificates issued before any template change. Agree the retention period and who approves an export with your compliance lead.
Responsibilities for accreditation and certification
Confirm who owns each claim printed on a certificate. DeployOpen prepares the configuration and the evidence, including the template, issue rules and records, but it does not issue accreditation or certification and does not decide the wording a credentialing body requires. Your accreditor or regulator, and your own quality team, must approve the final text before learners receive it.
Questions buyers ask about Moodle certificate projects
What makes a Moodle certificate project cost more or take longer?
Scope drives the effort more than the plugin itself. The main drivers are the number of courses and programs that issue certificates, the number of certificate templates and languages, whether certificates must write to an HR or CPD record system, and how many courses already have completion tracking configured. Each course without completion rules needs review before any issue rule can be trusted. Each template adds layout design, wording review and test issues. Each language adds translation review and a check that fonts and date formats render correctly. Integration effort depends on the receiving system's interface and data rules. Ask any provider to price each driver separately in the written scope so you can see which one moves the total.
Can our own team set up Moodle custom certificates without a partner?
Often yes, for a single template used in a few courses. A team with Moodle administration experience can install the Custom certificate plugin, build a template and set an issue rule tied to course completion. The harder work is repeatable: keeping issue rules consistent across many courses, testing reissue and verification codes, and keeping the plugin aligned with each Moodle version. Check three things before deciding: who owns wording and sign-off, whether you have a staging copy for testing, and who will own upgrades after launch. If any of those is missing, a fixed-scope project or a retainer can cover the gap. DeployOpen plans, implements, tests and documents these builds in infrastructure you control.
What do we need to provide before an implementation partner starts?
Four inputs decide whether the project moves on schedule. Named owners for certificate wording and for final sign-off, so approvals do not stall. Access to a staging copy of your Moodle site, where templates and issue rules can be tested without affecting learners. Sample learner data that covers the edge cases you care about, such as partial completions, name changes and learners enrolled in several programs. Accreditation requirements in writing, including the wording, identifiers and retention rules your accreditor or regulator expects. Requirements given verbally tend to surface during testing, which adds rework. Ask for these inputs as a written list in the scope document so both sides know who supplies what and by when.
How many certificate templates and languages change the scope?
Each template is a separate design and test task, and each language adds a translation and rendering check. A single English certificate for one program is a small piece of work. A set of templates for several programs, with different layouts, signatories and wording per language, multiplies review cycles and test cases. Right-to-left languages, character sets and locale date formats need checks on the printed or PDF output as well as the screen. Ask the provider to list templates by program and language in the written scope, with the person who approves each one. Templates built on a shared layout with variable fields usually take less effort than fully separate designs, so ask whether a shared base suits your brand and your accreditor's wording.
Does certificate issuing need to connect to our HR or CPD record system?
It depends on whether the record system is the source of truth for completion or only a place to store issued certificates. If Moodle holds completion data and the HR or CPD system only needs a copy, the integration is a one-way export with a defined data format. If the external system decides eligibility or assigns CPD hours, the design needs agreed field definitions, a two-way data contract and a rule for conflicts. Before estimating, ask the system owner for the interface type, the authentication method, the field list, the update frequency and the error handling process. Integration usually adds the most uncertainty to a project, so confirm access and test accounts early and list it as a separate line in the written scope.
What recurring work remains after the certificates go live?
Certificates need ongoing care because Moodle and the plugin keep changing. Expect three recurring tasks. Plugin and core upgrades, scheduled around Moodle's release cycle. Template changes when wording, logos or signatories change. Reissue requests when a learner loses a certificate, changes their name or needs a corrected date. Moodle ships major releases every six months and point releases every two months, and Moodle 4.5 receives security support until 4 October 2027. Moodle 5.1 also requires the web server document root to point to the /public directory, and a site that is not updated can show directory listings or errors. Decide before launch who owns these tasks, and whether a retainer or an internal team will carry them.
Why is there no fixed fee or timeline on this page?
The cost and duration follow from the written scope, and the scope depends on the drivers covered above: course and program count, templates and languages, integrations and the state of completion tracking. DeployOpen does not publish a price list. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. To request a quote, send the list of programs and courses, the template and language count, the systems the certificates must reach, the accreditation requirements and the names of your owners. A written scope lets you compare proposals on the same basis. Ongoing support, upgrades and testing can be arranged as a retainer after launch.
How do completion settings affect certificate issue rules in Moodle?
Issue rules depend on the completion data Moodle already records, so course completion must be configured correctly before a certificate rule can be trusted. Check that completion tracking is enabled for each course, that activity completion conditions reflect the learning outcome, and that course completion criteria match what the accreditor expects. Test with learner accounts in each state: not started, partly complete, fully complete and completed after a reset. Also check how grades, completion dates and enrolment end dates affect eligibility. Keep the test results with the scope document so an auditor can see how issue rules were verified. Changes to completion criteria later can change who qualifies, so treat these settings as controlled configuration.
How DeployOpen scopes and supports Moodle certificate work
DeployOpen plans, implements, documents and supports Moodle certificate work inside infrastructure you control, from the certificate design through issue rules and verification codes. Engagements are fixed-scope, with the deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- Confirm which certificates exist today, which courses or programs trigger them, and who signs off the wording.
- Record the completion rules each certificate depends on, including activity conditions, grades and expiry periods.
- Agree in writing which Moodle version and plugin release the work targets, and how the site will be upgraded later.
How we build
- Design certificate templates with the required fields, layout and text variables, tested on sample learner records.
- Configure issue rules tied to course completion, then test edge cases such as re-enrolment, retakes and partial completion.
- Set up verification codes and check that a code can be looked up and confirms the correct learner and certificate.
How we hand over
- Deliver a written configuration record covering templates, issue rules, plugin version and verification settings.
- Provide a test script that course administrators can repeat after each Moodle or plugin upgrade.
- Walk through the operating runbook with the teams that issue, reissue and revoke certificates.
How we support
- Review the custom certificate plugin against each planned Moodle minor release before the site is upgraded.
- Retest issue rules and templates after upgrades, plugin updates and changes to course completion settings.
- Offer ongoing support, upgrades and testing as a retainer if your team wants continuing help.
