Transforming a Health System's Digital Presence using Workspaces by Tag1 Consulting

[00:00:10] (Introduction.) Welcome back, everyone. I have the pleasure of introducing Mike and Hank, who work at Tag1. I work with a team of content editors all over the world who are working in workspaces, on a platform supported by Tag1, and I can't express how grateful everyone is to have this team building this platform. I'll turn it over to Hank and Mike to present on transforming health systems with workspaces.

[00:00:50] Thank you. It's been a long day, so we're going to try to bring the energy. Thank you, George, for the introduction. My name is Michael Meyers, and I'm the managing director at Tag1 Consulting. I was a longtime client of Tag1; they helped me build the first Drupal-based startup, the first top 50 website to run Drupal, and they also helped me when I was at Acquia. I'm joined today by Hank VanZile, our senior director of customer experience, a longtime member of the Drupal community and a staunch open source advocate. Hank has helped a lot of agencies and organizations in the ecosystem be successful: as a VP at FFW he helped their explosive growth, and most recently he was head of professional services at Pantheon.

[00:01:50] For those who aren't familiar with Tag1, we build large-scale applications for large organizations in every industry and sector, including many in the healthcare space. We work with a lot of technologies, but we're best known as the number two all-time contributor to Drupal. Our team members are behind many of the innovations that have driven Drupal's success over the last twenty years, from the taxonomy system almost twenty years ago to the Migrate subsystem, a lot of the performance and scalability work, the automated QA system, Drush, and what we're going to talk about today, which is workspaces. A lot of healthcare organizations still have a Drupal 7 portfolio. We're the only Drupal 7 extended support provider that is also a certified upgrade partner, so if you need help with your Drupal 7 end of life, we can keep your site secure and help you plan your upgrade.

[00:02:42] Here's a quick overview of what we'll cover. We'll give you an overview of the project that uses workspaces, talk about some of the mission-critical challenges we solved with it, explain what workspaces is and how it works, and most importantly give you a demo, and then hopefully have time for Q&A.

[00:03:13] Thank you, Michael. Unfortunately, folks, there's no AI in our presentation today; we didn't get the note that that was required. I will cop to the fact that my headshot is AI, so maybe that counts. Let's talk about this client. Unfortunately we can't name them, but they are a renowned academic health system at the forefront of integrated care and advanced research. They're an extensive regional health system with more than a dozen hospitals, over 300 ambulatory care sites, an integrated medical school, and a focus on world-class specialty care. Some of you may have figured out who this is, and that's okay.

[00:04:01] One of my favorite things about them is that they're committed to providing excellence across the diverse communities they serve. The metro region they serve is one of the richest in America and also one of the poorest, and that matters a great deal to them. They were also determined to accomplish a long-needed digital transformation and a universal rebrand at the same time, on an aggressive timeline. They don't do anything halfway.

[00:04:42] Let me talk about the before state, which is a common problem a lot of you will recognize. Two independent platforms, each running hundreds of Drupal websites, owned by different organizations with a close relationship but minimal coordination. They had different everything: branding, design, structure, how they worked as organizations, how they approved things, legal reviews, and different levels of funding and resources. Different systems, workflows, and tooling. Because of turnover, they had limited institutional knowledge of these systems. On one organization, literally one person who still worked there knew a fair amount about the tech, so migrating off it onto a shared solution was challenging.

[00:05:41] It makes sense as a solution, though. Organizations benefit from an economy of scale, working together, sharing costs and technologies. It's a lot of what Drupal is used for, especially in healthcare, education, and other sectors. The biggest drawback is that you don't want to handcuff yourself to a partner. So how do you achieve that economy of scale, work together on a shared platform with a shared look and feel, but not hold each other back day to day, especially when one of you is the bigger fish in the pond and the other doesn't want to get stuck?

[00:06:20] When we see organizations like this, it shows up in the project. This highly decentralized organization had numerous partner agencies; there are several of them in this room, in fact, all involved in different ways and aligned to different parts of the business. There were multiple legacy systems requiring data migration and feature rebuilding, one of which was a public-facing legacy system with a hard end-of-life deadline and no options for ongoing security support. It wasn't Drupal 7, but it was a CMS that was vulnerable.

