Sandbox Environments

Sandbox environments in SalesOS provide isolated copies of your organization where administrators can safely experiment with configuration changes, test new workflows, validate automations, and train team members -- all without any risk to your live production data or settings. Changes validated in a sandbox can then be deployed to production with confidence.

What Sandboxes Are

A sandbox is a separate, fully functional instance of your SalesOS organization that operates independently from your production environment. Think of it as a safe testing ground where:

• Configuration changes (custom fields, pipelines, automations) can be tested before going live.
• New workflows can be validated end-to-end without affecting real deals or contacts.
• Team members can be trained on new processes using realistic (but non-production) data.
• Integrations can be connected and tested without triggering real actions in third-party systems.
• Experimental changes can be explored and discarded without consequence.

Sandboxes are particularly valuable for organizations with complex configurations, strict compliance requirements, or large teams where an untested change could disrupt daily operations.

Creating a Sandbox

Only administrators can create sandboxes. The number of sandboxes available depends on your SalesOS plan.

To create a sandbox:

1. Navigate to Settings > Sandboxes from the admin panel.
2. Click Create Sandbox.
3. Provide a name for the sandbox (for example, "Q3 Workflow Testing" or "New Pipeline Staging").
4. Select the sandbox type (see below).
5. Optionally add a description explaining the purpose of this sandbox.
6. Click Create.

Sandbox creation takes a few minutes depending on the type and the size of your organization's data. You receive a notification when the sandbox is ready.

Sandbox Types

SalesOS offers two sandbox types to accommodate different testing needs.

Full Copy Sandbox

A full copy sandbox replicates both your configuration and a snapshot of your production data.

What is included:

• All organization settings and preferences.
• Custom fields, pipelines, stages, and field configurations.
• Automation rules, workflows, and approval workflows.
• Email templates and sequences.
• Products, price books, and pricing rules.
• A snapshot of records: accounts, contacts, leads, deals, quotes, orders (up to a configurable record limit).
• Team structure, roles, and permission settings.
• Integration configurations (credentials are excluded for security).
• Gamification settings and challenge definitions.
• Custom objects and their schemas.

What is NOT included:

• Integration credentials and API keys (must be re-entered or connected to test endpoints).
• File attachments and documents (references exist but files are not copied to reduce storage).
• Audit trail and activity history older than 30 days.
• Real email sending capability (emails are captured in a sandbox outbox instead of sent).

Best for: End-to-end testing of workflows that need realistic data, training new team members, testing reports and analytics with real data patterns.

Configuration-Only Sandbox

A configuration-only sandbox copies your settings, schemas, and rules but does not include any record data.

What is included:

• All organization settings and preferences.
• Custom fields, pipelines, stages, and field configurations.
• Automation rules, workflows, and approval workflows.
• Email templates and sequences.
• Products, price books, and pricing rules.
• Team structure, roles, and permission settings.
• Integration configurations (credentials excluded).
• Custom objects and their schemas.
• Gamification settings.

What is NOT included:

• Any CRM records (accounts, contacts, leads, deals, quotes, orders).
• Activity history and notes.
• File attachments.
• Audit trail.
• Integration credentials.

Best for: Testing configuration changes in isolation, building and validating new automations from scratch, evaluating custom field or pipeline changes without data clutter.

Choosing Between Types

Working in a Sandbox

Once your sandbox is created, you access it through the sandbox switcher.

Accessing a Sandbox

1. Click the environment indicator in the top navigation bar (it displays "Production" by default).
2. Select the sandbox you want to enter from the dropdown.
3. The page reloads in the sandbox context. A prominent banner at the top of every page indicates you are in a sandbox environment, showing the sandbox name and a colored border to prevent confusion with production.

Testing Automations and Workflows

Sandboxes are ideal for testing automations before deploying them to production:

1. Enter the sandbox.
2. Create or modify an automation rule (for example, "When a deal moves to Negotiation, create an approval request").
3. Create a test record (or use existing data in a full copy sandbox) and trigger the automation.
4. Verify the automation executed correctly by checking the automation log.
5. Test edge cases -- what happens if required fields are missing, if the owner is inactive, or if the approval is rejected.
6. Once satisfied, note the configuration and replicate it in production (or deploy via change set).

Testing Approval Workflows

Approval workflows often have complex routing logic. Test them in a sandbox to ensure:

• Requests route to the correct approver based on deal size, region, or discount level.
• Escalation rules trigger correctly when approvals are not actioned within the time limit.
• Rejection flows properly notify the submitter and reset the record state.
• Parallel and sequential approval chains resolve in the correct order.

Testing Custom Fields and Objects

Before adding custom fields to production (which affects every user immediately):

