Sandbox Environment
Availability: The sandbox feature is currently deactivated for all organizations while it is being refined (LMS-583). The settings page and sandbox access are disabled until it returns; this guide describes the feature as it will work when re-enabled.
Who this guide is for: Tenant administrators who want to test configuration changes, new content, or integrations before rolling them out to learners in production.
Overview
The EmbayLMS sandbox is an isolated copy of your production portal that you can use for testing without risk. Changes in the sandbox have no effect on your live environment and do not touch real learner data. Use it to safely test new courses, SSO configurations, branding changes, webhook integrations, or any setting before applying it to production.
Prerequisites
- Super Admin or Tenant Admin role
- Sandbox feature enabled on your plan (available on Professional and Enterprise plans)
1 - What the Sandbox Is
The sandbox is a fully isolated copy of your portal configuration. It runs on a separate subdomain (e.g., sandbox-acme.embaylms.com) and uses separate infrastructure. Nothing you do in the sandbox affects your production environment, and vice versa.
The sandbox is refreshed on demand - you copy your current production configuration into it whenever you need a fresh baseline. It does not stay in sync with production automatically.
2 - Accessing the Sandbox
- Navigate to Admin Panel > Settings > Sandbox.
- Click Open sandbox. You will be taken to your sandbox portal URL (e.g.,
https://sandbox-acme.embaylms.com). - Log in with your admin credentials. Sandbox admin accounts use the same password as production (copied on the last refresh). If you refreshed the sandbox recently, use your current production password.
Bookmark the sandbox URL. You can also access the sandbox directly by navigating to
https://sandbox-[your-tenant-slug].embaylms.com.
3 - Logging In to the Sandbox
The sandbox supports both password login and SSO login.
- Password login: Use your EmbayLMS admin email and password.
- SSO login: If your production portal uses SSO, the sandbox replicates the SSO configuration from your last refresh. You can test SSO end-to-end in the sandbox using real IdP credentials. Note that your IdP may need a separate application entry for the sandbox redirect URI (see section 6 - Limitations).
4 - Refreshing the Sandbox
A sandbox refresh copies your current production configuration into the sandbox, giving you a clean baseline that mirrors your live setup.
4.1 Trigger a refresh
- Navigate to Admin Panel > Settings > Sandbox.
- Click Refresh sandbox.
- Review the confirmation dialog listing what will and will not be copied.
- Click Confirm refresh.
The refresh runs as a background job and typically completes within 5 minutes. You receive an email notification when it is done.
Warning: Refreshing overwrites all existing sandbox data - any test content, test users, or configuration changes you made in the sandbox since the last refresh will be lost.
4.2 What gets copied in a refresh
| Data type | Copied to sandbox |
|---|---|
| Branding (colors, logo, fonts, custom CSS) | Yes |
| Course structures, modules, and content metadata | Yes |
| SCORM/xAPI package files | Yes |
| Roles and permission definitions | Yes |
| Group definitions (names, dynamic rules) | Yes |
| SSO/SAML/OIDC configuration | Yes |
| Email notification templates | Yes |
| Custom domain configuration | Yes (sandbox uses its own domain) |
| Webhook endpoint URLs | Yes (see limitations - sandbox sends to test endpoints) |
| API key definitions | No (new sandbox API keys are generated) |
| User accounts | Admin accounts only (no learner or employee data) |
| Learner enrollment records | No |
| Completion and assessment data | No |
| Personal data (names, emails beyond admins) | No |
| Billing information | No |
Why learner data is excluded: The sandbox is a safe testing environment. Copying real learner data (enrollments, progress, PII) would create an unnecessary duplicate of personal information. Sandbox testing uses synthetic test accounts.
5 - Best Practices
Test new courses before publishing Upload and validate your SCORM package in the sandbox first. Confirm the completion trigger is set correctly, the content launches without errors, and the progress saves between sessions. Then upload to production with confidence.
Test branding changes Apply new colors, fonts, or logo changes in the sandbox before rolling to production. Confirm the changes look correct on the login page, dashboard, and email templates.
Test SSO configuration Whenever you change your SSO settings (new IdP certificate, updated attribute mappings, new OIDC app), apply and test in the sandbox first. A broken SSO configuration in production locks out all SSO users.
Test webhook integrations Point your webhook endpoint to a test URL (e.g., a RequestBin or your staging HRIS endpoint) and trigger test events in the sandbox to confirm your integration handles the payloads correctly.
Test role and permission changes Create test user accounts in the sandbox with the new role configuration and verify the access boundaries before applying to production.
6 - Sandbox Limitations
The sandbox is designed for configuration and content testing, not production use. The following limitations apply:
| Feature | Sandbox behavior |
|---|---|
| Email delivery | All outbound emails are redirected to a test inbox. Emails do not reach real learner addresses. View captured emails at Admin Panel > Settings > Sandbox > Test inbox. |
| Stripe / Payments | Stripe is in test mode. Use Stripe test card numbers only. No real charges occur. |
| Webhooks | Webhook calls are sent to the endpoints configured in the sandbox. After a refresh, these are copied from production - update them to point to test/staging endpoints before testing. |
| SCORM content delivery | Served from a separate CloudFront distribution. Performance may differ slightly from production. |
| API keys | New API keys are generated on each refresh. Production API keys do not work in the sandbox. |
| SSO / IdP redirect URIs | The sandbox uses a different redirect URI (https://sandbox-[slug].embaylms.com/api/auth/callback/[provider]). Add this URI to your IdP application for SSO testing to work. |
| Custom domain | The sandbox does not use your production custom domain. It is always accessible at https://sandbox-[slug].embaylms.com. |
| Data persistence | Sandbox data is wiped on each refresh. Do not use the sandbox to store anything you need long-term. |
| Concurrent users | The sandbox is not sized for load testing. Do not run load or stress tests against the sandbox. |
Configuration Reference
| Setting | Location | Description | Default |
|---|---|---|---|
| Sandbox URL | Settings > Sandbox | Read-only. URL of your sandbox portal. | sandbox-[slug].embaylms.com |
| Last refreshed | Settings > Sandbox | Timestamp of the most recent sandbox refresh. | - |
| Test inbox | Settings > Sandbox > Test inbox | View all outbound emails captured by the sandbox | - |
| Sandbox admin accounts | Copied from production on refresh | Admin user accounts available in sandbox | Production admin accounts |
Troubleshooting
Sandbox refresh failed Check Admin Panel > Settings > Sandbox > Refresh history for the error details. Common causes:
- A SCORM package file failed to copy (usually due to a temporary S3 availability issue). Retry the refresh.
- The previous sandbox session was still active. Wait 5 minutes and retry.
If the problem persists, contact EmbayLMS support with your tenant slug and the approximate refresh time.
I cannot log in to the sandbox The sandbox admin accounts are copied from production at refresh time. If you changed your production password after the last refresh, use the older password, or request a password reset from the sandbox login page.
SSO is not working in the sandbox
Confirm you have added the sandbox redirect URI to your IdP application (see section 6 - Limitations). The sandbox redirect URI is https://sandbox-[slug].embaylms.com/api/auth/callback/[provider].
Emails sent in the sandbox are reaching real users All sandbox emails should be captured in the test inbox. If real emails are leaking, navigate to Admin Panel > Settings > Sandbox and confirm the sandbox is in sandbox mode (the status indicator should show “Sandbox - email capture active”). If it shows otherwise, contact EmbayLMS support immediately.
Changes I made in the sandbox disappeared The sandbox was refreshed, which overwrites all sandbox-specific changes. Check the refresh history to confirm. Going forward, complete your testing before the sandbox is refreshed.