Workspaces is revolutionizing Drupal Core: Unlock True Enterprise Content Management in Drupal

[00:00:00] All right, let's get started, everyone. We have a lot to cover, and I'll be channeling Fabian Franz. Welcome to our talk on enterprise content management in Drupal with Workspaces.

[00:00:27] I'm Peta Hoyes, Chief Operating Officer of Tag1 Consulting. I found my way to Drupal via engineering and product design, and a desire to make technology transparent to what I call the fuzzies: artists, musicians, and writers. Back in 1993, when the web wasn't really a thing, I used bulletin board software to create a wide area network to connect people. Basically, I had a wall of Hayes modems and a T1 line coming into a Brooklyn brownstone. Fast forward about 15 years, and I realized I had actually been creating social networks, though I didn't know what they were at the time. While I try not to live in regrets, I do get serious twitches from time to time.

[00:01:33] Around 2008, Drupal got on my radar when I started working with Nat Catchpole at CivicActions. Catch introduced me a few years later to Jeremy Andrews and Narayan Newton at Tag1 Consulting. We've continued making waves ever since, especially in the Drupal performance arena.

[00:01:50] I'm joined today by one of my colleagues, Ray Stuart, who will be presenting for Fabian Franz, Tag1's VP of Software Engineering. Fabian is recovering from the flu and unfortunately couldn't be here, so we're going to do our best to cover for him. As many of you know, Fabian is a Drupal 7 maintainer and core committer, and he's been developing the Content Preview System (CPS), the Drupal 7 predecessor to Workspaces, since 2014. He's guided the development of Workspaces for the last three years in pursuit of feature parity with CPS.

[00:02:45] Ray Stuart is a senior technical lead at Tag1 and an avid outdoorsman. We happen to both be Jamaican, by the way, and like the Jamaican bobsled team, we just do it, and we go for the gold. Ray's expertise centers on back-end architecture and development, with front-end capabilities. He specializes in what he thinks of as moving data around in ways that create meaningful impact. Since discovering Drupal around 2007, Ray has built his career on the platform, developing a particular appreciation for teams where each person contributes meaningfully to complex engineering challenges. That's Tag1 in a nutshell.

[00:03:43] If you're not familiar with Tag1, we're a global technology group focused on using open source software to solve very difficult problems for a lot of different clients. We work with many technologies, but we're best known as the number two all-time contributor to Drupal. Since 2001, our team has created many of the innovations that have fueled Drupal's success, such as the taxonomy system and the Migrate API. And if you use Drupal, which I'm pretty sure you do, we're involved every time you update a site: we manage the infrastructure of drupal.org, along with the tooling used to build, test, and release Drupal on behalf of the Drupal Association and its community.

[00:04:38] So what do we mean by true enterprise content management? Since Tag1 was founded, we've worked with a lot of enterprise organizations over the last few decades. We've helped many grow their websites from something basic into a critical part of their business. As those websites have become more and more important, the most successful enterprise companies have expanded the role of their CMS from a tool that helps them manage their website to one that's also a key element of content governance.

[00:05:19] If content governance isn't a familiar term, it refers to all of the various things, from procedures to technology, that a complex organization needs to make sure its content meets its standards and requirements. Anyone who works for or with large enterprise organizations knows that's no small feat. There can be a lot of content stakeholders with diverse concerns, from brand marketing to legal compliance. That's a lot of cooks in the kitchen, and strong content governance is what, hopefully, stops all of that from devolving into chaos.

[00:06:04] So for a CMS to truly meet enterprise content management requirements, it needs to provide tools for both creating content and managing the end-to-end governance of that content. Drupal has been working toward this in core for a long time now, from early features like granular user roles that let enterprise teams control permissions and access, to tools like workflows and content moderation in Drupal 8 for managing content publishing lifecycles. And with the adoption of Workspaces in core, we've closed another major governance gap where Drupal has lagged for some time: content staging and review in the CMS.

[00:06:52] Let me explain why that's more important than ever. In our modern age of composable content and visual page builders, a lot of enterprise websites have gone from looking like this to more like this. These are the types of sites we've worked hard to make Drupal great at building. Content comes from a bunch of different systems, it's highly designed and dynamically laid out in the CMS, and edits and updates propagate automatically all over the site.

