Applicant sync
Applications and offers in Salesforce create or update the person in the student record.
Home / Solutions / Salesforce and Moodle
Connected campusSalesforce and Moodle
Salesforce and Moodle, working as one.
Applications in Salesforce become enrolments in Moodle without re-keying. Cases, cohorts and communications stay aligned with the student record, through connectors we build and run.
Salesforce managed appMoodle pluginInnealla or your SIS
The problem
Admissions in Salesforce, teaching in Moodle, truth in the student record.
SalesforceMoodleStudent recordCasesCohortsCommunications
When those three drift apart, staff re-key offers into Moodle and advisers work cases against yesterday’s export. This page is about closing that gap.
Who it is for
What this page is about.
This is the Salesforce and Moodle path specifically. For the wider campus integration picture, see Connected campus.
- Salesforce Education Cloud or custom admissions orgs
- Moodle and multi-tenant Moodle estates
- Innealla or your existing SIS as the student record
- Identity via Microsoft 365 or Google Workspace
- Payments and finance hand-offs when offers become enrolments
What we connect
From Salesforce application to Moodle learner, without re-keying.
Three systems stay in step: Salesforce for the pipeline, the student record for truth, Moodle for teaching.
Course provision
Accepted offers provision the right Moodle courses and cohorts for that intake.
Cases aligned
Service cases in Salesforce can see the same student identity Moodle and registry use.
Staff identity
Advisers and tutors keep the Microsoft or Google accounts they already have.
Payments
When fees clear, enrolment status updates without a second spreadsheet.
Reporting
Recruitment and teaching numbers come from one joined picture, not three exports.
How we work
Salesforce connectors that IT can still support in two years.
Named owners, acceptance tests and least-privilege credentials — not a one-off script under someone’s desk.
Object map first
We map Account, Contact, Opportunity or Application objects to the student record before any Apex or Flow is written.
Acceptance tests
Every sync path has an agreed test: applicant created, offer accepted, enrolment in Moodle, case visible to the right queue.
Managed where it helps
Our Salesforce managed package and Moodle plugin where they fit; documented custom work where your org needs it.
Handover that sticks
Runbooks, monitoring and credentials that your team can own — with us on call if you want a managed service.
Part of the Integration HubThe Salesforce–Moodle path reuses the same hub patterns we run for SIS, payments and identity.
Start here
Start with a Salesforce–Moodle Integration Review.
Two weeks, fixed price. You get an object map, the sync paths that matter, and a build plan you can take to your Salesforce admin or to us.
2 weeksFixed priceObject map
Book a Salesforce–Moodle review →What you get
- Salesforce objects and flows that touch admissions and cases
- Moodle courses and cohorts that must stay in step
- Where the student record must remain source of truth
- A ranked build list with effort and risk
Case study
Built for Dublin Business School.
Moodle, attendance, payments and Salesforce working across one estate.
- Multi-tenant Moodle estate
- RFID attendance tied to timetables and records
- Student service desk on Salesforce, connected to student data
- Automated release pipeline for every system we maintain
Proof
Proven on a live Salesforce and Moodle estate.
Dublin Business School runs Moodle, attendance, payments and Salesforce across one connected campus.
“Inneall are very solutions driven. They find better ways of doing things. I can throw an idea at them and they’ll find a way to do it.”
EO
Read how DBS connected the estate →Edward OrmondeHead of IT, Dublin Business School
CASE STUDY
DBS: Moodle, Salesforce and the student record on one estate
Read more →
RELATED
Connected campus: the wider integration picture
Read more →
RELATED
Integration Hub connectors we run for colleges
Read more →FAQ
Common questions.
Something else? Talk to us and an engineer who has shipped Salesforce–Moodle connectors will answer.
Do you use the Salesforce Education Cloud or a custom org?
Both. We have connected Education Cloud orgs and custom Salesforce builds used for admissions, cases and partner recruitment. The connector shape depends on your objects and flows, not on a single product SKU.
How do applications become Moodle enrolments?
When an applicant reaches the agreed stage in Salesforce, the Integration Hub creates or updates the learner in the student record and provisions the Moodle courses for that programme. Staff do not re-key names, emails or course codes.
What about cases, cohorts and communications?
Cases stay in Salesforce. Cohorts and communications can use Salesforce data that is kept in step with the student record, so advisers are not working from a stale spreadsheet export.
Can you work with our existing Moodle plugin or do we need yours?
We prefer our Moodle plugin and Salesforce managed package because we support them. If you already have a connector, discovery tells you whether to keep it, wrap it, or replace it within the fixed-price scope.
How long does a Salesforce–Moodle integration take?
A focused applicant-to-enrolment path is often live in weeks after discovery. A wider programme that also covers cases, payments and identity usually lands in a short phased release rather than one big cutover.
Where does the student record sit?
At the centre. That can be Innealla or the SIS you already run. Salesforce and Moodle both connect to it through the Integration Hub, so neither system becomes a second source of truth.
Next step
Salesforce and Moodle, working as one.
Start with a two-week, fixed-price Integration Review, and a plan you can act on.
Integrators for specialised education and CRM platforms
- Moodle
- Salesforce
- Zoho
- HubSpot
- Sitefinity
- Celcat
- Microsoft 365
- AWS
One college, many systems,
one set of integrations
Start with an Integration Review
Two weeks, fixed price. You get a map of what you have and a plan you can act on, with us or without us.
- Every system and interface mapped
- What breaks, what is manual, what is undocumented
- Fixes ranked by value and effort
- A short report for IT and the senior team
What we connect
A typical college runs systems from different suppliers and different decades. Staff re-key data between them, and students have to know which system holds what. The student record sits at the centre, whether that is Innealla or the SIS you already have.
- Student information systems to Moodle and other VLEs
- Attendance to timetables and student records
- CRM to admissions, payments and enrolment
- Service desks to student data
- Microsoft 365 and Google Workspace to everything else
- Intranets and portals to AI assistants
How we work
Integrations fail when only one person understands them. Ours are built so that is never the case.
- Fixed scope and an acceptance test for every integration
- Documented, monitored and supportable by someone other than the person who built it
- Least privilege, logged, no shared passwords
- Integration engineers embedded with your SIS or CRM programme for 6 to 24 months where needed
Platforms we work with
We are not tied to a vendor. These are the ones we have connected most often.
- Innealla, our own student record system, and other SIS platforms
- Moodle and Iomad
- Salesforce, Zoho and HubSpot
- Celcat timetabling
- Microsoft 365 and Google Workspace
- Sitefinity and WordPress
- Payment providers and finance systems
Built for Dublin Business School
Moodle, attendance, payments and Salesforce working across one estate.
- Multi-tenant Moodle estate
- RFID attendance tied to timetables and records
- Student service desk on Salesforce, connected to student data
- Automated release pipeline for every system we maintain
How we do things
Partnership, transparency, user-centred design and long-term quality guide every project. Each one runs through the same six stages, so you always know where it stands and who is accountable.