Creating Content That Converts: Expert Advice

Watch Now

Blog

Marketo Sandbox: What it is and what it isn’t.

Read Time: 5 Mins
Marketo Sandbox: What it is and what it isn’t

Generally speaking, a sandbox is a testing environment that’s separate from production,  enabling the isolated execution of software or programs for independent testing and evaluation. This is helpful for everything you may not t want to do in a live environment, such as developing new features and identifying and fixing bugs.  It can also be used as a learning environment so new users can practice working in a platform  without affecting production.  Like many platforms, Marketo offers a ‘sandbox’ instance that can be used alongside the production instance.

The Marketo Sandbox is not robust.

The Marketo sandbox is not as robust as sandbox environments that many marketing and sales ops teams may be used to using. This is a critical distinction because it directly affects how it can be used and the use cases it is fit for purpose. Here are several key capability limitations to know about the Marketo sandbox.

  • Not a mirror instance. A Marketo sandbox starts out empty. While Marketo support can copy data from your production instance into the sandbox (this article outlines what can be copied), it is important to be aware that there is a lot of data that is not brought over, like the lead database, campaign history and Marketo users. In addition, all Admin settings need to be set up manually. 
  • Only programs can be imported. Programs created in sandbox can be moved into production, using a program import. The tool can be used to copy programs from production to sandbox as well. However, anything outside of a program, such as custom fields, database segmentations, smart lists outside a program, or design studio assets cannot be copied between sandbox and production.
  • Importing dynamic content is not possible. Program imports do not support dynamic content, snippets, and image tokens. All emails and landing pages with dynamic content and snippets are skipped during the import. Tokens that live outside of a program are converted to local tokens during the import process. 
  • Edits to existing programs are not possible. Marketo Sandbox cannot update existing programs in Marketo, it can only be used to push over new programs. If any changes are made to an existing program in a sandbox that are deemed necessary in production, these changes need to be manually replicated in production. Alternatively, the program needs to be imported from Sandbox into production, the old program needs to be archived and the newly imported one associated to related Marketo assets.
  • The Marketo sandbox is throttled. Sandboxes are throttled so production instances aren’t adversely affected by testing environments. You can send up to 20 emails per campaign run. Iron Horse does not view this as an issue as a sandbox shouldn’t be used to send live marketing emails. 
  • Not-self service. A new sandbox can not be created directly by an admin. A new sandbox can only be created by contacting your marketo account representative who will then make the request internally for a new sandbox. 

When using a Marketo Sandbox, pair it with a CRM sandbox.

A Marketo sandbox can be connected to a Salesforce.com  or Microsoft Dynamics sandbox. We recommend doing this if you intend to use the sandbox long term, so it stays current with the CRM testing environment. The integration can help keep the Marketo sandbox up to date on leads, contacts, accounts, teams, users, opportunities and custom objects.  Iron Horse particularly recommends using a sandbox for testing changes with Microsoft Dynamics before pushing changes in production. Microsoft Dynamics is highly customizable and not all customizations that can be made in Microsoft Dynamics are compatible with Marketo. 

When to use a Marketo Sandbox.

With the shortcomings listed above it, you might be asking where a sandbox makes sense, and when it doesn’t. There are three primary use cases where we see Marketo Sandbox being particularly useful.

  • Large number of new programs that need to be tested. A sandbox might make sense if there is a need to create and test a large number of new programs all at once that can affect production. An example of this would be a large change around operational campaigns. This would be a short term sandbox, as after the programs are implemented the sandbox would no longer be necessary.
  • New integrations. A sandbox is a great tool to set up and test new integrations before using them live in production. This is particularly helpful for integrations with a more involved setup, or that will require additional operational smart campaigns. Be aware, however, that the integration cannot be copied to production, it will need to be set up again. 
  • User training. If multiple new Marketo users need to learn Marketo around the same time, a sandbox would allow for a space for users to practice using the platform without affecting live campaigns or the database. Additionally,  with the limits in place on a sandbox, it’s not possible to unintentionally send an email to a large audience.

When Not to use a Marketo Sandbox.

There are two prominent use cases where a Marketo sandbox should not be used.

  • Most or all work in Sandbox first. Larger organizations that have a sandbox -> production approach for their corporate websites often attempt to do the same for marketing automation. This isn’t realistically possible with a Marketo sandbox.  A sandbox is not a one-to-one replica of production and, with the exception of programs, data in sandbox cannot be pushed over to production. That means it can’t be used as an accurate testing environment for all changes planned in production. Any edits made to existing assets, programs and admin settings would need to be replicated manually as well. This adds a significant amount of time.
  • Grant Access. It may be tempting to use sandbox as an environment where you can grant more access to users who have restricted permissions in production, such as consultants or contractors. However, as anything done in sandbox outside of a program would need to be replicated in production, their access would also need to be the same in production or someone with more access in production will have to replicate the work done in sandbox. One also would run into the issue noted above that only work 100% done in a program can be fully brought over and anything else (including adjustments to inflight programs) would need to be manually replicated.

The Iron Horse insight.

As Marketo consultants, we don’t see clients widely using the Marketo Sandbox, and when we do it’s for particular use cases, such as testing new integrations, or if the Marketo instances has been or will be integrated with Microsoft Dynamics). Microsoft Dynamics is a unique use case because of how customizable it is, and how many of the customizations that can be made affect the integration.

The concept of a sandbox is very appealing, and many companies would benefit from using one. However, with the current limitations of the Marketo sandbox, especially how disconnected it is from production, it’s not something we typically recommend. Instead, Iron Horse recommends clear processes and procedures, as well as using segments/partitions when available.

Related content.

Subscribe to our blog.
Get unstuck with the most interesting business ideas and our insights delivered to your inbox.

© 2024 Iron Horse. All rights reserved. Privacy Policy

Question?

Chat with our AI Expert

×