Is it worth having a sandbox? | Community
Skip to main content
A
Anonymous
January 13, 2016
Solved

Is it worth having a sandbox?

  • January 13, 2016
  • 5 replies
  • 9208 views

I had a Marketo sandbox for our initial setup but have never otherwise used one. For those of you with a sandbox, is it worth the extra cost? Do you integrate your Marketo sandbox to your fullcopy SFDC sandbox? Does everyone get access or is it limited provisioning? How often do you refresh? How does testing work? Do you get access to releases early with sandbox?

I come from a strong process background for SFDC and we do everything in sandbox before implementing in production. Pros/cons to this approach in Marketo?

Appreciate the feedback as I'm trying to get my tech budget together

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Edward_Unthank_

I personally don't think the Sandbox is worth the money. I would instead spend that money on Workspaces and Partition.

It functions as a pseudo-sandbox in terms of development process—it's actually just a separate Marketo instance with the same functionality as your normal Marketo instance (with a few more limitations), only labeled as a "sandbox." The instances aren't mirrored automatically, and the proposed process is to build in the Sandbox instance and then import the program into the Production instance—that's a lot of manual work, with all the considerations of that process. It requires reactivating all smart campaigns, for one.

The Sandbox, when it's created, is a carbon copy of your Production instance. After that point in time, though, the Sandbox and Production instances lose that mirroring automatically, and can only be kept up through spending lots of time doubling your effort to keep them mirrored—a not-worthwhile amount of time and effort, especially considering the reality of quick, on-the-fly changes that need to happen in Production.

I think Workspaces and Partitions provide a better solution for: allowing new Marketo users to train in their own silo'ed partition and workspace, having a "Development" workspace/partition that is much easier to move the final product over to your "Production" workspace/partition, and it also gives you the other benefit of having workspaces and partitions anyway. Things like giving you the ability to have internal communications and employee leads in their own partition, or other random communication interests that come up which don't perfectly fit with your normal Marketo usage.

Cheers,

Edward Unthank

5 replies

Dory_Viscoglio
Dory_Viscoglio
New Participant
January 15, 2016

We have a sandbox that's almost never used, except sometimes when our Development team is building something new and since they don't normally work in production they are basically afraid of working in production. (It freaks them out when I go in and just start making random changes to stuff, and they're always reminding me that I'm in production....)

But, if you do move forward with it, one thing that we encountered during one of our renewals was they tried to tell us we had 50% more people in our database than we actually did.. In the end it turns out they were counting the records in our sandbox towards our total! We put an end to that very quickly, but it's something to watch out for.

    Grégoire_Miche2
    Grégoire_Miche2
    New Participant
    January 15, 2016

    HI Emily,

    I also concur with Ed and Josh on this. Especially, in the absence of better data management tools, the burden associated with managing a sandbox can be really painful and using a dedicated WS/Partition is much much simpler.

    Just a point: you can ask support to connect your 2 Marketo instances, so that at least you will be able to exchange programs, at least under certain conditions.

    One of the things that is really painful is when your SFDC UAT is being refreshed to reflect a dev instance... because reconnecting the SFDC sandbox and the Marketo sandbox become really painful, data model might have changed on SFDC, fields disappeared, other suddenly appeared, etc...

    Now, some large companies just do not consider it possible to go live with any software before they have intensly tested on a sandbox, and Marketo impossibility to change SFDC connection may make the Marketo sandbox mandatory in such environments.

    -Greg

      Iryna_Zhuravel4
      Iryna_Zhuravel4
      New Participant
      January 14, 2016

      Agree with Ed and Josh.

      One more thing to consider is that whenever you back up your SFDC production into sandbox the sync between your SFDC and Marketo sandboxes breaks, because your SFDC sandbox org id changes, every time that happens you have to contact Marketo support to resync the sandboxes. After that it takes up to a week for everything from your updated SFDC sandbox to sync to your Mrkt sandbox and during that time Mrkt sandbox becomes unusable. So if you are backing up your SFDC production into sandbox often, using Marketo sandbox becomes a real pain.

      That said I found it very useful to test new SFDC/Marketo sync processes on sandboxes in the past.

      Edward_Unthank_
      Edward_Unthank_Accepted solution
      New Participant
      January 13, 2016

      I personally don't think the Sandbox is worth the money. I would instead spend that money on Workspaces and Partition.

      It functions as a pseudo-sandbox in terms of development process—it's actually just a separate Marketo instance with the same functionality as your normal Marketo instance (with a few more limitations), only labeled as a "sandbox." The instances aren't mirrored automatically, and the proposed process is to build in the Sandbox instance and then import the program into the Production instance—that's a lot of manual work, with all the considerations of that process. It requires reactivating all smart campaigns, for one.

      The Sandbox, when it's created, is a carbon copy of your Production instance. After that point in time, though, the Sandbox and Production instances lose that mirroring automatically, and can only be kept up through spending lots of time doubling your effort to keep them mirrored—a not-worthwhile amount of time and effort, especially considering the reality of quick, on-the-fly changes that need to happen in Production.

      I think Workspaces and Partitions provide a better solution for: allowing new Marketo users to train in their own silo'ed partition and workspace, having a "Development" workspace/partition that is much easier to move the final product over to your "Production" workspace/partition, and it also gives you the other benefit of having workspaces and partitions anyway. Things like giving you the ability to have internal communications and employee leads in their own partition, or other random communication interests that come up which don't perfectly fit with your normal Marketo usage.

      Cheers,

      Edward Unthank

        A
        Anonymous
        January 13, 2016

        I like the idea of using Partitions/Workspaces for user training. That's a big pain for me right now.

        Andy_Varshneya1
        Andy_Varshneya1
        New Participant
        January 13, 2016

        Hi Emily,

        It all comes down to how much you'll end up using it. I use the sandbox to test out new features we may be adding into SFDC, Marketo, our website, or one of our integrations, and as a training ground for new team members.

        If your other environments aren't as intertwined with Marketo, you could get away without having a sandbox, but we've personally connected our Marketo sandbox, SFDC sandbox, website staging environment, and product staging environment so we're able to test everything end-to-end before pushing it live.

          A
          Anonymous
          January 13, 2016

          Hi Andy, What kind of things do you test end-to-end? New forms, programs? Is there a process for what needs to go into sandbox and what can be created in Production? Do you manually keep everything in the two instances updated since there's no auto-refresh?

          Andy_Varshneya1
          Andy_Varshneya1
          New Participant
          January 14, 2016

          We have our Marketo instance integrated with our product (data flowing to and from between our Marketo instance and product), website, and SFDC and so in order to keep everything on the same page when we make big changes like upgrading our product to a new version, changing user profile properties in SFDC, rebuilding the corporate website and/or switching to an SSL server, and so on, it's much less nerve wracking doing it in the sandbox environment first.

          We've prevented at least half a dozen fatal flaws from getting released publicly in the last year by testing in the sandbox ecosystem first and knowing exactly how everything will be impacted by making a certain change.

          All depends on how big your changes are as well as what your budget is. Like Edward pointed out, for some companies, you'll be just fine without a sandbox and would be better off spending your money on partitions and workspaces.

          All forms and programs are created straight into production. We pull things into the sandbox on a per-need basis. Every so often I'll go sync the operational programs over to the sandbox, but otherwise, it all depends on the changes we need to test in the sandbox e.g. changing privacy rights doesn't need programs to be up to date.

          Terms & ConditionsAccessibility statement

          Loading footer...