As your Atomicwork setup grows — new workflows, an updated SLA, revised service catalog items — configurations become interconnected. An update to one workflow might affect how another routes requests. A change to an SLA policy might interact with escalation rules established earlier. The more sophisticated your setup, the harder it is to anticipate every downstream effect of a change.
You can now test your configuration changes in Sandbox before taking it live to production. This gives you an isolated environment that mirrors your production configuration, so you can build, test, and perfect your workflows before they go live. When you're confident everything works, you selectively promote changes back to production — with full visibility into what changed and where conflicts exist.
How Sandbox works
When you create a Sandbox, Atomicwork provisions a separate environment linked to your production account. This environment clones your existing configurations so you can experiment freely without affecting live data or workflows. The following configurations are cloned from production to sandbox:
At the account-level
Workspaces
Assistant settings
Content settings
Small talk
Acronyms
Trusted knowledge
Webhook credentials (under Security)
At the workspace-level
General settings
Request attributes
Service and incident catalogs
Forms
SLAs
Tags
Surveys
Canned responses
Knowledge (including Verified Answers, folders and files)
Approval policies
Workflows
Agents
Groups
Business hours
Any connected integrations including Slack, Teams, email configurations, Okta, Azure, etc. are not copied to the Sandbox. This prevents accidental messages or unintended pings to live channels and services.
If you need to test integrations, configure them manually in the sandbox environment.
Creating a sandbox
You need Account Admin access to create a Sandbox.
Only one Sandbox can be active per production account at any time.
Navigate to Settings > Organization > Sandbox.
Click Create sandbox.
Select the test users who should have access to the sandbox environment. These users will be able to log in to the sandbox and test configurations.
Click Create sandbox to confirm.
Atomicwork provisions the sandbox and clones your production configurations. You'll see a progress indicator while the sandbox is being set up, and receive an email notification once it's ready.
Once created, the Sandbox settings page will display when the sandbox was created, the production URL it's linked to, and who created it.
Opening and navigating the sandbox
Once your sandbox is ready, you can switch to it from the Sandbox settings page by clicking on Open sandbox.
The Sandbox opens in a new browser tab. You'll see a Sandbox badge at the top-right corner so you always know whether you're working in the sandbox environment or production.
Inside Sandbox, you can navigate and configure settings the same way you would in production — update workflows, modify SLAs, edit service catalog items, adjust forms, and more. All changes stay isolated in the sandbox environment until you explicitly promote them.
Managing test users
Test users are the people who can access and test configurations in the sandbox environment. To manage test users:
Click on Test users in the Sandbox settings page.
Click Add to search for and add users from your organization.
To remove a test user, click the menu next to their name and select Remove.
For example, if your IT team is testing a new onboarding workflow, you might add the IT admin responsible for onboarding along with a few team members who can simulate the employee experience.
All users from production are created in a disabled state in the sandbox. Only the users you explicitly add as test users can log in and interact with the sandbox environment.
Reviewing and promoting changes
After making changes in the sandbox environment, you can review them and selectively promote what's ready to production. You don't have to push everything at once — you choose exactly which changes go live.
Viewing changes ready for promotion
On the Sandbox settings page, you'll see the number of changes ready for promotion. Click on it to view the full list. Changes are grouped by when they were created — today, this week, this month, etc. Each change is tagged with its configuration type (Workflows, SLAs, Service Catalog, etc.) and the action taken:
Created — A new configuration that doesn't exist in production yet
Modified — An existing configuration that was updated in the sandbox
Deleted — A configuration that was removed in the sandbox
Click on any change to expand its details and see exactly what was modified.
Promoting changes
Select the changes you want to promote by checking them individually, or choosing Select all.
Click Promote changes.
Review the summary of what will be pushed to production. Add a description for the change set if needed.
Click on Confirm.
Only the selected changes are applied to production. Non-selected changes remain in the sandbox environment for future promotion.
For example, say you've updated three workflows and two SLA policies in the sandbox. If only the workflows are fully tested, you can promote just those three and continue refining the SLA changes before pushing them separately.
Promoted changes become live in production immediately after confirmation. Make sure you've thoroughly tested configurations in the sandbox before promoting.
Once a promotion is complete, an email with a summary of all changes pushed to production is sent to the person who promoted the changes.
Handling conflicts
A conflict occurs when the same configuration has been changed in both the sandbox and production since the sandbox was created. For example, if you update a workflow in the sandbox and someone else updates the same workflow in production, Atomicwork flags this as a conflict.
When conflicts exist, the Sandbox settings page shows the number of conflicts alongside the total number of changes.
Navigate to changes list and look for those marked with a conflict indicator.
Click on the conflicting change to see both versions — the sandbox version and the production version.
Important: Promoting a conflicting change will overwrite what's in production with the sandbox version. If you're not sure which version should be retained, skip that configuration during promotion — you can always come back and promote it later once you've confirmed.
This ensures you never accidentally overwrite a production change that happened while you were working in the sandbox environment.
Best practices
Test one set of changes at a time. Promoting smaller, focused change sets makes it easier to identify issues and roll back if needed.
Add the right test users. Include people who understand the workflows being tested — they'll catch edge cases you might miss.
Review conflicts carefully. When both sandbox and production have changed, take the time to understand both versions before choosing which one to keep.
Promote regularly. Don't let changes pile up in the Sandbox. Smaller, frequent promotions are safer than large, infrequent ones.