A Magentrix Sandbox is a separate testing environment that functions identically to your production portal. It provides a safe space where administrators can test configurations, develop customizations, and validate changes before deploying them to your live production environment. This ensures that modifications work correctly and don't negatively impact real users.
What is a Sandbox Environment?
A Sandbox environment is an optional add-on that serves as a snapshot of your production portal at a specific point in time. It operates completely independently from your production environment, allowing you to:
- Test configurations safely: Make changes without affecting live users
- Develop customizations: Build and test custom code, workflows, and automations
- Validate new features: Ensure new functionality works as expected before deployment
- Train administrators: Practice administrative tasks without risk
- Test integrations: Verify CRM connections and data synchronization
The Sandbox connects to your CRM sandbox environment (if you have one in Salesforce, Microsoft Dynamics, or HubSpot), allowing you to test the complete integration workflow without touching production data.
How Sandbox Differs from Production
What's the Same
- All features and modules available in production
- Identical structure including custom objects, fields, and workflows
- Same user interface and functionality
- Connected to your CRM sandbox (mirroring your production CRM connection)
What's Different
- Operates independently: Changes in Sandbox don't affect production
- Email communications disabled: Magentrix automatically disables all email communications in Sandbox environments by default to prevent accidental emails to real users
- Separate data: User data and content exist only in the Sandbox after cloning
- Custom Hubs not supported: Custom Hub configurations are not available in Sandbox environments
- Manual deployment required: Tested changes must be explicitly deployed to production by Magentrix support
Email Communications in Sandbox
Critical Protection Feature: As of October 2024, Magentrix disables all email communications in newly created Sandbox environments by default. This automatic protection prevents accidental emails to real users during testing activities.
Important Note: Sandbox environments created before October 2024 do not have emails automatically disabled. If you have an older Sandbox, email notifications will still function unless you manually disable them.
What's disabled (for Sandboxes created after October 2024):
- User activation emails
- Workflow notification emails
- Automated system emails
- Custom email triggers
- All other email communications
For newer Sandboxes, this ensures your testing activities cannot accidentally send emails to real partners, customers, or employees. You can test email workflows and configurations, but the emails will not actually be sent.
Best Practice for All Sandboxes: Regardless of when your Sandbox was created, we strongly recommend that you do not use real email addresses. Use test email addresses (like test@yourcompany.com
or dummy addresses) to avoid any potential issues and to clearly distinguish test data from production data.
If you have an older Sandbox: If your Sandbox was created before October 2024 and emails are still enabled, you should either manually disable email workflows and notifications before testing, or contact Magentrix support to have them disable all email communications for your Sandbox environment. This will bring your older Sandbox in line with the current standard and prevent accidental emails to real users.
What Can Be Deployed from Sandbox to Production
When you've tested changes in your Sandbox and are ready to deploy them to production, the Magentrix team can package and deploy certain structural changes:
Deployable Items
These can be packaged and transferred by Magentrix support:
- Custom objects and fields: New entities and field definitions you've created
- Workflows and automation rules: Business process automations and triggers
- Custom code and applications: Active Pages, custom logic, and integrations
- System configuration changes: Structural platform modifications
Non-Deployable Items
These must be manually recreated in production:
- User Management: Security roles, user accounts, and user permissions
- User Data: All user-generated content and activity data
- Learning Content: Courses, learning paths, and training materials
- Content: Engagement Pages and FAQ articles
- Themes and Branding: Visual themes, branding elements, and styling
- Custom Hub Configurations: Not supported in Sandbox environments at all
Why manual recreation? These elements are often highly customized, contain user-specific data, or require careful migration to ensure they align with your current production configuration. Manual recreation ensures compatibility and gives you control over the deployment process.
Recommended Administrator Workflow
Follow this workflow to minimize risk and ensure successful deployments:
Best Practice: Test First, Deploy Second
Step 1: Make Changes in Sandbox
- Develop and configure all structural changes in your Sandbox environment
- Build custom objects, fields, workflows, or code modifications
- Test thoroughly with realistic scenarios
Step 2: Test Thoroughly
- Validate that functionality works as expected
- Test edge cases and error conditions
- Verify integrations with CRM sandbox
- Have other administrators or power users review and test
Step 3: Request Deployment
- Contact Magentrix support with deployment request
- Provide detailed information about what changes need to be deployed
- Schedule deployment during an appropriate maintenance window
- The support team handles the technical deployment process
Step 4: Manual Recreation
- Manually recreate content, users, and configurations that cannot be packaged
- Verify all elements work correctly in production
- Test the complete workflow in production with a small group before full rollout
This workflow minimizes risk to your live environment and ensures changes work properly before affecting real users.
Purchasing a Sandbox Environment
Sandbox environments are available as an optional add-on to your Magentrix subscription.
To purchase a Sandbox:
- Contact your account manager for a quote and pricing information
- Alternative: Open a support ticket, and the support team will connect you with the accounts team
The cost of a Sandbox is separate from your production license and provides ongoing access to a testing environment for the duration of your subscription.
Cloning Production to Sandbox
You can request a fresh clone of your production portal into your Sandbox environment at any time. Cloning creates a snapshot of your current production environment and copies it to Sandbox.
When to Clone
Consider cloning your production portal to Sandbox when:
- Starting a major project: You want to test against current production data and configuration
- Sandbox has diverged significantly: Your Sandbox no longer resembles production due to extensive testing
- Testing requires current data: You need up-to-date structures, workflows, or configurations
- Beginning a new development phase: You want a clean starting point that matches production
How to Request Cloning
To clone your production portal:
- Contact Magentrix support with your cloning request
- Specify any special considerations (timing, data sensitivity, etc.)
- The support team will schedule and perform the cloning process
- You'll be notified when the cloning is complete
Important: Cloning overwrites your current Sandbox environment. Any changes you've made in Sandbox since the last clone will be lost. If you have work in progress in Sandbox, coordinate with Magentrix support before requesting a clone.
Custom Hubs and Sandbox
Custom Hubs are not supported in Sandbox environments. If your production portal uses Custom Hubs, you'll need alternative approaches for testing:
- Test hub functionality in production: Make carefully controlled changes during low-traffic periods
- Work with Magentrix support: Discuss alternative testing approaches for hub-specific functionality
- Focus sandbox testing on other areas: Use Sandbox primarily for testing non-hub features and configurations
This limitation exists because Custom Hubs require specific DNS and hosting configurations that cannot be replicated in Sandbox environments.
Deploying Changes to Production
When you've completed testing and are ready to deploy changes to production, follow this process:
Requesting Deployment
Step 1: Contact Magentrix Support
- Open a support ticket or email support@magentrix.com
- Provide your deployment request with detailed information
Step 2: Specify What to Deploy
- List all structural changes you want deployed (custom objects, fields, workflows, code)
- Identify any dependencies or prerequisites
- Clarify what should NOT be deployed
Step 3: Schedule Deployment
- Work with the support team to schedule during an appropriate maintenance window
- Consider user activity patterns and business hours
- Plan for testing time after deployment
Step 4: Support Handles Deployment
- The Magentrix support team packages and deploys your tested changes
- They verify the deployment completed successfully
- You're notified when deployment is complete
Step 5: Post-Deployment Tasks
- Manually recreate users, content, themes, and other non-deployable items
- Test all functionality in production
- Verify integrations and workflows work correctly
- Monitor for any unexpected issues
Deployment Timeline
Deployment timing depends on:
- Complexity of changes being deployed
- Current support team workload
- Your requested deployment window
- Any custom code or complex configurations
Work with support to set realistic expectations for deployment timing.
Best Practices for Sandbox Usage
Regular Testing
- Use your Sandbox for all significant changes before implementing in production
- Don't skip Sandbox testing even for "small" changes - unexpected issues can arise
- Test with realistic scenarios that mirror actual user workflows
Documentation
- Keep detailed records of changes made in Sandbox
- Document what needs to be manually recreated in production
- Maintain a change log for tracking what's been deployed and when
User Training
- Use Sandbox to train internal staff on new features before rolling them out to external users
- Allow administrators to practice complex configurations in a safe environment
- Test training materials and documentation using Sandbox
Change Management
- Establish internal processes for who can make Sandbox changes
- Define approval processes for deployment requests
- Coordinate with stakeholders before deploying changes to production
Fresh Cloning Strategy
- Periodically clone production to Sandbox to ensure testing against current data
- Plan cloning around major development projects
- Balance the need for current data with work in progress in Sandbox
Testing Checklist
Before requesting deployment, verify:
- ✓ All functionality tested and working correctly
- ✓ Edge cases and error conditions considered
- ✓ CRM integration tested (if applicable)
- ✓ Multiple administrators have reviewed changes
- ✓ Documentation prepared for manual recreation steps
- ✓ Production deployment timing planned
- ✓ Rollback plan prepared in case of issues
Troubleshooting Common Issues
Issue: Changes I made in Sandbox aren't in production
Solution:
- Sandbox and production operate independently - changes don't automatically sync
- You must explicitly request deployment through Magentrix support
- Some elements (content, users, themes) must be manually recreated
- Verify you've completed both deployment request and manual recreation
Issue: I can't test Custom Hub functionality in Sandbox
Solution:
- Custom Hubs are not supported in Sandbox environments
- Test Custom Hub changes directly in production during low-traffic periods
- Work with Magentrix support for alternative testing approaches
- Focus Sandbox testing on non-hub functionality
Issue: Email workflows aren't working in Sandbox
Solution:
- For Sandboxes created after October 2024, this is expected behavior - Magentrix disables all emails by default
- For Sandboxes created before October 2024, emails may still be enabled
- You can test email configurations, but emails won't actually send (in newer Sandboxes)
- Test email functionality in production with test accounts after deployment
- If you have an older Sandbox with emails still enabled, manually disable workflows or contact support to disable emails
- This protection prevents accidental emails to real users
Issue: My Sandbox has old data that doesn't match production
Solution:
- Request a fresh clone of production to Sandbox
- Contact Magentrix support to schedule the cloning
- Note that cloning will overwrite your current Sandbox environment
- Save any important in-progress work before requesting a clone
Issue: Users in Sandbox are receiving emails
Solution:
- If your Sandbox was created before October 2024, emails are not automatically disabled
- For older Sandboxes, manually disable email workflows and notifications to prevent accidental sends
- Contact Magentrix support to request email disabling for your Sandbox environment
- For Sandboxes created after October 2024, emails should be disabled by default - contact support if emails are being sent
- Verify you're working in Sandbox and not accidentally in production
Issue: Deployment didn't include all my changes
Solution:
- Review the deployment request - you may not have specified all changes
- Some elements cannot be packaged and must be manually recreated
- Contact support to clarify what was deployed and what needs manual recreation
- Refer to the "What Can Be Deployed" section to understand limitations
Issue: Production broke after deployment
Solution:
- Contact Magentrix support immediately for assistance
- Provide specific details about what's not working
- Support can help troubleshoot or roll back changes if necessary
- This is why testing thoroughly in Sandbox before deployment is critical
Understanding Deployment Scope and Limitations
What the Magentrix Team Deploys
When you request deployment, the Magentrix support team:
- Packages structural changes from your Sandbox
- Deploys custom objects, fields, workflows, and code
- Verifies the technical deployment completed successfully
- Ensures no errors during the deployment process
What You Must Handle
After deployment, you are responsible for:
- Manually recreating users, security roles, and permissions
- Creating content (Engagement Pages, FAQs, articles)
- Configuring themes and branding
- Setting up learning content and courses
- Testing all functionality in production
- Training users on new features
- Monitoring for issues after deployment
This division ensures that customizations are deployed correctly while giving you control over user-facing elements and content.
Related Topics
For more information about Sandbox environments and related topics, see: