Moodle HR and SIS integration guide

How Moodle HR and student information system integration starts with one source of truth

Moodle HR and student information system integration starts by naming which system is authoritative for each fact about a person. The HR system or student information system (SIS) usually holds the records that matter most: who is employed or enrolled, in which job or program, and for which term or course. Moodle has to reflect those records without someone re-keying them, so the first decision is which system owns identity, which owns role and program membership, and which owns grades. Settle that before any connector is chosen, because every later choice depends on it.

Moodle core is licensed under GPL-3.0 and can be self-hosted, which means the integration is not a feature you switch on. Your team or a partner builds it, configures it and owns it after go-live. Moodle core ships several authentication and enrolment paths, including external database, LDAP and web services, but the exact enrolment and web service options depend on the Moodle version you run and the plugins you install. Confirm the available options against your target release before you design around any one of them. The connection itself is usually the easy part. The hard parts are identity matching, deprovisioning, duplicate accounts, cohort and enrolment rules, and grade return.

Identity matching decides whether a person in the HR or SIS record maps to exactly one Moodle account. Choose a stable identifier from the source system, such as an employee or student number, rather than an email address that can change. Deprovisioning needs the same rigor: define what happens to access and enrolments when a contract ends or a student withdraws, and test that path as carefully as the create path. Duplicate accounts usually appear when a manual account already exists, so decide in advance how the first sync reconciles existing users.

Teams usually need this integration for a few recurring situations. Term-based student intake creates large batches of enrolments on fixed dates, and missed updates show up as students who cannot reach their courses. Staff onboarding and offboarding require timely account and role changes, often tied to HR events. Mandatory training depends on accurate cohort membership so that completion reports reflect the people who were actually required to finish. Ask your implementation partner, or check with your own team, how each of these cycles maps to the sync frequency, the cohort rules and the grade return schedule you intend to use.

Before you write any sync logic, document the source fields, the Moodle fields they map to, the owner of each rule and the expected behavior for changes, leavers and conflicts. Run a small pilot against a copy of production data and check the results with the people who own the source records. Confirm the authentication and enrolment method against the Moodle release and plugins you plan to run, since those choices shape the rest of the build.

Which Moodle components carry users, cohorts, enrolments and grades

An HR or student information system feed reaches Moodle through a small set of components: how users authenticate, how they are enrolled, how cohorts group them, how external calls and scheduled jobs move data, and how grades and completions travel back. Each component behaves differently across Moodle versions, so the design should start from the version you will actually run.

Authentication plugins that create accounts

Moodle core ships authentication plugins for manual accounts, external database, LDAP, OAuth 2, Shibboleth, LTI and web services. Decide which one creates and updates user records and which one only authenticates them, because a site can have several enabled at once. For SAML 2.0 identity providers, the SAML2 single sign-on plugin (auth_saml2) is a common community option that must be checked against your Moodle version. Confirm field mapping and account-creation behavior in your version's documentation before design.

Enrolment plugins for role-based access

Enrolment plugins decide how a user gains a role in a course. Manual enrolment, self enrolment, cohort sync and database-driven enrolment are the usual options for HR or SIS feeds, and each has different rules for removing enrolments when a source record disappears. Test how each plugin handles suspension, unenrolment and role changes, since a feed that only adds records will leave stale access behind. Verify the exact settings in your own release.

Cohorts as the grouping object

Cohorts are site-level groups of users that can be used for enrolment, audience targeting, and reporting. They are often the simplest way to map a department, class or intake from a source system into Moodle. Decide whether cohort membership is owned by the source system or edited locally, because local edits will be overwritten or will drift from the feed. Confirm how cohort membership is exposed through your chosen web service or import method.

Web services for external calls

The web services layer lets an external system create, update or read users, enrolments and grades through token-authenticated calls. It suits near-real-time updates and two-way exchange, but every exposed function widens the attack surface and needs a dedicated service account with limited capabilities. Check which functions exist in your target version, since function names, parameters and deprecations change between releases. Plan token lifecycle and logging before any production call is made.

Scheduled tasks and import jobs

Scheduled tasks run through Moodle cron and are commonly used for batch imports from files or databases. Batch jobs are easier to audit and roll back than point-to-point calls, but they depend on cron running reliably and on the order of operations between user, cohort and enrolment steps. Confirm how your version schedules and logs these tasks, and how large imports behave under the cron settings you intend to use. Any community import plugin must be checked for compatibility before adoption.

Gradebook and completion for return flows

Grades and completion status are the data most often sent back to the HR or SIS. Decide which grade items, course totals and completion criteria are authoritative, and whether the source expects letter grades, percentages or raw points. Completion tracking depends on activity and course completion settings configured per course, so inconsistent settings produce inconsistent return data. Export through the reporting or web service method your version supports, and test with a sample course before enabling scheduled returns.

Which integration method fits your HR or SIS data

This table compares five ways to feed people, cohorts and enrolments from an HR system or student information system into Moodle. Read each row for the conditions where the method fits, the operational work it adds (credentials, network paths, error handling, monitoring, vendor dependency), and who must keep it running after go-live.

Method	When it fits	Operational cost	Who maintains it
Direct database read (external database authentication or enrolment)	Source system exposes a read-only database view and the team accepts tight coupling to its schema	Database service account, network path from Moodle to the source database, query tuning, alerts when views change	Moodle administrator with the source system's database team; both must agree on schema change control
LDAP or directory sourcing for accounts	Identities already live in a directory such as Active Directory and Moodle only needs accounts and group membership	Bind account with least privilege, LDAP over TLS, certificate renewal, directory replication awareness, handling of disabled accounts	Directory team for the schema and groups; Moodle team for field mapping and sync settings
Web services push from the source system	Source system can call an authenticated Moodle web service on each change and the team wants near-real-time updates	Moodle web service token and role, endpoint security, retry logic on the sender, reconciliation for failed calls, version handling	Source system developers for the sender; Moodle team for the service, roles and error review
Scheduled file-based import (CSV or flat file)	Source system can only export files on a schedule and changes are modest in volume	Secure file transfer path, file validation, rejection reports, duplicate and deletion rules, scheduled task monitoring	Operations team for transfers; Moodle team for import rules and exception handling each term
Middleware or integration platform in between	Several source systems feed Moodle, or transformation and audit logging must sit outside both applications	Platform licence, connector upkeep, separate credentials per system, extra hosting and monitoring, vendor upgrade cycle	Integration team owns the platform; it becomes a dependency that needs its own support and change control

Build sequence for Moodle HR and SIS data flows

This sequence takes an HR or student information system feed into Moodle in a controlled order, so accounts, cohorts, enrolments, suspensions and grade returns are each proven in a non-production copy before they touch live learners and staff.

Define the data contract and system of record
Agree, field by field, which system owns each value Moodle will hold: identity, name, email, department or program, job or enrolment status, cohort membership and course roles. Write down the source field, the format, the update frequency and who approves changes, using the HR and SIS data owners as signatories. Confirm which system wins when two sources disagree. The step is complete when the contract is signed off and every Moodle field has exactly one named source of truth.
Agree the stable matching key
Choose an identifier that does not change when a person changes name, email or department, such as the HR employee ID or the SIS student number. Email is a poor key because it is reassigned, corrected and sometimes shared. Decide how Moodle stores the key (the username, an ID number profile field or an external identifier) and how the key behaves for rehires, transfers and duplicate records. Confirm with the source system owner that the key is unique and retained after a person leaves. The check is a sample of records showing that the key is present and unique across the extract.
Build a non-production Moodle and source extract
Stand up a non-production Moodle instance on the same major version and database engine planned for production, and load a representative extract from the HR or SIS system, with personal data minimized or masked where policy requires it. Confirm the extract method (direct database view, export file or web service) with the source owner. Record the extract timestamp and row counts. The check is a reconciliation report comparing source and Moodle counts for users, cohorts and active enrolments, with any differences explained before the next step.
Build account provisioning and attribute mapping
Configure the authentication method that creates accounts from the feed, such as the external database plugin or a scheduled import, and map each source field to its Moodle profile field. Test creation, update and the handling of changed attributes, including name and email changes that should not create a second account. Confirm how the matching key is used to update existing users. The check is a test run where a changed email updates the existing account and does not create a new one, with the mapping table signed off by the data owner.
Build cohort and enrolment rules with role mapping
Translate source groupings such as department, program, intake or class section into Moodle cohorts, and translate job or enrolment codes into course roles through an explicit mapping table. Keep role assignment narrow, because a broad mapping can grant staff rights they should not have. Decide whether cohorts and enrolments are created from the feed or by course owners. The check is a test that a learner in a known section appears in the correct cohort and course with the expected role, and that a user with an unmapped code is flagged rather than given a default role.
Add deprovisioning and suspension rules
Define what happens when a person leaves, is suspended by the source or drops a program: suspend the account, remove or end enrolments, and keep records for grade history and audit. Decide the grace period and whether deletion is ever automated, and confirm the retention rule with the records owner. Add a check that compares active Moodle accounts with active source records on every run. The test that closes this step is a leaver test showing the account is suspended, can no longer sign in, and keeps its completed grade history.
Build grade and completion return with idempotent writes
Build the outbound job that sends final grades or completion status back to the SIS or HR system, using the matching key to identify each record. Design every write so that repeating the same run updates existing records and never creates duplicates, and log each change with a run identifier. Agree the grade scale, pass marks and the point when a grade is final. The check is a re-run test: run the same job twice on unchanged data and confirm the target system shows no duplicate or altered records.
Schedule and monitor the jobs
Schedule the import, enrolment, suspension and return jobs in the order the contract requires, and record their run windows against the source system's availability. Configure alerts for failed runs, row-count drops, unexpected spikes in deletions or suspensions, and mapping rejects, and assign an owner for each alert. Document how to pause the flows and how to rerun a single job safely. The step closes when a monitored production run completes, the reconciliation report matches the source within agreed tolerances, and the runbook has been tested by the operations team.

