Why LMS-native integration wins
Faculty adoption depends on workflow simplicity. If instructors must switch platforms for setup, monitoring, and review, operational friction rises and consistency drops.
ProctorSafe integrates as a single script tag on your exam page, so it lives inside whichever LMS workflow you already use rather than adding a separate system to log into.
On the roadmap: LTI 1.3 / LTI Advantage platform-to-tool launches are not available today. The setup below uses the SDK's script-tag model, which every one of the three platforms below supports without a plugin.
Adding the script tag per platform
The same two lines go on the exam page in every case — see the under-one-hour technical guide for the full Proctor.start() call. What differs is where that HTML goes:
- Moodle: exam pages built with the HTML block or an "IFrame/HTML" resource type accept the script tag directly in the block editor's HTML source view. For a course-wide rollout, add it once to the theme's page footer so every quiz activity picks it up.
- Canvas: add the script tag to your account or course theme's custom JavaScript file (Admin → Themes → Edit CSS/JS), scoped to exam pages by checking the URL path in your own wrapper code, or embed it directly in a Canvas page used as the exam wrapper.
- Blackboard: a content area or "Item" with HTML editing enabled accepts the script tag the same way as Moodle's HTML block. Course-wide deployment depends on your Blackboard building-block permissions — check with your Blackboard admin.
In all three cases, the candidate never leaves the LMS: the script runs on the page the LMS already served.
Responsibilities: LMS vs. ProctorSafe
In every deployment:
- the LMS manages course context, enrollment, and assignment lifecycle, and authenticates the candidate before the exam page loads,
- ProctorSafe handles session integrity checks and incident evidence once the exam page starts a session,
- your exam page is the integration layer — it decides when to call
Proctor.start()and whatapplicationReferenceidentifies the attempt.
Clear ownership boundaries reduce support load and integration drift.
Instructor experience design
A good integration allows instructors to:
- enable proctoring per assessment by adding the script tag to that assessment's page,
- launch exams without custom technical steps, once the page is set up,
- review incidents in a concise, explainable timeline in the ProctorSafe dashboard.
When this is implemented well, instructors spend less time managing tooling and more time on academic decision-making.
Admin controls that matter
Platform administrators should have centralized controls for:
- tenant-level security defaults, set in the ProctorSafe dashboard,
- allowed origins for the SDK (Settings → Network), so the script only runs from your LMS domains,
- role-based access and audit trails for reviewers,
- proctoring profiles by exam risk level, applied via
proctoringProfileonProctor.start().
This avoids ad hoc configuration and keeps compliance posture consistent across departments.
Practical rollout checklist
- Add the script tag to a staging exam page in each LMS you use, and confirm a session starts and completes.
- Run a pilot with faculty champions and documented feedback loops.
- Train support teams on troubleshooting a missing or blocked script tag (the most common failure mode — check CORS-allowed origins first).
- Publish student-facing guidance before full launch.
- Monitor incident quality and false-positive trends post-rollout.
LMS integration should feel invisible to users. The best implementation is the one that is operationally reliable and academically transparent.