How to Integrate Interact, Moodle, and Viewpoint Without Replacing Legacy Systems

A nationally recognized heavy-lift contractor specializing in crane services, engineered lifts, and transportation for industrial construction projects.

Our client needed to connect data across its company intranet (Interact), ERP (Viewpoint), and it’s LMS (Moodle) into one employee experience.

The client already had the major platforms in place. The problem was not a lack of software. The problem was the user experience between those systems.

Employees had to navigate multiple systems to answer simple questions.

• What training is required?
• What training is hands-on or practical?
• What training is optional?
• What training is already complete?
• Which Moodle course matches a training code in Viewpoint?
• Where are the related course documents?

The client did not need another system of record. It needed a better workflow across the systems it already trusted.

Administrators also needed a practical way to keep course mappings, training codes, and LMS resources aligned without burying critical logic in configuration files or ad hoc processes. The client sought technical assistance from Tevpro to build custom integrations and and unify the user experience.

Tevpro built a custom Moodle training integration that embedded a responsive training experience directly inside the existing Interact intranet.

The integration layer handled the work between systems:

• verifying the employee’s active session
• retrieving employee-specific training records from Viewpoint
• synchronizing Moodle course metadata
• mapping business training codes to Moodle courses and resources
• launching the correct course through LTI 1.3

This allowed the client to unify the employee experience without changing which system owned the workflow. This distinction matters because the project was not about merging systems into one large platform. It was about creating a thinner layer that made those systems work together cleanly.

Integration Architecture at a Glance

• Employee
• Interact intranet and existing login
• Embedded training experience
• Integration API
  • Viewpoint (employee and training records)
  • Moodle: courses, documents, activity, completion, and grades
  • Metadata cache: course mappings and LTI resource links

For secure course launch, the integration used the LTI 1.3 standard from 1EdTech, with the connector acting as the platform and Moodle acting as the learning tool. Moodle handled the LMS side of the relationship, while the integration layer handled employee-facing orchestration and business-specific mapping logic.

How the Unified Training Experience Works

1. Employees Start Inside Interact

Employees begin inside the intranet they already use, not in a separate training portal. The embedded application uses the active browser session, and the API verifies the employee before issuing an application session.

This avoids a second login flow inside the embedded experience. Especially important in iframe-based applications, where browser cookie rules, redirects, and mobile webviews can create unreliable authentication loops.

2. Viewpoint Supplies Employee and Training Records

Once the employee context is established, the integration retrieves the relevant training records from Viewpoint.

Those records are translated into employee-facing categories such as:

• required
• practical or hands-on
• optional
• completed

This is more than display logic. It reflects how the business actually manages training. Due dates, assignment dates, completion history, practical indicators, position requirements, and status fields all affect what employees need to see first.

3. Training Codes Are Mapped to Moodle Courses

The project uses the business training code as the bridge between operational training records and Moodle course content.

Moodle course metadata is synchronized into a local cache so the integration can enrich training records with course names, short names, categories, and Moodle course IDs.

For employees, that means the dashboard shows meaningful training items instead of disconnected codes. For administrators, it means course relationships can be maintained through a management workflow rather than hidden in code.

4. Moodle Courses Launch Through LTI 1.3

When an employee starts a training item, the connector resolves the training code to the correct Moodle course and published resource. It then creates the signed launch flow, and Moodle validates the launch using the connector’s public key.

The implementation also uses LTI Deep Linking so administrators can associate the correct Moodle resources with the correct training codes.

In practical terms, LTI 1.3 handles the secure launch standard, while the integration layer handles the business mapping and employee context around that launch.

5. Employees Can Access Moodle Profile Documents in the Same Experience

The training center also exposes selected Moodle profile documents through the same embedded experience.

That sounds straightforward, but the workflow had to operate reliably across desktop browsers, Android webviews, iOS environments, and in-app browser constraints. The implementation accounted for cookie behavior, Safari behavior, file sharing, and mobile container limitations.

A workflow that works in desktop Chrome is not automatically ready for field employees using mobile devices.

How Administrators Manage the Training Workflow

Employee experience was only half of the project. Administrators also needed a reliable way to manage the relationships behind the dashboard.

The integration supported administrator workflows such as:

• searching training activity by employee, ID, training code, description, location, and status
• paginating broad searches and rejecting unbounded searches
• synchronizing Moodle course and category metadata
• publishing and unpublishing Moodle courses as LTI resources
• linking business training codes to Moodle courses and resources
• tracking LTI management activity
• monitoring longer-running operations through background jobs and polling
• inspecting the API through OpenAPI documentation

This mattered because a unified employee dashboard stays useful only if the underlying relationships are visible and maintainable. The result was not just a front-end improvement. It was an operable integration product rather than a fragile set of hidden mappings.

This project delivered a single employee-facing training workflow across Interact, Viewpoint, and Moodle without replacing the client’s existing platforms.

Employees gained:

• one place to view required, practical, optional, and completed training
• a clearer path to the right Moodle course
• access to related training documents within the same experience
• fewer workflow interruptions caused by switching between systems

Administrators gained:

• a maintainable way to manage course mappings and LTI resources
• better visibility into training search, synchronization, and publishing workflows
• a practical control surface for maintaining the training experience over time

Engineering Lessons From the Build

• Embedded Authentication Must Be Designed Early: Authentication inside an iframe is different from authentication for a standalone web application. Cookie rules, embedded contexts, redirect behavior, and mobile webviews all shape what will work. In this project, Interact remained the authentication gate, and the integration API verified the active session before giving the embedded app its own short-lived token. Same-domain routing helped keep browser behavior predictable.
• URL Architecture Is Part of the Product: The project used shared-domain routing so the intranet, embedded app, API, assets, and training short links could feel like parts of one experience. In a project like this, infrastructure decisions affect user workflows directly. Route matching and precedence are not just deployment details. They influence whether the system feels consistent and reliable to end users.
• Standards Help, but Vendor-Specific Gaps Still Happen: LTI 1.3 provided the secure launch standard between the connector and Moodle. Deep Linking provided a structured way to associate resources. Even so, not every operational need was exposed cleanly through the Moodle REST paths used by the project. The implementation isolated vendor-specific synchronization behavior behind a smaller adapter and cache. That reduced coupling while preserving flexibility.
• Training Data Still Has Business Semantics: Categories like required, practical, optional, and completed are not always simple database statuses. They may depend on training codes, dates, assignments, practical indicators, position requirements, and completion state. Sorting and prioritization also changed based on stakeholder feedback.

That is a useful reminder for integration projects: integration logic is often business process logic, not just data movement.

Why This Integration Pattern Is Reusable

This architecture applies whenever identity, workforce data, and learning content live in different systems. A thin integration layer can create a unified employee experience without becoming another master database.

This pattern works especially well when:

• employees already start from an intranet or employee portal
• training records live in Viewpoint or another ERP
• course content lives in Moodle or another LMS
• business identifiers can map operational records to learning content

For organizations planning a Moodle LTI 1.3 integration or an embedded employee training dashboard, the key is discipline. Keep each system authoritative, expose the workflow employees actually need, and give administrators a clear way to manage exceptions and mappings.