[00:07:01] Between replatforming and rebranding, most of their content needed to be transformed; it wasn't going to be a lift and shift. Their user base was completely diverse: content editors, marketers, and IT people in all kinds of parts of the organization, and they all needed Drupal training, since few of them had used Drupal before. And then all the things we know well: regulatory, legal, stakeholder review. It was a really complicated project.

[00:07:43] A lot of the time we're brought into a project when things have gone wrong or there are big challenges to solve. We came in initially to do expert consulting, particularly around a shared architecture, process, and tooling: how do we help more agencies coordinate and work together? As the project grew, so did our role. We continued in a technical architecture and leadership role, introducing more process, more manual reviews, more automated tools to reduce the manual reviews, and gatekeeping, making sure the architecture we'd agreed on was actually being implemented so the train stayed on the tracks. We did more project management across the shared aspects of the platform, built key pieces like the data migration and workspaces, and eventually took over leading a lot of the development.

[00:08:53] Let's talk about how we addressed some of the most critical challenges, which all leads to workspaces. The first is that we had no choice but to execute a number of projects in parallel. Michael and I were saying the other night that it was at least two projects, because a lot of these things merited being their own projects, but they were happening at the exact same time. The good news is that with shared standards, multiple teams can be a superpower; it's just not easy to do.

[00:09:30] Work was segmented along a number of lines. Along technical lines there were people responsible for UX and Storybook, front-end developers building reusable components, backend developers, and a ton of APIs to integrate, plus site building. There was business-line segmentation too: one group for the health system site, one for the medical school, and another building sites for the smaller urgent care, ambulatory care, and specialty locations. All of that was done with coordinated release management, which is what made the pieces come together, so that by the time things went into production they had all been normalized.

[00:10:24] We also had to extend the lifespan of the legacy content. The CMO leading the project was completely dedicated to transforming the content, not just lifting and shifting it, and that, combined with an aggressive timeline and an insecure public-facing legacy system, made it really hard. To help, we developed a content proxying solution. For pages without native Drupal content, it would intercept the page request at the CDN layer, request the content transparently from the appropriate legacy system, transform it, and deliver it within the visual frame of the new site in Drupal.

[00:11:30] This was heavily cached at the edge, so by the time the transformation was done we could recache it, and there was little to no noticeable degradation compared to a native Drupal page. That allowed a couple of things. It let them remove public access to the end-of-life system, which was significantly less risky than leaving it publicly available; they put it behind firewalls and everything else they could. And it let content editors keep making necessary updates in the legacy system, like changing office hours or noting that an office would be closed on Memorial Day, while they focused on preparing their new content.

[00:12:32] The final one I want to highlight, and this is where we get into workspaces, is that we introduced a more future-facing approach to content management and governance all at once. We used Drupal workspaces to give content editors a safe way to compose and stage content in the full context of the new site. With the legacy site they were editing in a little box; the new site had Layout Builder and all the trappings of a modern Drupal site, so instead of updating content in a single box, it was a visual composition. The CMO was really into this; it was part of the transformation and a whole new paradigm for most of these people. Letting them do it in a way that had audit and review built in, and that let them fail safely, is far more valuable than spending thirty minutes showing someone how to do it and then saying, now go do it.

[00:13:53] It let them get comfortable with the tools and eased the training burden. One of the things we really like about workspaces is that it removes annoying compromises like a content staging environment. They're doing their work where the content will eventually live, so there's no developer needed to shuttle it off somewhere else. And it provided end-to-end content governance during the transition: the same workflows and approval processes they use now that the platform is live, so they got used to it before it was their day-to-day work.

