Many of us are familiar with a sandbox environment: it's an area where you can “play around” and test out a solution before implementing it into production. For CRM solutions like Salesforce, the sandbox environment is a major part of the deployment process, yet for Eloqua users, it is rarely utilized. According to a recent poll in Eloqua’s Topliners community, over half of Eloqua’s users make changes right in production, and less than 15% use the sandbox for all configuration changes. Let’s look at the differences between the two options, and why the majority of Eloqua users choose to forgo the sandbox.

What does the Eloqua sandbox do?

While the sandbox capabilities for Eloqua may not be as robust as those from other cloud solutions, with each release the Eloqua sandbox becomes a more appealing feature. When Eloqua first offered a sandbox environment, it began as a separate instance altogether. The fall release brought us the ability to refresh the sandbox (replicate the production instance), but Eloqua still lacks the ability to push changes into production. I suspect we’ll see this capability in the near future. 

When should you use the sandbox?

Not every change made to the system needs to go through a release cycle. For example, assets like campaigns, forms, landing pages, and emails are not usually good candidates of a sandbox to production push. 

As a rule of thumb, whenever the changes made in Eloqua will affect other systems, it is best to pass those alterations through the sandbox environment. Don't overlook minor changes, the removal of a field mapping could break your entire integration. For example, if you delete a field in Eloqua required in Salesforce, you could accidentally hinder your lead capture at the expense of possible business.

What if you don't have an Eloqua sandbox?

The majority of Eloqua clients do not have a sandbox environment to test changes. If you fall under this category—don’t worry—there are still ways to test configuration changes without the fear of breaking existing functionality. Here are four ways to make changes safely in a non-sandbox instance: 

1. Synch Eloqua production with your CRM sandbox
   
   One of Eloqua’s value propositions is that it can synch with various systems, including more than one instance of your CRM tool. If you are working without an Eloqua sandbox, take advantage of this and connect Eloqua to your CRM sandbox environment.
   
   
   
   This will take some investment, as you will want to mimic your product integration for your sandbox. This means new internal events and new external calls (what sends data into your CRM) configured with the sandbox user. Next, you’ll need to copy your integration programs and change all integration steps to point to your sandbox environment.
   
   
   
   Once you've set this up, you can test changes to your integration, such as the addition of a field, before going live. 
   
    
2. Copy assets before making live changes
   
   When you're making changes to assets, it's best to make a copy, and not change the live asset. There is no revision history in Eloqua, so you can't count on "undo."
   
   
   
   Make duplicates of your forms and landing pages if you're planning to make changes. The last thing you want to do is miss out on a form submit which could result in a loss of business. You are better off testing on copied assets and then either sunsetting the live asset for the test asset, or mimicking the changes. This is also true with programs: you can copy them without the feeders (what pulls members through) and test the flow. 
   
    
3. Create test fields
   
   The danger of making changes to live processes is that you risk losing or overwriting data in live fields. Try creating new test fields and running your programs against those.
   
   
   
   For example, when you are testing a new lead scoring program, create new fields for your lead scores and create new test update rules to update the new fields. That way you can run your entire database and analyze your distribution or verify use cases without creating a data disaster.
   
   
   
   Use this same tactic for any process that uses update rules, like processing steps on a form. 
   
    
4. Run use cases first
   
   It's so simple, but often forgotten. Come up with use cases before doing any development or configuration. This will help you map your expected results and communicate why you're making the changes. These use cases and test scripts will be a guide throughout the planning, implementing, and testing/validating.

And there you have it: four ways to safely make changes in a non-sandbox instance. If you have any other tips & tricks to add, please your comments below. 

See how to ignite a digital marketing strategy in your organization with Bluewolf’s free guide, The Three Pillars of Modern Digital Marketing.