True or false: Work nightmares are 10x scarier than ones with monsters.
If you answered ‘True’ – you’re not alone, fellow sleepworker. Some psychologists actually say this is pretty normal since people tend to dream about what’s important to them. In fact, one survey shows that more than 50 percent of people experience work nightmares once a week or more.
There are a lot of ways integration projects can go wrong.
This realization prompted our team to compile a list of all the horrifying things that cause failed integration efforts, potentially leading to an increase in “workmares.” (While we don’t have any cold hard facts to prove this, we’re pretty sure they’re correlated.)
Of all the scenarios we came up with, one in particular stood out, which is why we’re dedicating a whole blog post to it in the hopes you’ll avoid it, too.
Did someone say refresh?
Hands down, one of the most horrifying (and costly) mistakes we encounter as experienced integration consultants is when a client refreshes their sandbox environment —Salesforce mainly—mid-project.
If you’ve ever been involved in any kind of system rollout or sit on the technical side of the business, then you’re probably familiar with the term “sandbox.” A sandbox environment is a great way to develop, test, and train in a system like Salesforce, for example, without compromising the production (live) org. It gives companies the flexibility to isolate custom code, test development changes against copies of production data, and train users before rolling out updates.
Remember what your mother always said: “Play nice in the sandbox.”
Occasionally, a company might decide to refresh their sandbox to more accurately reflect production. If changes are made in production and not in the sandbox, then the two environments look and respond differently. Since a refresh updates the sandbox’s metadata from its source org, this is expected to improve the accuracy of future testing and deployments (i.e. new integrations).
Refreshing a sandbox when no one’s building in it? A-OK. Nothing’s been built, so there’s nothing to break.
Hitting refresh when someone’s been building in it? That’s the stuff workmares are made of.
Consider for a moment you’ve contracted with an outside resource to build an integration between Sage Intacct, a widely utilized accounting software, and Salesforce, your CRM platform. While this is considered a fairly standard integration, it’s not uncommon for it to take anywhere from 80 to 140 hours to build.
Refreshing your sandbox mid-project could mean the difference between paying what you originally contracted for the work and more than 2x what you contracted to fix it.
Your heart’s in the right place, make sure your integrations are too.
While there’s nothing fundamentally wrong with a good old fashioned refresh to your sandbox, you can see why things get scary quickly if you’re not paying close attention to who and what are in it first.
If for some reason you need to run a refresh during an integration project, here are a few tips from Venn’s resident integration consultants for how to go about it without losing sleep.
Notify both internal and external resources of your intent to refresh the sandbox.
This applies to any new integrations or custom code built in the sandbox. If you worked with an outside resource to build these, ask to have them packaged up for you.
This allows your resources to continue building and testing from where they left off. If you worked with an outside resource to build the integrations, ask them to apply the package to the new sandbox for you.
It’s our hope that by following these simple steps, you’ll avoid experiencing one more workmare than you have to.
Bottom line: Always, always, always consult with anyone who has access to your sandbox environment —whether that’s someone internal to your company or a consultant —prior to refreshing.