[00:14:44] I'll give you a quick overview of workspaces before the demo. I'm not going to sugarcoat it: Drupal's content management and staging has kind of sucked. It's a well-known weakness we've all suffered from for a long time. It's been complex, with a lot of use cases and ways to set up Drupal, and you typically have to move data and configuration across staging and production environments. Organizations have solved this in some capacity; it's not that you can't do it, it's that it's hard, requires developer investment in scripts, tooling, process, and workflows, and everybody reinvents the wheel. Then when it's time to release that content, you need developers again, so you're tied to your development infrastructure.

[00:15:39] None of these solutions were complete, given how complex they were. Even the content staging that existed was narrow. Even Drupal's page preview kind of sucked for a long time, and this is a core feature you'd expect in a content management system. There have been attempts over the years; the biggest and most successful was the Site Preview System, which Acquia largely funded as part of their Spark initiative, with Phase2 and Tag1 as big contributors. It did more than anything before it, but it still had too many complexities to be what we need today.

[00:16:39] At the same time, Drupal's competitors always had better solutions to this, and that's a problem when an organization is evaluating your CMS and it doesn't do content and site staging. So workspaces is, hopefully, something the community will adopt and embrace, because I think it takes Drupal to world-class status in what I'd call site staging, not just content staging. One reason it can do this is that it's tightly integrated into Drupal core; in fact, it is part of core.

[00:17:29] You can use it in a lot of scenarios. We use it in a streamlined fashion on production, where you create workspaces, work independently in them, and push a button to put things live. If you want physical segmentation with separate development, staging, and production environments, it supports that too. It works exactly like Drupal, because it's a virtual copy of your site, and you can have as many copies as you want. All the permissions, users, and controls are inherited by those workspaces. It's full fidelity, not a cheap preview; it looks and feels and works exactly like your site.

[00:18:22] There's a live workspace, which is your live site, and all the other workspaces you create. You can move change sets across workspaces, merge workspaces, put one live, or roll back. It also has more complex features like hierarchical relationships, where you can have sub-workspaces that inherit content from the parent.

[00:19:02] (The demo laptop needed a reboot.) One of the best things about it is that once you're up and running, your business users are in control. You're not dependent on developers to do your releases, which frees them up for more valuable work and lets your business users move at the speed they're capable of.

[00:19:47] So what can you version and change with workspaces? Pretty much everything. From a content staging standpoint, you can version your content: create new content, add or edit translations, all using the standardized workflows you've created for your compliance, legal, marketing, and department reviews. You can edit the fields on your content type, and add media, images, and video.

[00:20:32] Here's where it gets into an area that really makes it world-class and does things you could never do before. You can change the structure of your site. Want to add a taxonomy term or a whole new taxonomy? You can do that in a workspace and push that component live. You can change menu items and add menu hierarchies. You can version Layout Builder, changing the layout of sections and pages, preview how it will all work, and then push it out. Views is supported as well.

[00:21:10] Think about a hospital or an academic institution with lots of groups and departments, all trying to go live. It would be chaos if everyone was editing on the same instance of Drupal. Now each department can operate in its own workspace. Need to learn Drupal? Here's a copy of the site, go to town; you can't break anything. Everyone works at their own pace, independently, and those workspaces can be merged, rolled up, and deployed independently. It solves a lot of the publishing and deployment problems that have long plagued content staging systems: scheduled publishing, public preview links for a partner to check a workspace before you go live, and multi-environment deployment.

[00:22:26] I want to be upfront: workspaces is really powerful, but there may be work required depending on your use case to get up and running. It may not work fully out of the box. It was an experimental feature and a set of contributed modules for a long time, and a lot of people still think of it as experimental, which is not true. It's a full-fledged, fully functioning part of core; you check a box and it's enabled. It's also being integrated into Drupal CMS to power certain aspects out of the box, the way you'd expect a content management system to work. I can't believe it's 2025 and we're talking about this as a great new feature, because this is what people expect from a CMS.

[00:23:28] There's an active roadmap funded by a lot of organizations we work with. Some of the more experimental aspects have been moved to a module called Workspaces Extra, which you can enable as contributed modules, so we can maintain the pace of development while keeping core stable. Not everything works out of the box; it depends on how you're using views and Layout Builder, so expect a little development to get it running. One common request we hear is content locking: people want to edit the same thing in multiple places simultaneously. Right now, if you edit something in a workspace it locks in other workspaces. That's under development and will be available in the near future.