How to test a Moodle SIS integration before it touches real enrolments

Test the integration against a seeded staging copy of your HR or student information system extract before any scheduled job is allowed to write to a production Moodle site. The point of this stage is to prove that a bad input cannot create, move or remove enrolments in ways you would not accept. Build the seed data deliberately rather than copying a live extract wholesale, because a random sample rarely contains the awkward cases that cause real incidents. Your test set should include joiners, movers (a change of department, programme or cohort), leavers, duplicate person records, legal name changes, records missing the identifier your matching relies on, and a bulk run sized close to your largest term start. Ask the source system owner to confirm which identifier is authoritative and how it is reissued, since that answer drives most of your matching rules.

Verify both directions of the flow. For inbound data, check that each test person lands in the correct Moodle account, cohort and course enrolment, that movers lose the old enrolment and gain the new one, and that leavers are suspended or unenrolled according to the policy your registrar or HR team has signed off. Confirm which enrolment or authentication plugin performs each action, because a leaver handled by one plugin and a rejoiner handled by another is a common source of duplicate accounts. Run the same test set twice to confirm the job is idempotent: a second run against unchanged input should produce no changes. For outbound data, check the return flow separately in the next part of the test plan.

Make the failure behavior testable before you trust the schedule. Run the job in dry-run mode first and review the proposed create, update and suspend actions as a report. Set a cap on the number of changes a single run may make, and test that the job stops and alerts when the cap is exceeded instead of applying the excess. Confirm that records failing identifier matching are quarantined and listed for a named administrator to resolve, not silently skipped or force-matched to the nearest account. Finally, test the alerts: feed the job an empty extract and an extract far smaller than normal, and confirm that both halt the run and notify the on-call contact. A source outage that looks like mass leavers is the scenario this control exists to stop.

The return flow needs its own checks. Confirm that each grade or completion is written to Moodle once, including after a retried or interrupted run, and that the write is keyed to the correct user and course mapping, so a student enrolled in two courses with similar names receives the right record. Include suspended users in the test data and confirm that no grades are written for them. Check that the destination systems accept the format you send, and agree with the registry or records office which completion states are final and which can be revised. Record the expected output for every test case so the comparison is objective.

Set your own acceptance thresholds before running the final test cycle, such as the maximum tolerated number of mismatched enrolments in a bulk run and the maximum acceptable quarantine volume for a normal term. DeployOpen can help define the test cases and thresholds, but the business owners of the data should approve them in writing. Document every test case, input file version, expected result, actual result and sign-off, and keep this evidence with the change record. Auditors and internal reviewers will ask how you know the integration behaves correctly, and a dated, repeatable test pack is the most direct answer. Confirm with your assessor which evidence format they expect before you begin.

What drives the effort and cost of a Moodle HR integration

This table lists the main factors that change how much work a Moodle HR or student information system integration takes, and what to do early to keep each one under control. Read each row as a lever: the driver explains why effort rises, and the second column names the decision that lowers it. Most overruns trace back to the first three rows, so settle those before any build starts.