[00:07:25] But here's the catch. The kinds of critical, large-scale updates that Drupal does so well, things like adding new products or services or migrating to a new department, are notable visual changes. They impact navigation, views, and blocks throughout the site. Because of that, the governance of those changes, reviewing for brand consistency, legal compliance, accessibility, and so on, really needs to happen in the context of the overall site, with all the pieces of the puzzle present. Until now, Drupal hasn't had a great solution for that kind of content staging. It has required workarounds and compromises, things like the content staging site.

[00:08:21] The content staging site is, of course, a duplicate of your production site where content managers can stage all of their changes without disrupting the live site. It sounds great in theory, and a lot of you are using them for enterprise websites, but it's time to say goodbye. Here's why.

[00:08:43] That staging site requires a duplicate codebase, database, and file system that all have to be maintained. Often that means a whole other file server that requires ongoing maintenance. Keeping it in sync with your live site probably means complex CI/CD pipelines and build workflows. Sure, I get it, we're all working in the cloud; our DevOps teams or our favorite managed platform have a lot of this set up for us. But getting all of it set up and keeping it up to date is time-consuming and expensive. And for what? Staging infrastructure often doesn't have resources equal to production, which introduces concerns for things like performance testing.

[00:09:39] But okay, we're enterprise Drupalists. We're comfortable with DevOps, coding, and config management. What about the impact on the people who need to manage the content? External staging sites mean content managers have to work in two or more different places. Why more? Well, what happens when you need to stage more than one set of updates at a time? More staging equals more problems. I know the build tubes can probably handle it, but do you know what most content managers don't love? Remembering which autogenerated subdomain from a git branch ID is the one they're supposed to be updating.

[00:10:29] But even if that doesn't convince you, here's the hardest part, the part you've been waiting for me to get to: you need some way to get the content from one site to another. Content deployment across systems is rife with opportunities for failure. Remember, we're not talking about version-controlled code. We're talking about rows of data from multiple tables moving from one database to a second, completely unrelated database, and that is always risky.

[00:11:09] There have, of course, been numerous attempts to overcome this in the Drupal community over the years. I'm certain I'm not the only one who remembers, and still has nightmares about, the Features module and long lists of overridden mistakes. Seriously though, Drupal.org's documentation has a page comparing 50 content deployment modules, and there are also a number of external systems that tackle the problem. Some of these solutions are quite good. But to be clear, no matter what, content staging servers are a costly, complex, very inconvenient, and very risky way to work around Drupal's historic limitations.

[00:12:14] So you've heard about all these capabilities: atomic publishing, full-site preview, zero overhead on production. That might sound complex to set up, but it's not. Workspaces is now built into Drupal core, and getting started is one command many of us are familiar with: drush en workspaces, and you're done. Mostly, as with a lot of Drupal. You have what's in core, and you also have WSE, Workspaces Extra.

[00:12:51] Since Drupal 10.3 in June 2024, Workspaces has been stable and fully supported, and it ships with every Drupal 11 installation. You now have enterprise content staging that rivals Adobe Experience Manager, and it's free and open source. But you'll also want Workspaces Extra (WSE). If core Workspaces are git branches for content, WSE is like the full CI/CD pipeline you have for your code. You get scheduled publishing, preview links for external stakeholders, rollback capability, access control, menu staging, and task monitoring. Plus, WSE Config lets you stage configuration changes alongside content.

[00:13:43] Installing WSE should also be very familiar by now: it's just composer require drupal/wse. And that's pretty much it. It's a low barrier to entry, with enterprise capability out of the box.

[00:14:06] Workspaces, in a sense, is a staging site. Traditional staging servers can cost as much as production: separate infrastructure, databases, and certificates, and you typically get one, maybe two, environments. Workspaces eliminates all of that, or can. When you preview a workspace, you see the entire site as it will appear once it's updated, live, and published. Views, listings, navigation menus, entity references, everything reflects your staged state. Your workspace changes layer transparently on top of the live site. It's complete context, and it's automatic.

[00:14:49] You get enterprise features out of Workspaces right from the get-go. Unlimited workspaces, so design, content, translation, and legal teams, whichever teams you have, can all work in parallel. Each workspace is isolated, with granular permissions. Content moderation integration, which is still ongoing, gives you entity-level workflow states, with atomic publishing, scheduled publishing, rollback, and external preview notifications, all within one Drupal installation. Zero infrastructure cost, zero overhead on live. Traditional staging is infrastructure, whereas Workspaces is architecture.

