Hi everyone - 

I recently crowdsourced the Gainsight Admin community to ask for some best practices regarding best practices for managing a Gainsight sandbox. I got some helpful thoughts, and along with an assist from ChatGPT, came up with the following 8 best practices. By all means, do not consider this a final list! I’d love to hear what I missed or if anything needs to be tweaked. We’re all constantly learning here .

1. Use Sandbox for Testing Only 

• Only use Sandbox for: 
  • Testing new rules, playbooks, layouts, and configurations 
  • Training new admins or CSMs 
  • QA before deploying to production 

Never test in production if the change has risk — even small changes (e.g., to Rules or Permissions) can cascade widely. If we absolutely must test in production (due to data limitations in Sandbox, for example), then test on a Company record that is only meant for testing.

2. Establish a Promotion Process 

Have a clearly documented change control process: 

• Develop and test in sandbox. 
• Use a change log or ticket system (e.g., Jira) to track what was built. 
• Have another admin review before moving to production. 
• Promote manually into production using the UI or the X-Org migration tool. We must be diligent about keeping parity, especially with MDA objects, as those have tons of dependencies. 

3. Label Everything as Sandbox 

• Name rules, reports, and dashboards with a rSBX] or TEST - prefix to avoid confusion. 
• You don’t want users or admins mistaking sandbox items for live ones. 

4. Test with Realistic Data 

• Load anonymized or partial real data into MDA for realistic testing.
• You can use Data Designer or S3 ingest to simulate production-like data flows.
  • Note: This will unfortunately not apply to Salesforce data, as we are reliant on the Salesforce team’s refresh schedule, which doesn’t always align with ours. Hopefully limited Salesforce data won’t hamstring us too much when testing processes. For everything else though, we should either be able to test on what’s already in the MDA or can export from production into the appropriate MDA object(s) if necessary. 

5. Use Feature Flags Safely 

• If testing new features (e.g., with Gainsight support or early access), isolate them in sandbox first. 
• Coordinate with Gainsight Support if you need beta or limited-release features enabled. 

6. Clean Up Regularly 

• Delete stale test data, rules, fields, and assets to keep the sandbox uncluttered. 
• Archive anything you want to save but no longer actively use. 

7. Restrict User Access 

• Only give admins or power users access to sandbox.
• Prevent confusion or mis-testing by limiting the audience.

8. Communicate! 

• Keep track of sandbox-only features or experimental setups that may not yet exist in production. 
• Let your fellow Admin(s) know when you are testing something in Sandbox that involves any changes to assets – even if seemingly minor.  
  • For example, if you want to quickly test something that involves adding a field to the Company object in Sandbox, that may seem harmless, but if your fellow admin is migrating a rule that sources the Company object, it will add that new field to Production, which may not be what either of you want.