A Sandbox, also known as a second instance, staging, or development environment, is a separate site designed for developing, testing, and experimenting without affecting your live production site. Key reasons to use a Sandbox include:
Frequent Intranet Changes: Ideal for testing new widget templates, troubleshooting, and developing APIs and integrations without risking the stability of your production environment.
Platform Updates: Test new features and updates before they go live on your production site.
On-Premise Customers: Essential for validating changes in hardware, infrastructure, or applications to ensure they don't adversely affect your live environment.
A Sandbox is initially a clone of your production environment. Key modifications are made to ensure it functions properly as a development space:
User Restrictions: Only users with Site Administrator roles (or a designated Sandbox Administrator role) will have access. If needed, discuss additional user access with your Client Success Manager (CSM).
Email Restrictions: Email sending is disabled to prevent unintended communications to your users.
Login Settings: SAML-based auto-login is disabled to allow login with a username and password, ensuring secure access to your Sandbox.
When configuring your Sandbox, pay attention to the following:
User Permissions: Adjust these as necessary for your testing purposes.
Single Sign-On (SSO): Reconfigure the sign-out URL and other settings to suit your Sandbox. If necessary, re-enable SAML auto-login after initial setup.
Email Settings: Adjust these to avoid unwanted emails and ensure your email testing does not impact your user base.
Integration Testing: Update settings to ensure integrations work correctly without affecting live operations.
A Sandbox Refresh involves replacing your Sandbox with a fresh clone of your production site. Generally, you're entitled to one refresh per calendar year unless your contract states otherwise.
Before requesting a refresh, ensure:
No ongoing projects in the Sandbox need preserving, as Axero cannot restore lost data post-refresh.
Users active in the Sandbox are prepared for the upcoming refresh and any permission changes.
To request a Sandbox Refresh, submit a case to Axero with the following:
Sandbox and Production URLs
Confirmation of readiness for a complete refresh
Preferred schedule for the refresh
Any unique roles to keep active
Governance: Establish rules on how your Sandbox is used to maintain its effectiveness as a testing environment. Document ongoing changes and use a private space on your production site to manage Sandbox governance.
User Management: Limit active users primarily to necessary administrators. Use personas and roles to manage access efficiently. Create Sandbox-specific logins if needed.
Email Testing: Be cautious with email settings to prevent impacting deliverability on your live site.
Integrations: Regularly review and adjust integrations as necessary, ensuring they replicate the live environment as closely as possible without disrupting normal operations.
By following these guidelines, you can maximize the effectiveness of your Sandbox environment for development, testing, and experimentation.
is requesting access to a wiki that you have locked: https://my.axerosolutions.com/spaces/5/axero-documentation/wiki/view/100416/managing-your-sandbox
Your session has expired. You are being logged out.