[00:15:33] Now, most of us here know git, and if you do, you pretty much already understand Workspaces. The workflow is identical to working on a feature branch and then merging to main; the difference here is content. In git, you create a branch where changes accumulate, you switch between main and your branch to see the complete state, and then you merge atomically. The parallels are fairly exact: a workspace is a content branch, live is main, publishing is merging your staged content, and your repository is your site. The mental model is nearly identical.

[00:16:17] Developers take branching for granted. Content editors face a similar problem, coordinating related changes, but they've been stuck with per-item drafts and manual coordination until now. Workspaces doesn't implement automatic merging, which leads to data corruption with structured content. Instead, teams coordinate through communication: shared workspaces for collaboration and clear content ownership. Your workspace will never contain content that you didn't put there.

[00:16:53] Here's a direct mapping between Workspaces and git. The repository equals the Drupal site. A git branch equals a workspace. The main branch in git equals the live workspace in Drupal. A commit equals a save. A working copy equals a workspace preview. A merge equals publish.

[00:17:23] The workflow is identical. In git: create a branch for your feature, make commits, preview the complete state, get approval, and merge to main. In Workspaces: create a workspace for your campaign, save changes, preview the complete site, get approval through content moderation, and then publish. Developers already know this workflow intimately; content teams just haven't had the tooling until now.

[00:17:53] Branches aren't just for developers. Anytime you need to coordinate multiple related changes, preview them together, and deploy them as a unit, you need branching. The architecture that powers git, isolated workspaces, atomic merges, and zero maintenance cost, is the same architecture that powers Workspaces. If your dev team wouldn't ship code without branches, why would your content team ship content without workspaces?

[00:18:24] Workspaces is built for content teams coordinating multiple related changes: large organizations where departments work in parallel, say marketing, legal, design, and content teams; and campaign launches where articles, media, navigation, and landing pages must deploy simultaneously. What's the common thread? Full-site content preview. If you've ever had a landing page go live before its menu link, you need a workspace.

[00:18:53] Who is it not for? Here's a surprising answer: no one is excluded from using Workspaces. Content moderation will use Workspaces soon; there's one issue left in core to deal with that. There's also an issue with updating content across multiple workspaces; there's a parallel workspaces module to help with that, and an issue that will help fix this in core as well.

[00:19:23] Workspaces has a fundamental principle: it's a boundary around production. When the active workspace is live, which is 100% of the time for anonymous users, the workspace system is invisible. Your staging work cannot affect production performance.

[00:20:15] Form submissions within a workspace are prohibited, because they trigger irreversible side effects like sending emails or processing payments. You can stage content, preview layouts, and test navigation, but you can't accidentally trigger real-world consequences. Non-workspace-safe entities, those that don't support revisions, simply can't be modified in a workspace. The system enforces architectural safety at every level.

[00:20:39] Now, how about performance? This is Workspaces' most important architectural property: zero overhead on the live site. When the active workspace is live, which again is 100% of the time for anonymous users, the workspace system is invisible, so your production site performs exactly as if Workspaces didn't exist. This makes Workspaces viable on the highest-traffic production sites in the world. Content staging systems that add overhead to every page load get disabled. Workspaces was architected from day one, in CPS in 2014, to have zero impact on live traffic. That's why it's been running at Alexa top 500 companies for over a decade.

[00:21:35] Inside a workspace, yes, there's overhead, but that's generally editorial traffic, which is a tiny fraction of your load. You will see a slight decrease in performance inside a workspace because of the additional overhead. But editors get a full-site preview, while visitors get full production speed.

[00:21:59] The most common question is: what happens when two people edit the same content in different workspaces? The answer is simple and deliberate: you can't, and this is the right design. As I mentioned, there's work in the parallel workspaces module, and in core, to improve on this. There's also no automatic merging within workspaces; it's really up to the team to communicate those changes and manually merge conflicts later. When an entity is modified in a workspace, it's tracked there, and another editor can't modify it in a different workspace. This isn't exactly a limitation; it's a feature.

[00:22:50] Automatic merging of structured content fields, entity references, and media relationships could lead to data corruption, and every system that has attempted it has encountered fundamental issues. This is especially true with config, where you'd want to be careful with those merges. Workspaces takes the same approach as a well-run dev team: coordinate through communication. Shared workspaces let teams work together, content ownership keeps responsibilities clear, and WSE (Workspaces Extra) lets you move content between workspaces when needed. The absence of automatic merging is a safety guarantee: your workspace will never contain content that you didn't put there.

