Workspaces are available on Split’s Platform Edition as part of the Collaborate package.
As we have built out the Split platform over the last few years, we have had a few pillars for success that have guided our product vision. One of the most important ones for us has been to have a focus on being “Built for Teams.” For us, this means that we’re always laser-focused on making sure that cross-functional teams across product and engineering can easily find and manage their own feature experiments and releases. We also want to make sure that each team has a standardized process to ensure visibility and collaboration across an entire organization. This focus over the past few years has resulted in releases including standardized SDKs across ten languages, team workflows for permissioning, starring to find your most important splits easily, and many more.
Today, we’re excited to announce the release of Workspaces to further enhance our ability to support larger teams. With this feature, we’ve given our customers the ability to easily separate the management of experiments and feature flags across their product lines and applications. This release comes directly as a result of our experience onboarding our customers onto the Split platform over the years. We’ve often started out partnering with a single scrum team or department to transform the way they release and measure their features. As these teams realized dividends on the speed, safety, and impact of each of their feature releases, the adoption of Split naturally spread to other teams and departments in the organization.
As product and engineering teams began to experiment and feature flag at scale, we realized the need to build out even stronger standardized segmentation of feature releases for teams that work on entirely separate product lines or applications within a company. For example, if you’re a product and engineering team building products for a bank that is managing commercial and retail banking business lines, the software you’re releasing to your bankers is likely an entirely different set of applications than anything you might be giving to your corporate customers. Workspaces will provide you with the ability to avoid any mix up of features across the two product lines.
Segmenting your team’s experiments and feature releases
With this release, we’ve updated our object model so that every feature and experiment belongs under a single workspace. Your teams will be able to operate entirely out of their workspace without any added noise or cross-contamination of the feature releases or experiments running on a totally different product line. Additionally, each API key that you leverage in our SDKs will only have access to the features that are relevant within a given workspace, providing a way to simplify your use of the SDKs. Below, you can see two diagrams how the object model has changed.
Object Model – Current State:
Object Model – Workspaces release:
While building out workspaces for our customers, we wanted to make sure that we wouldn’t disrupt the current flow of how our users use Split on a day to day to basis. For that reason, the main points of navigation within the platform will remain the same. To switch between different workspaces, users click into the top left menu in the application to select from the various workspaces that have been configured for them. Once in a workspace, users can then easily navigate across their experiments as they always have.
We’re incredibly excited about this release, but we’re far from done! Our team has a ton in store to further enhance our ability to support teams looking to manage their experiments and feature flags. Make sure to subscribe to our Release Notes to be the first to hear about all of the new features we are building.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Split manages more than 50 billion feature flags changes around the world every day. A recent study shows that about 5 to 6% of feature flags are rolled-back (or killed, using Split terminology in reference to a kill switch) within 30 days of being created. This speaks to the importance…
At Split we believe in the power of metrics, and are always striving to improve the ways we help our users make more data-driven product decisions. In this previous post we talked about the importance of understanding the impact of a new feature release via key and guardrail metrics. With…
When we speak to our customers, one of the most common reasons they say they made the move towards feature flags was the need to make sure their releases didn’t cause more errors for their users. By leveraging feature flags to ramp the release of their features to just small…