Driver	Why it changes effort or cost	How to keep it down
Number of source systems and data quality	Each HR system, student information system or contract register adds its own field formats, codes and gaps. Inconsistent records create exception handling that is often larger than the sync logic itself.	Agree one source of truth for each user attribute before build. Run a data profile on a sample extract and fix duplicates, blank fields and inconsistent codes at source.
Identity matching complexity	Matching a source record to an existing Moodle account depends on whether the source has a stable identifier. Matching on names or email addresses causes duplicates, merged accounts and rework.	Fix a persistent, unique identifier such as a staff or student number before build. Document the matching rule and the handling for records that do not match.
Volume and change frequency	Large populations, frequent joiners and leavers, and mid-term enrolment changes increase run time, error volume and the number of cases that need checking after each run.	Separate full reconciliations from incremental changes. Schedule runs to match how often the source actually changes, not how often it could change.
Number of enrolment and cohort rules	Every rule that assigns users to courses, cohorts or roles needs its own test cases. Rules that depend on other rules, such as program membership plus start date, multiply testing.	Phase rules: launch the core rules first, such as one program per cohort, and add conditional rules once the base sync is stable. Keep rules in a written table with owners.
Grade return scope	Returning grades raises questions about which assessments, which courses, what grade scale, when the record is final, and what happens when a grade is changed in the student information system after return.	Limit return to named assessments and courses. Agree the grade scale, the release point and the correction process in writing. Return only the fields the receiving system needs.
Return fields and personal data	Each extra field sent back or stored in Moodle adds mapping work, access controls and documentation. Personal data in logs, backups and reports adds review effort.	Limit exchanged fields to the documented minimum. Map each field to a stated purpose and review retention for logs and exports with your data protection lead.
Environments and change control	Separate development, test and production environments, plus a sign-off process for mapping changes, add setup, data refresh and approval time.	Use a masked or synthetic dataset in test. Agree who approves mapping and rule changes and how they are released, before the first build.
Compliance requirements	Regulated employers and education providers may need evidence of access control, data flows, change records and retention. Each control requested adds design and documentation work.	Ask your compliance lead which controls and evidence apply before scoping. Confirm specific obligations with your regulator or auditor rather than assuming them.

How deployment model changes the Moodle integration design

On a single web server, Moodle's scheduled tasks, including user, cohort and enrolment syncs, usually run from one cron entry on the same host that serves the site. There is only one runner, so duplicate execution is not a concern at this layer. Outbound calls to the HR or student information system leave from that one host, which makes the firewall rules simple but concentrates risk on one machine. Credentials for the external database or API usually live in the Moodle configuration file or in enrolment and authentication plugin settings, so file permissions and backup handling carry most of the security weight.

Scheduler: one cron entry triggers Moodle's cron, which runs the sync tasks on their configured schedule.
Outbound paths: one source address to allow-list at the source system, plus a route to the database or API endpoint.
Credentials: keep the configuration file outside the web root with restricted read access, and confirm how the chosen plugin stores passwords.
File exchange: a drop folder on the server read by a scheduled import, kept outside any publicly served path.
Backups: confirm that backups of the configuration and drop folder are encrypted and access-controlled.

Confirm the chosen cron entry and task setup against the Moodle version in use, because task scheduling and cron behavior are documented per release.

How to protect HR and student data in the integration

An HR or student information system feed into Moodle moves names, identifiers, enrolments and grades between systems that each hold regulated personal data. The cards below cover the credentials, connections, data minimization, logging, change control and deletion handling that keep that flow contained. Identity provider and SSO design is covered separately in the Moodle SSO and identity integration topic.

Least-privilege service accounts

Create one service account for the source connection and a separate Moodle web service user for the sync, each with only the capabilities its job needs. Avoid reusing administrator accounts or shared logins, so a compromised sync cannot change site settings or read unrelated records. Ask your Moodle administrator to confirm the role assigned to the web service user and review it whenever the mapping scope changes.

Credentials kept out of code

Database passwords, web service tokens and API keys should live in a secret store controlled by your platform team, not in plugin settings files, scripts or version control. Confirm where each integration reads its secrets, who can view them, and how rotation is done without editing code. Record each credential's owner and rotation date so an expired token does not silently stop provisioning.

Encrypted data in transit

Every hop in the feed, from the HR or SIS database to the sync host and from the sync host to Moodle's web services, should use encrypted connections with certificates validated against your internal trust store. Disable plain-text database connections and HTTP endpoints for these calls. Test that the client rejects an invalid certificate, since a sync that quietly skips validation will pass functional tests but expose records in transit.

Read-only database views

Give the integration a database user that can read only purpose-built views exposing the columns the sync needs, not the base tables. The view should exclude salary, national identifiers, health or disciplinary fields and anything else the sync never uses. Ask the source system owner to confirm that the user has no write, DDL or stored procedure execution rights.