[00:23:42] Because workspaces are conflict-free, scheduled publishing is actually safe. WSE Scheduler lets you set a date and time, so your workspace publishes automatically at, say, 2 a.m. on launch day. A workspace's contents are deterministic: what you reviewed and approved is exactly what goes live. No surprises. In a merge-based system, you couldn't guarantee what state the content would be in at deployment time.

[00:24:07] Rollback is guaranteed to work because the workspace is an atomic unit. WSE's rollback feature can revert an entire published workspace and undo the complete deployment. There's a clean boundary: these specific changes came from this specific workspace, so there's no ambiguity about what to undo. Revert the workspace and you're done.

[00:24:38] And conflict-free means correctness, to some degree. What your editor reviews is what's published. What your legal team approves via preview link is what goes live. No merge during deployment, and no conflicts introduced during review.

[00:24:57] Now, the deletion problem, and how it's solved. Deleting content in a workspace creates a challenge: the content needs to disappear from the workspace preview but remain visible on the live site until you publish. Trash solves this elegantly with a "deleted" field using a ternary state. Values greater than one are Unix timestamps of actual deletion, and those are subject to garbage collection; one means draft in a workspace, not yet published; and zero means live and visible.

[00:25:35] When you delete content within a workspace, the entity remains live in the main table with deleted equal to zero, but the workspace revision marks it as deleted. Within the workspace, that content disappears from listings, views, and search results; on the live site, it remains visible until you publish. Content deleted in a workspace is recoverable until you publish. This integration also removes an old constraint: any entity type can now participate in workspaces, not just those with a publication status.

[00:26:16] Workspaces and workflows. Workspaces integrates cleanly with Drupal's core Workflows module. You can move an entire workspace through workflow states, for example draft, review, approved, and published. The entire collection of changes moves through the approval process as a unit: your legal team reviews the complete workspace, your content manager approves the entire set, and when it reaches the publish state, the whole workspace deploys atomically.

[00:26:48] The simplified content workflow initiative makes this even better. When those final issues land, it will make content moderation and workspaces work together seamlessly for complex scenarios where different entities need different approval paths. The Entity Workflow contrib module provides entity-level workflow granularity within a workspace context. Most sites won't need this, but the capability exists.

[00:27:24] Now, beyond content entities, here's where Workspaces becomes truly revolutionary. Up until now, we've talked about content entities: nodes, media, taxonomy terms. But what about configuration? Block placements, view configurations, theme settings, site title, field definitions. WSE Config is bringing all of that into workspaces, and it's almost production-ready. With WSE Config, you can modify a view within a workspace and preview it, change sorting and filters, all stageable and previewable. Block placements, menu settings, layout configuration, site settings, everything that's normally a configuration management export/import workflow can now happen within a workspace. There are some limitations I can't speak to exactly right now, but it's almost there.

[00:28:20] Add WSE Theme, and you can preview an entirely different theme. Want to test a major visual redesign? Stage it in a workspace, preview it with real content, get stakeholder sign-off via WSE's preview links, and then publish the entire redesign atomically. Configuration staging within workspaces closes one of the last remaining gaps between Drupal and the most capable proprietary CMSes.

[00:28:52] And now, AI. Everybody's talking about AI, and it's no different here: Workspaces is the perfect AI sandbox. AI content generation is scaling rapidly. The Drupal AI module integrates 48-plus AI providers, with automators that bulk-populate fields, generate summaries, and translate content. But AI is non-deterministic: it hallucinates, and it will produce errors. So how do you use AI at scale safely? Workspaces provide the natural architecture: the side-effect boundary.

[00:29:31] Think of a workspace like a pure function: everything inside is safe and reversible, with no side effects. AI can generate content, edit fields, restructure pages, and populate entire sections, all inside a workspace. Nothing touches live, and it's completely reversible. Publishing is the I/O at that point; that's when content gains irreversible, real-world effects. You still want a human in the loop to verify everything, and the human can verify everything within the workspace before it's published to live. The diff in the workspace helps you do that.

[00:30:23] As I mentioned, Workspaces has been stable in core since 10.3, and it ships with every Drupal 11 installation. It's no longer experimental; it's core infrastructure, so it's safe to use, and your sites can benefit from it now. But here's what we need from the community: this is the task, real-world testing on production projects. Try it with your contrib modules. Test it with custom entity types. Report bugs when you find them. Like any complex subsystem, there are edge cases. Every bug report makes it better, and every production deployment proves the architecture. The people who built this have been running it in production since 2014; now it needs the community.

