Live
Sandbox

Live Sandbox is fundamentally differentiated in how it operates from other production environments. Traditional sandboxing works by taking a copy of your production instance at a point in time, and putting that into a separate environment. 

Anyone who has been in enterprise software knows how this works: hosting a separate environment is generally very expensive. If you're talking about ERP, specifically with NetSuite, 10% to 15% of your license, just to get a single environment for testing, and it’s a copy at a point in time–with only a few refreshes a year. That data is locked into a point in time–so if anything changes in your production instance, it doesn’t show up in your sandbox.

For instance, if you wanted to understand what would happen to an order if you needed to change the product or packaging–there’s no way to test that. Or, let's say you wanted to change how a specific configuration works, perhaps “I want to see what my revenue allocations would look like on this contract if I decided to do revenue allocations in the first place.” 

When you go to a normal production sandbox, you can change the configuration, but then, you wouldn't have any of your recent contracts, or you need to refresh them so that you can do it.Managing sandbox planning is time consuming. Teams spend days doing instance planning.

But at Lensing, we figured out how to put sandboxing inside of your production instance. You log into your production instance, and that's it. You don't need another environment to run tests, or build integrations, or change configurations and test them. Like you go into your production environment, you click two buttons, and you're in a completely protected environment–as many times as you want. It's unlimited. You can refresh the data in your environment.

What can Live Sandbox help with as far as scaling and growth? 

As far as scaling and growth, back to our first example of “I want to change the product mix in this order that a customer is requesting,” once inside your development environment, you can go to the order sandbox, change it, and then see what happens immediately. 

Some users use it to simulate revenue posting. We've seen users simulate how orders would look if they changed their pricing on a product. If our product changed to usage based subscription instead of a SaaS subscription, what would it do?

With this, companies are responding to change faster because they're able to test the implications of change faster. They're able to feel more confident that they can support changes almost as fast as it takes to make them. 

Lensing’s Live Sandbox is also not just a testing environment–there are also tools within the sandbox to merge those changes from production to deployment. You can test changes within Live Sandbox, confirm that’s what you’d really like, and then deploy with confidence, automating deployment management and reducing change management risk.  

Additionally, every time you try to merge something from a sandbox into your production environment, Lensing puts it through a pipeline of nearly 3000 tests to make sure the changes you're making aren't going to cause any issues with the system that you already have.

This isn’t just a product that Lensing markets and supports–we also operate within the Live Sandbox production environment ourselves. When an application developer in Heidelberg develops a new feature, they go to our development and into a sandbox. They launch a version of VS Code that we have in the browser, make the changes to the actual application source code inside of the Lensing application itself inside of the sandbox, and then run it through the whole testing pipeline with reviewers and approvers. 

The developer is able to then merge it back into the main code base, and that's what we ship to our customers.