Minimal personal data sent to Moodle

Map only the fields Moodle needs to create accounts, place users in cohorts and enrol them in courses, such as a stable identifier, name, institutional email and role or program code. Fields used only for reporting in the source system should stay there. Review the field list with the data owner before each new mapping goes live, because each added field becomes personal data stored in Moodle's database and backups.

Audit logs for every write

Record each user creation, suspension, enrolment change and grade write with a timestamp, the integration account, the source record identifier and the before and after values. Moodle's own logs and the sync's logs should both be kept, and the sync log should be retained in a location the Moodle administrators cannot edit. Confirm that logs can answer who changed a grade and from which source record within your required review window.

Change control on mapping rules

Field mappings, role assignments and cohort rules decide who sees which course and which grade, so they should go through the same review and approval as code. Keep mapping definitions in version control, require a second reviewer for changes, and test each change in a staging Moodle before production. Record which version of the mapping produced each batch so an incorrect enrolment can be traced and reversed.

Deletion and retention requests

Agree in advance how a deletion or retention request from the HR or SIS owner reaches Moodle: whether the account is suspended, its personal fields are removed, or grades are retained for a defined period. Confirm which copies exist in Moodle's database, the file store, backups and the sync logs, since each may need separate handling. Test one deletion end to end on a staging copy before the first real request arrives.

What to monitor, back up and document after a Moodle SIS integration goes live

The integration is not finished at go-live. Once Moodle starts receiving users, cohorts and enrolments from the HR system or student information system (SIS), the team needs a standing view of whether each job ran, what it changed and what it failed to change. Start by defining alerts for job success and failure, and send them to a person who can act on them, not only to a shared mailbox. Pair those alerts with scheduled reconciliation reports that compare the source extract with Moodle's current state: how many accounts were created, how many were suspended, how many enrolments were added or removed, and how many records were skipped. A sudden jump in suspensions is often the first sign of a broken source extract, so agree on the thresholds that should pause a job before a bad file reaches live accounts. Also monitor the grade return error queue, since failed grade or completion writebacks to the SIS can sit unnoticed for weeks, and run a source extract health check (file present, row count within expected range, header and encoding valid) before each import.

Backups for this integration must cover more than the Moodle database and moodledata. The mapping configuration, the job definitions, the cohort and enrolment rules, and any credentials or web service tokens used by the connection all determine how Moodle behaves after a restore. Export these artifacts on a schedule and store them under the same change control as the code. Confirm with your Moodle administrator and the integration owner that a restore test rebuilds the jobs and mappings, not just the data, and that the restored site can still reach the source system. Keep the backup retention and restore procedure in the operations documentation so the on-call engineer does not have to guess.

Retest the integration jobs after every Moodle minor or major upgrade and after every change to the source system, including a new field, a renamed status code or a new student record type. Moodle's release notes for the version you are moving to should be read against your mapping, because web service functions, authentication settings and plugin compatibility can change. Moodle 5.1 changed the web server document root to the new /public directory, and sites that must serve the site from /public need to update the web server configuration. Any custom endpoint, callback URL, script path or cron invocation that the integration uses must be checked against that change, because a path that worked before may return a directory listing or an error. Record the Moodle and PHP versions tested alongside each job run so that the evidence matches what is in production.

Hand over a set of documents that lets a new administrator run the integration without the original builders. The data contract defines the fields, formats, update frequency and ownership on the source side. The field mapping document lists each Moodle field, its source, its transformation and its default. The rules for cohorts and enrolments explain how a person is placed into cohorts, which roles they receive, when enrolments end and what happens to course history. The runbook for failed jobs covers how to identify a failure, how to rerun safely, when to stop a job and whom to contact at the SIS. The access inventory lists every account, service user, token and certificate, with its owner and purpose. Finally, the test evidence records what was tested, against which Moodle and source versions, and what the results were. Ask the implementation partner for these documents in an editable format and confirm they are updated at each change, not only at handover.

What buyers ask before hiring help with Moodle HR and SIS integration

What drives the cost of an HR or SIS integration for Moodle?

The main cost drivers are the number of source systems, how cleanly the source data is kept, and how many business rules must be encoded in Moodle. Cost components usually include discovery and data mapping, the integration build, test environment work, cutover, and documentation, with a separate line for any ongoing support. What raises cost: inconsistent employee or student identifiers, multiple campuses or departments with different rules, custom role logic, and sync frequency requirements. What lowers cost: a stable export or API from the source system, agreed field definitions, and a small set of cohort and enrolment rules. Ask any provider to split the quote into one-time build work and recurring operations so you can compare it with your own team's estimate.