[00:31:13] This matters urgently. Workspaces isn't just nice-to-have for AI integration; it's almost a must-have. AI content generation is scaling now, and with the problems of hallucination, you could really use a sandbox. Workspaces provides that sandbox for your AI content generation.

[00:31:40] Okay, now we're getting into demos. I'm going to start up a couple of videos and try to talk over them. Fabian couldn't be here, but we have a couple of items that will be helpful to see.

[00:32:08] This is an example of switching into a workspace. We're looking at some content and editing various aspects of it, including the title and the body content, and this is the stage workspace.

[00:32:37] Now we're going to save that content in the stage workspace. You can see the change we made to the title. We're looking at that in the stage workspace, and once we switch back to live, it switches back to "super easy," which is the original title. Back in the stage workspace, we're going to edit it again and change a few more items.

[00:33:05] We're updating the taxonomies, and we're going to swap out an image. We're also going to change some content in a multi-value text field. And, maybe most importantly and interestingly, we're going to change the URL alias for this item as well, so you'll see "even better" as part of the alias.

[00:33:50] It's hard to see, but in the URL bar there, it's "even better" as an alias. You'll see that the content has been switched out, the image has been switched out, and the terms we had in there as well. Now we're going to switch back to live, and you'll see that the URL has switched back to the original, and the image has switched back too, which are the easy visual markers.

[00:34:18] Now we're going to switch back to the stage side and go to layout, using Layout Builder. We're going to make a change here: move some blocks around, putting the ingredients on the right and the directions on the left. Then we'll save that layout, still on the stage workspace. You see the ingredients are on the right. We'll switch back to the live workspace, and you'll see ingredients on the left, and then back on the right again in the stage workspace.

[00:35:10] Now we're going to update a block and edit some of its configuration. We're going to change the title text field, change the URL alias we're pointing to, and swap out an image within this block as well. So keep in mind, this isn't just node content; it's entities site-wide, many content entities across the site.

[00:35:42] Now we're in the stage workspace, and we're going to the workflow management. You can see the changes that are staged, and in that edit menu, you can move an item to another workspace, translate it, and so on, so you have some per-item functionality with workspaces. Now we're publishing the content, and you'll see the changes are now applied in the live workspace.

[00:36:28] Okay, now we're going to create a new workspace, a blog workspace. This is going to create a number of blog content items relatively quickly; it's sped up here.

[00:37:09] So we've created a number of items, all in the blog workspace, which you can see in the upper right. Now we're going to go to menu items, which is always interesting to figure out when deploying new content. It's creating a nutrition blog. (This is when you realize you kept your computer glasses on and not your distance glasses.)

[00:37:46] In the blog workspace, you can see the nutrition blog menu item is there and takes you to the correct place. Go back to the homepage, switch back to the live site, and you'll see the nutrition blog menu item is no longer there.

[00:38:11] Switch back into the workspace, and you can see everything outstanding at a glance. Now it's going to publish the blog workspace. It's published, it automatically redirects to live, and the nutrition blog is now there. You haven't done anything particularly special to make it happen; it's just there.

[00:38:50] Now we have another video. For this one, I used a little AI to make it a bit larger.

[00:39:25] This one is using the Umami theme, but it's been replaced, as you can see, with lots of "DrupalCon" for DrupalCon. Everything is in a workspace, though I keep wanting to call it a change set, from CPS. This is content that was created by an AI agent. We're not demoing that live today, but this content was created by an AI agent that replaced lots of content on the site with "DrupalCon" and replaced a lot of terms on the site with "DrupalCon." So it's AI going rampant, in a sense.

[00:40:13] When you look at the workspace, you can see what's been changed in your AI agent workspace: lots of changes, lots of media images, and you also have configuration updates listed at the bottom, using WSE Config.

[00:41:06] The important thing to realize is that it's not just content that's been majorly updated; that's a view that's been updated as well, with additional configuration in the change set, in the workspace. This shows where the change is happening.

[00:41:35] Okay, we have one more. These are changes we're putting into content, in the title and in the description or body.

[00:42:29] This is moderated content. This change was made as moderated content, and then it's been imported into a workspace using what we're calling virtual workspaces at the moment. So it's like using normal content moderation, but now it's being imported into a virtual workspace. You can imagine all these disparate changes on your site made with content moderation, then bulked into a virtual workspace.