1. Create the custom field in the sandbox.
2. Test that it appears correctly on record pages, list views, and reports.
3. Verify that any automations referencing the field work correctly.
4. Check that required field validation behaves as expected.
5. Confirm that the field exports correctly in CSV and API responses.

Testing Pipeline Changes

Restructuring pipelines (adding, removing, or reordering stages) can disrupt active deals. In a sandbox:

1. Modify the pipeline structure.
2. Verify that existing deals (in a full copy sandbox) map correctly to new stages.
3. Test that probability percentages and forecast calculations update correctly.
4. Confirm that stage-based automations trigger on the correct transitions.
5. Verify that reports and dashboards reflect the new structure accurately.

Email Behavior in Sandboxes

To prevent sandbox testing from sending real emails to customers:

• All outbound emails in a sandbox are intercepted and stored in a Sandbox Outbox instead of being delivered.
• You can view intercepted emails from Settings > Sandbox Outbox within the sandbox.
• Each intercepted email shows the intended recipient, subject, body, and any attachments.
• This allows you to verify that email templates, sequences, and notifications render correctly without risking accidental customer communication.

Deploying Changes to Production

Once you have validated changes in a sandbox, you need to move them to production. SalesOS supports two approaches.

Change Sets

Change sets allow you to package specific configuration changes and deploy them as a unit.

1. In your sandbox, navigate to Settings > Change Sets.
2. Click New Change Set.
3. Give it a name (for example, "Q3 Pipeline Restructure").
4. Add components to the change set by browsing available changes:
   • Custom fields (new or modified).
   • Pipeline and stage configurations.
   • Automation rules.
   • Approval workflows.
   • Email templates.
   • Product and pricing changes.
5. Review the change set summary, which shows exactly what will be created or modified in production.
6. Click Deploy to Production.
7. Confirm the deployment. Changes are applied to production immediately.

Change sets include a rollback capability -- if something goes wrong, you can revert the change set within 24 hours.

Manual Replication

For simple changes, you may prefer to manually replicate the configuration in production:

1. Document the exact settings configured in the sandbox (screenshots, notes, or the change log).
2. Switch to the production environment.
3. Apply the same settings manually.
4. Verify that the production configuration matches what you tested in the sandbox.

Manual replication is appropriate for one or two simple changes. For larger or more complex changes, always use change sets to reduce human error.

Deployment Best Practices

• Deploy during low-activity hours. While most configuration changes are non-disruptive, deploying during off-hours minimizes the chance of conflicts with active users.
• Communicate changes to the team. Send a brief notification before and after deployment so users are aware of new fields, stages, or workflows.
• Verify after deployment. After deploying a change set, spot-check the affected areas in production to confirm everything works as expected.
• Keep a deployment log. Record what was deployed, when, by whom, and from which sandbox. This helps with troubleshooting and audit trails.

Sandbox Refresh and Reset

Over time, a sandbox may become stale (its data no longer reflects production) or cluttered (filled with test records that make further testing confusing). SalesOS provides refresh and reset options.

Refresh

Refreshing a sandbox replaces its contents with a fresh copy from production.

1. Navigate to Settings > Sandboxes.
2. Find the sandbox you want to refresh and click the three-dot menu.
3. Select Refresh.
4. Confirm the action. Note that refreshing destroys all current sandbox data and configuration, replacing it entirely with a new copy from production.
5. The refresh process takes a few minutes. You receive a notification when complete.

When to refresh:

• Your sandbox data is significantly out of date and you need current records for testing.
• A major production update was deployed outside the sandbox and you need to test further changes on top of it.
• The sandbox has accumulated too many test records and is difficult to work with.

Reset

Resetting a sandbox clears all data and configuration changes, returning it to a clean state matching production at the time of reset.

1. Navigate to Settings > Sandboxes.
2. Click the three-dot menu on the target sandbox.
3. Select Reset.
4. Choose between:
   • Reset to production -- Same as refresh; copies current production state.
   • Reset to empty -- Removes all data but keeps the sandbox shell. Useful if you want to start testing from a blank slate.

Refresh Limits

Depending on your plan, sandbox refreshes may be limited:

Refresh counts reset on the first of each month.

Access Control

Sandbox access is governed by your organization's role structure.

Who Can Create Sandboxes

• System Admins -- Can create, refresh, reset, and delete any sandbox.
• Managers -- Can create sandboxes (subject to plan limits) but cannot delete sandboxes created by other managers or admins.
• Users and Viewers -- Cannot create sandboxes.

Who Can Access Sandboxes

By default, all sandboxes are accessible to admins and the user who created them. Admins can grant access to additional users:

1. Open Settings > Sandboxes.
2. Click on the sandbox name to open its settings.
3. Under Access, add users or roles who should be able to enter this sandbox.
4. Options include:
   • All admins (default).
   • Specific users (by name).
   • All managers.
   • All users (for training sandboxes).

