Sandboxes Aren’t Just for Playing Around: The Pros and Cons of Marketo & SFDC Sandbox Environments

Many of you are familiar with the Sandbox — a software concept where a replica instance of a production system, like Marketo or Salesforce, is generated so that it can be used to test out features and functionality in a harmless way.

If you are not familiar with Sandboxes, or haven’t used them extensively, keep reading for a quick primer and some pros and cons.

A quick primer

First, let’s cover some basic ins and outs of sandboxes. Sandboxes in general are typically a “snapshot,” or current copy, of your production environment. It is possible to have a sandbox that is a full copy of your production environment or a partial copy, meaning it only contains certain components of your production instance.

Sandboxes are not actively connected to your production systems in any way. By “not actively connected,” I mean that no data or processes are automated between sandbox and production; however, most sandboxes allow designated items to be moved from the sandbox to the production instance.

Most sandboxes will have a separate login from your production environment, and any changes you make in the sandbox will not be made in your production instance — unless, of course, you choose to move the change to production. The data, and any built-out functionality, will remain in the state they were in when you created the sandbox. They won’t update what you have in production until you refresh the sandbox. When you refresh a sandbox, it is understood that everything you may have changed or built in that sandbox will cease to exist and will be completely swapped for the production environment’s data and contents.

Pros of Sandboxes

Depending on how many integrations your company has in place, sandboxes can help you test new features and functionality, discover and correct any fatal flaws, and train your team members before moving into production:

• Worry-free testing: If it is not already obvious, the biggest pro of having a sandbox is that you can test things out with no threat to the live environment in your production instance. Using a Marketo sandbox, you can build and observe extensive operational programs, such as Lead Lifecycle and Lead Scoring, to determine if they are sound enough for production. An SFDC sandbox can be used to test many large-scale data and process-affecting changes in a secure way — tests that could be severely detrimental to a business if they resulted in a negative outcome within a live system.
• User Acceptance Testing: A great way to leverage sandboxes for both Marketo and SFDC is for UAT (user acceptance testing) to prepare Marketing and Sales teams for forthcoming changes to their environment, such as upgrading Marketo’s user interface to Sky or upgrading SFDC’s user interface to Lightning. In addition to large project builds and testing, a sandbox is just as useful for smaller projects or temporary proof-of-concept projects.
• Multiple sandboxes for complex environments: For companies that have ever-changing environments because of acquisitions and tech stack improvements, it is feasible to have multiple sandboxes in SFDC (we usually only see one sandbox in Marketo). A few examples of a multiple sandbox need would be:
  • Building out a new system integration (in sandbox A), while testing out new product operational impact (in sandbox B). The teams working on these projects don’t want to inadvertently affect one another until it’s time to test in conjunction before moving to production.
  • Pre-production roll-out of separate sandbox functionality testing (sandbox C).
  • By far one of the most coveted uses of a sandbox is for it to be a backup to your production environment so that when a new update rolls out to production, it is easier to roll back changes made in production should things go awry (sandbox D).

If you’re considering whether to purchase a new MarTech solution, or if you’re starting to map out how to integrate a new solution with the rest of your stack, check out our Best Practices for Evaluating and Building Out Your MarTech Stack white paper.

• Easy to move into production: It is simple to move components from your sandbox to production when ready. With a Marketo sandbox, you can move entire programs and all of their contents to Marketo production, including embedded programs, emails, landing pages, forms, smart campaigns, smart lists, static lists, and reports. With an SFDC sandbox, you package any components you want to move in a “change set” and push the change set to production where you will deploy its components. This is a huge advantage and time saver of sandboxes!

Cons of Sandboxes

Playing in a sandbox is all rainbows and butterflies, right? For all of the ways sandboxes are useful and sometimes necessary, there are some gotchas when using sandboxes that you should be aware of before jumping in:

• Dependent components: The biggest issue commonly encountered with sandboxes comes from the movement of components between sandbox and production. A failure can occur in this movement when dependent components are not available or not in the correct state within the production environment. This failure is truly an example of putting a square peg in a round hole. Luckily, an error message will occur, in both Marketo and SFDC, that will at the very least provide some evidence of the root cause of failure, if not a pinpointed reason. These error messages can sometimes send you on the path of removing a component and trying again, possibly resulting in failure again, prompting you to remove another component, et cetera, until the problem is uncovered. You can imagine how much work ends up being undone just to make the movement of a change set or program successful.
• These preventative measures help ensure a solid sandbox process: To prevent what seems like inevitable failures as described above, you may have to break apart the components you wish to move from sandbox to production. This means a bit of work upfront before any packaging or movement takes place:
• Comprehensive documentation: The first ounce of prevention is on the documentation side, where you should track items that need to be moved separately or simply rebuilt in production to afford a smooth movement of as many grouped changes as possible.
• Preemptive builds: The second preventative measure is in actually moving or building out those separate items in production as far ahead of time as you can; however, the very nature of some projects will not allow too much preemptive building time.
• Detailed planning: When preemptive builds are not an option, create an order of operations with a timeline for clear visibility of dependencies and expectations around roll-out of sandbox changes to production.
• Manipulation of artificial data for testing purposes: Working in a Sandbox bubble protects you from affecting real data, but if you are trying to test a solution that will be applied to real data one day, how do you recreate the scenarios needed to satisfy those true-to-life requirements? This can be challenging, because technically you can only build scenarios that closely resemble your real-world issues; they can never be 100% exact. Even a thorough Beta testing phase within your Sandbox, where you’ve invited people to test both externally and internally interactive components (whatever may apply to your solution), will leave a modicum of doubt about your solution’s live performance. Some protected testing is better than none, but the fact remains that it is artificial at best, and this is an important point to keep in mind.

In the case where a sandbox is a requirement, then these sandbox “cons” become part of the process rather than a detriment. It is important to recognize that for some companies, the presence of a sandbox simply creates more work and longer time-to-deployment than may be necessary. That is an important evaluation point when deciding to use a sandbox for development.

Need help?

DemandGen’s team of experts are well-versed in highly complex, sandbox-driven environments and can help you get the most out of your sandbox (or sandboxes). If you are unsure about taking on a sandbox in the first place, we can help you make that decision as well. Drop us a note online to schedule an initial conversation.

Sarah Wight, Solutions Architect at DemandGen, is a seasoned technical administrator and strategist with 15 years of experience using Salesforce CRM and 9 years of experience using Marketo Marketing Automation. She is adept at building custom-fit marketing data stack solutions for companies of all sizes, in all industries, with a keen focus on functional attribution that fuels powerful reporting. Sarah is passionate about helping her clients make their marketing efforts highly visible, maintaining clean data, and optimizing the use of today’s leading marketing software.

The post Sandboxes Aren’t Just for Playing Around: The Pros and Cons of Marketo & SFDC Sandbox Environments appeared first on DemandGen.

About the Author

Sarah Wight, Solutions Architect at DemandGen, is a seasoned technical administrator and strategist with 13 years of experience using Salesforce CRM and 7 years of experience using Marketo Marketing Automation. She is adept at building custom-fit marketing data stack solutions for companies of all sizes, in all industries, with a keen focus on functional attribution that fuels powerful reporting. Sarah is passionate about helping her clients make their marketing efforts highly visible, maintaining clean data, and optimizing the use of today’s leading marketing software.