Using Magentrix Sandbox Environments for Testing

    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:

    1. Contact your account manager for a quote and pricing information
    2. 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:

    1. Contact Magentrix support with your cloning request
    2. Specify any special considerations (timing, data sensitivity, etc.)
    3. The support team will schedule and perform the cloning process
    4. 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:

    « Previous ArticleNext Article »


    0.0 (0)


    Comments

    No records to display

    Subscription
    Follow Knowledge posts
    Please enter your email address to subscribe:

    Email:
    Subscribe