Permissions Within a Sandbox

Users retain their production role and permissions inside a sandbox. An admin in production is an admin in the sandbox; a viewer in production is a viewer in the sandbox. This ensures that permission-related testing reflects real-world behavior.

Exception: the sandbox creator always has admin access within their own sandbox, regardless of their production role. This allows managers to test admin-level configurations.

Limitations and Known Differences from Production

While sandboxes are designed to mirror production as closely as possible, some differences exist:

Functional Differences

• Email delivery is disabled. All emails go to the sandbox outbox. This is intentional and cannot be overridden.
• Integration credentials are not copied. You must re-authenticate integrations within the sandbox using test credentials from third-party services.
• Webhooks fire to a sandbox endpoint. Outbound webhooks from sandbox automations are routed to a sandbox log rather than external URLs, preventing unintended actions in connected systems.
• Scheduled automations run at reduced frequency. Time-based automations in sandboxes run at most once per hour (regardless of their production schedule) to reduce resource consumption.
• API rate limits are lower. Sandbox API rate limits are 50% of production limits.

Data Differences

• Record limits. Full copy sandboxes cap at 100,000 records per object type. Organizations with more records receive a representative sample.
• File attachments are referenced but not copied. File metadata exists but actual files are not duplicated. Downloading an attachment in a sandbox returns a placeholder.
• Encryption keys differ. Encrypted fields in production are re-encrypted with sandbox-specific keys. The plaintext values are preserved but the underlying encryption is separate.

Behavioral Differences

• No production billing impact. Actions in sandboxes (for example, sending proposals or creating quotes) do not count toward production usage metrics or billing.
• Analytics and reports may show limited data. Dashboard widgets and reports that rely on historical data may show incomplete results if the sandbox does not contain the full history.
• Gamification points earned in sandboxes do not carry to production. The gamification system is active in sandboxes for testing purposes but points and badges are sandbox-local.

Sandbox Management for Admins

Monitoring Sandbox Usage

Admins can view sandbox status and usage from the Settings > Sandboxes list:

• Status -- Active, Refreshing, or Expired.
• Created by -- The user who created the sandbox.
• Created date -- When the sandbox was provisioned.
• Last accessed -- When someone last logged into the sandbox.
• Type -- Full Copy or Configuration-Only.
• Size -- Approximate storage used.

Deleting a Sandbox

To delete a sandbox you no longer need:

1. Navigate to Settings > Sandboxes.
2. Click the three-dot menu on the target sandbox.
3. Select Delete.
4. Confirm the deletion. This action is permanent and cannot be undone.

Deleted sandboxes free up your sandbox allocation for creating new ones.

Sandbox Expiration

Sandboxes that have not been accessed in 90 days are flagged for expiration. The creator and all admins receive a notification 14 days before expiration. To prevent expiration, simply access the sandbox or click Keep Active in the notification.

Expired sandboxes are automatically deleted and cannot be recovered.

Best Practices

• Always test in a sandbox first. Any configuration change that affects workflows, pipelines, custom fields, or automations should be validated in a sandbox before production deployment.
• Name sandboxes descriptively. Use names that reflect the purpose (for example, "Q3 Approval Workflow Test") rather than generic names like "Test 1". This helps when multiple sandboxes are active.
• Use configuration-only sandboxes for quick tests. If you only need to validate a field layout or automation rule and do not need real data, a configuration-only sandbox is faster to create and consumes fewer resources.
• Refresh before major testing cycles. If your sandbox is more than a week old and you are about to test changes that depend on current production data, refresh it first.
• Document your test plan. Before entering a sandbox, write down what you intend to test and what success looks like. This prevents aimless exploration and ensures you validate all scenarios.
• Test with multiple user roles. Log in as different user types (admin, manager, user, viewer) to verify that permissions and visibility work correctly for the changes you are deploying.
• Use change sets for multi-component deployments. If your change spans custom fields, an automation, and a pipeline modification, package them together in a change set to ensure they deploy atomically.
• Clean up unused sandboxes. Delete sandboxes that have served their purpose. Stale sandboxes consume plan allocations and can create confusion about which environment contains the latest tested configuration.
• Never use production credentials in sandboxes. When connecting integrations in a sandbox, always use test or sandbox credentials from the third-party provider. This prevents sandbox testing from triggering real actions in external systems.
• Coordinate sandbox use across admins. If multiple admins are testing different changes in separate sandboxes, communicate to avoid deploying conflicting changes to production simultaneously.
• Treat sandbox deployment as a release. Apply the same rigor to deploying from sandbox to production as you would to a software release -- review, communicate, deploy, verify.