[00:24:42] It's extremely functional and scalable, with an architecture you can build on. If you need to invest in making your views or Layout Builder work, it's worthwhile; past implementations like the Site Preview System cost seven figures to build, and this does so much more, so it's a rounding error by comparison. We use this in production on several very large-scale systems for Fortune 150 companies and healthcare organizations. It's on your systems now; you should enable it and play with it. If you want to add features as part of the open source community, we encourage you to do so, and we're happy to help in the issue queues. Now we're going to prove it with a recorded demo.

[00:26:02] I'm not as brave as some of the others today; I didn't live-demo this. I recorded a demo to narrate live, though my hotel room last night will tell you that wasn't as easy as I thought on Friday. We're going to do this demo on the Umami Health System demo, built in Drupal 11. You can see workspaces is installed, with the switcher in the top right corner. We're currently in the live workspace. If I go to modules and filter, you can see the core workspaces module, the workspaces UI, and Workspaces Extra installed, with Layout Builder and menu support.

[00:27:02] One of my favorite Workspaces Extra features is the simplified workspace switcher, so I'll turn that on. Let's head back to the homepage. I'll do a basic node edit here, using the super easy vegetarian pasta bake, and switch to the staging workspace. My favorite thing about workspaces is that it doesn't change the way you work. I hit the edit tab, update the title to "even better vegetarian pasta bake," make it emphatic in the summary, and save the translation. That's just Drupal; the changes are right there. But if I switch to the live workspace, they're completely contained in staging; the live site is unaffected. Switch back to stage and there they are, waiting for review.

[00:28:13] It's not limited to titles and bodies. I can edit a taxonomy; honestly, this dish is more of a snack than a main, so I'll update that. I'll change the media to a better picture, fix a typo (whole wheat is two words), and, since I promised it was better, double the mozzarella. I can even update the URL, changing the path to "even better vegetarian pasta," and all of that lives in the workspace. When I save, you'll see the updated address, taxonomy, picture, and ingredients.

[00:29:17] Layout is a possibility too. I've got the Workspaces Extra Layout Builder module enabled, so I'll make some adjustments. Same workflow as any Layout Builder: click the layout tab, put the ingredients on the right and directions on the left with the regular visual tools, and save. You can see the changes immediately, but if I swap back to live, nothing leaks into the live environment. Production, yes; live, no. That's a different paradigm.

[00:30:22] Back on the homepage, you'll notice the block didn't update, because in Umami this is an independent block. Workspaces can handle blocks too, so now I'm getting into site staging. I'll update the block to my even better vegetarian pasta bake, update the button and its link to the new URL, and change the picture. Save, and there's the block, and, wow, that's a lot of cheese. The link works fine and goes to the staged page.

[00:31:04] That's a lot of changes, and I want to see all of them, so I'll go to the manage workspace link. This is one of the great things for working with teams: a full list of all the changes, each with an operations menu where you can move a change to a different workspace or delete a single change. When you want to publish, it's one publish button. I just deployed the whole thing, and in the top right corner all of those changes are now live.

[00:31:35] This client is actually using workspaces to bring on whole departments and sections of their site bit by bit. I'll demo that by adding a nutrition blog. First I created a new workspace for it, then I'll add some blog posts. There's already a view sitting there waiting, which is how we work with this client: the developers build a view because it's easier for them to consume. Now I'll add a menu link to the new blog landing page the normal way, through configuration and the main menu, pointing to /blog. Save, and it's in the site. Click through and there's the landing page with all the new posts. All of that is resident in the workspace; switch to live and it's simply not there.

[00:33:24] We'll swap back to the blog workspace and, just like before, pretend we've gone through all our audits and reviews. It's a single button; I publish seven items, go to live, and the entire new feature is available. Here we are on the live workspace, with the nutrition blog and all its content. That's our demo.