How long does a Moodle HR or SIS integration usually take to deliver?

Duration depends mainly on how quickly your data owners answer questions and how many source systems and rules are involved. The work normally moves through discovery, mapping, build, test with realistic data, a supervised cutover, and a period of monitoring after go-live. Delays most often come from unclear identifiers, waiting for access to the source system, and late changes to enrolment rules. No duration is stated on this page. The timeline should come from the written scope for your environment, and it should show which milestones depend on your team's responses and access.

What do we need to provide before a Moodle integration project starts?

Before work begins, you will need to name the people who own each data set, such as HR, the registrar and the Moodle administrator, and assign one decision maker who can approve field mappings and rules. The delivery team also needs source system access with a documented way to export or query the data, a non-production copy or sample of the data, and test accounts in Moodle. Ask for written answers on which users, cohorts and enrolments are in scope, which grades or completions should be sent back, and how leavers and transfers are handled. Missing items in these areas are the most common reason schedules slip.

Can our internal team build the Moodle HR or SIS integration themselves?

Yes, many internal teams can build a basic sync, especially if they already run Moodle and have a developer who knows PHP and the Moodle APIs. The harder parts are usually the ones outside Moodle: understanding the source system's data model, handling identifiers and history correctly, and testing failure cases such as partial loads. Check whether your team can own the code after handover, keep it working across Moodle releases, and provide on-call cover for the sync schedule. A written scope can show which parts you keep in-house and which you ask an outside team to deliver.

Should we use an enrolment plugin, a web service or a file import?

Choose by how the source system exposes data and how quickly changes must reach Moodle. An enrolment plugin suits rules that map cleanly to course enrolments and when the database is accessible in a supported way. A web service suits near-real-time updates and two-way exchange, such as sending grades or completions back, but it needs an API on the source side and token management in Moodle. A scheduled file import suits systems that can only export files, and it is easier to audit, but it is slower and needs strict file validation. Core Moodle ships web services, and you should confirm which enrolment options your Moodle version and hosting setup support before deciding.

What happens to the Moodle integration when our HR or SIS system changes?

A source-side change, such as a renamed field, a new code table or a changed API version, can silently break mappings and cause users to be suspended or enrolled incorrectly. Good designs reduce this risk by validating each run, stopping on unexpected field counts or values, and logging every create, update and deletion. Ask for a change process that covers who is told when the source system is upgraded, how mappings are versioned, and how a test run is repeated before production. Confirm also whether support covers the sync after go-live, since many changes arrive months after the original build.

How do we request a fixed-scope quote for Moodle integration work?

Send a short written brief that names the source systems, the data objects in scope (users, cohorts, enrolments, grades, completions), the sync method you prefer or want assessed, the Moodle version and hosting model, and your target go-live window. Add the people who own each data set and who will approve the work. DeployOpen works from a written scope that sets out deliverables, responsibilities and timelines, agreed before work starts. Any figure in a quote should trace back to that scope, and you should ask the provider to list exclusions and the assumptions behind the timeline.

How DeployOpen scopes, builds and hands over Moodle integrations

DeployOpen plans, builds, tests, documents and supports Moodle integrations inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

How we scope

Map which HR or student information system records feed users, cohorts, roles and enrolments, and which fields are authoritative.
Agree the sync method in writing: enrolment plugin, web services or scheduled import, with the reasons for the choice.
Confirm the grade and completion records that must return to the source system, and the format and frequency each system accepts.

How we build

Configure a staging Moodle with the chosen enrolment, authentication or web service components, using test extracts from the source system.
Build field mappings, cohort naming rules and deprovisioning logic, and record every mapping decision in a shared specification.
Test duplicate handling, late joiners, leavers, changed student numbers and failed runs before any production data moves.

How we hand over

Deliver integration documentation covering configuration, scheduled tasks, credentials, data flows and known limits.
Provide runbooks for failed syncs, reconciliation reports and the steps to re-run a batch safely.
Walk your administrators through monitoring, log review and change control so the integration stays under your team's control.

How we support

Review integration behavior after each Moodle major or minor release, since web services and plugins can change between versions.
Investigate sync discrepancies against the source system and correct mappings through the agreed change process.
Offer ongoing support, upgrades and testing as a retainer, with scope confirmed in writing for each period.

Moodle HR and student information system integration