[00:43:07] So, we've talked a lot about Workspaces and seen some demos. In summary: it's stable, it's in core, it's fast and simple to use, it's the perfect AI sandbox, and it's a must-have for safe AI integration. It provides strong support for content creators and enterprise support for content workflows and governance. We need you to start using it. Workspaces is stable, it's ready, so test it, use it, and report what you find. The AI age needs this infrastructure now. And I think we have some time for questions.

[00:44:06] Okay, any questions out there? Audience: Canvas. Does it work with Canvas? You've heard a lot about Canvas. Does it work with Canvas? I'd say I'm not entirely sure. I believe it's a slightly different implementation, and I think Workspaces goes with the Layout Builder approach versus the Canvas approach. I don't know enough about Canvas to speak to it specifically. [After discussion] Yes, it will. We've been discussing it over the last couple of days, and yes, it will.

[00:44:48] Okay, any other questions back there? Audience: If you have a CDN or Varnish cache, will it work with that, or does it need something extra? The question is: if you have a CDN or Varnish cache, will it work, or does it need something extra? It will work in terms of your anonymous content: there's no change to your anonymous site usage. In the same way, you're not likely to have a lot of that caching enabled for your content editors, so it'll work in the same sort of way. As long as you have it set up appropriately for the content editors using the site, it should work fine.

[00:45:44] Audience: How do you deal with permissions for users you don't want to see the work happening in a workspace? Say I want someone to review it before we publish. Can you control permissions for a public or anonymous reviewer? The question is how you deal with permissions for users you don't want to see what's happening in the workspace, and for pages you might want to send to anonymous users to review. I don't know every detail, but I believe there's preview functionality where you can send reviewer links, and that would work for anonymous users to click on and use. [Confirmed] That's right. You can share the preview link, and in the permissions you select which users can access the preview. So what people do is create a role specifically to trigger this, assign it, and share the link. Essentially, you prepare roles for users and create preview links that apply to those users. And yes, that works for anonymous users as well.

[00:47:27] Audience: About static files uploaded inside the workspace: if it's public, is it available to users who know the URL? Say I upload a new JPEG, and someone goes anonymously to sites/default/files. Will they see it? The question is whether static files uploaded within a workspace are available to someone who knows the URL. I'm not entirely certain, but in the case of an image uploaded to Drupal that exists at a static URL, I believe Drupal would catch it. A file uploaded to a workspace is still covered by Drupal's standard security and features, so if you have it configured to be generally open to the world, it would be seen; otherwise, that should be caught by Drupal and Workspaces permissions.

[00:48:59] Audience: For changes like the views in the demo, how does that interact with the configuration export system? Does it exclude those views? The question is how the WSE Config changes we showed interact with Drupal's configuration import/export system. The straight answer is I'm not sure. What I imagine is that once it's published, you'd be able to export that configuration in the same way, so whatever is in live is what would be exported. I'm not 100% sure, but that's what makes sense to me based on what I know. It's an interesting question, because we use configuration import/export for a lot of things. This might be a case more relevant to sites that aren't necessarily using configuration import/export, that handle their configuration directly on the site rather than exporting it to code.

[00:50:20] Audience: Follow-up: if I create the workspace, make changes to a view, and then, in live, I do a configuration import from the view changes, how does it know what the mapping is? Now you're getting into different territory. The question is: if you import configuration before you publish a workspace, how does it know what the changes are? I think at this point the configuration in the workspace would override the configuration that was imported. However, I'm not sure whether there would be a flag telling you it had been changed.

[00:51:17] Audience: Similarly, on the conflict-free aspect of content editing: say you're adding a new section or a new campaign, so you create a workspace, but you also need to keep minor updates going on live. Can something like Workspaces Extra pull the changes you make directly on live into the campaign workspace, as long as they're not the same entities, so that when you publish they don't get overwritten? That's a good question, and probably the last one we have time for, but it's an important one. The question is: as you're working in a workspace and changes are happening on live, how does that affect your content, and can you pull those changes into the workspace? Going back to the git analogy, think of this as more of a shallow copy. It's not that copies of all your content live in the workspace; only the changes you make are in the workspace. So if you make changes to content on live, and you're not talking about the same content, those changes won't affect the content in your workspace.

[00:52:56] Thank you.