[00:34:11] (Q&A.) There are a couple of ways it works. It integrates with all the standard workflow and content moderation aspects. There's work going on right now for Drupal CMS to refactor content moderation to be based on workspaces, because right now they're two separate systems that work together. If you want people to review something bigger, like a blog section, and they have permission to see the site, it integrates with all the standard Drupal permissioning. With this particular customer we're using the Groups module heavily, so certain departments can see certain things and others can't. And Workspaces Extra has a contributed module that allows a public preview link, so you can let someone take a look without ever logging into Drupal.

[00:35:51] (On reviewing changes.) It depends on your permissioning. If you allow everyone who needs to review access to development, they can click the workspace switcher and show the blog workspace, though they'll probably want the manage view, which is where the audit is that shows everything. As Michael mentioned, Workspaces Extra also has work for deploying a workspace from a physical dev environment to physical staging or production. We don't use it that way; we like giving people one place to do all their updates. But it lives in a standard database, so if you pull prod down to dev, it comes along for the ride.

[00:37:21] (On Content Sync.) Content Sync has a wider array of features, but this could have that deployment workflow too.

[00:37:40] (On storage.) It's in the main database, using standard Drupal objects. There's a separate flag on all the different entities saying it belongs to a workspace, plus a hash code, so it all lives in the same places in the database as the rest of your content. There are some separate tables for tying things together, and the mechanism is revisions. Thank you, that's what I meant to say; that's why we brought him.

[00:38:48] (On parallel work.) It allows parent and child workspaces. I could set up the blog and start putting in the content, while your job is to work on other features like the tag cloud, and those could be children workspaces underneath the blog workspace, deployed up to it separately. You finish your work faster than I do, it's in the main blog and ready to go, I finish mine and it gets through review, we merge it up into the blog, and the whole thing can go live at once.

[00:40:06] (On effort.) The work is relative to your needs and the capabilities of workspaces. Some of the views capabilities aren't there yet, so if you want specific things with views, you might have to build that out, and the cost is associated with whatever capabilities you need. If the hierarchical parent-child inheritance isn't exactly the way you want, it might need a little development effort.

[00:41:07] (On code.) You'd still follow your standard development, staging, and production workflow for the code. This is more about site-building capabilities: Layout Builder, text, changing the site through point-and-click interfaces, and creating content. Those are the things you version through this, not the underlying code. That would be pretty something, though; I think that was called the Features module, and I still have nightmares.

[00:41:49] (On enabling entities.) You need to add the appropriate workspaces revision fields into your code, but it's roughly a single-line change to say this entity can be used with workspaces. That's some of the work still going on in core. If you've used workspaces, every now and then you hit something, like the navigation module currently stumbling when workspaces is installed, because it hasn't had that one field added. Andrei on our team is sniffing those out bit by bit; every couple of days there's a new one. It's really simple to make pre-existing things work in workspaces.

[00:43:08] (On content locking and merging.) That's what's behind content locking right now. For version one it was easier to say Chris is editing this thing, so don't let anyone else touch it, which is a classic paradigm. The hard part is when two or three of us are working on things and you have to decide who wins. Git still struggles with merges all over the place, so that's what we're figuring out: when you bring several of these together, is it as simple as whoever went last bubbles to the top? That might be the ultimate decision. If you did them individually and deployed them individually, it would use standard revisioning; if you try to merge multiple changes together, it gets a little squishier, but we're on the trail.

[00:44:15] (On contact forms.) I believe so; it wouldn't be hard to make it work, because a contact form can be revisionable. If it doesn't work already, we literally call Andrei and have him add that field.

[00:44:43] The workspaces channel on the Drupal Slack is a great place to ask this stuff. A few other organizations are using this in large production environments. Purple, the mattress company, is a big contributor to workspaces in Drupal, and they do exactly what you're describing: they ran their whole end-of-year campaign cycle in workspaces, and used another of the Workspaces Extra modules, scheduling, to schedule all their campaigns to go live at certain times. Very brave, and it worked like a charm.