The current landscape
Each platform takes a slightly different angle. Storyblok’s FlowMotion is an event-driven orchestration layer with a visual workflow designer that converts content events into automated sequences. Contentful’s AI Actions focuses on bulk content operations: generating, transforming, and translating metadata at scale, with a flexible choice of AI model. Contentstack combines Automate for low-code workflow automation with Agent OS, letting teams build AI agents that handle repetitive tasks and multi-step processes without manual intervention. Sanity’s AI Assist and Content Agent cover in-studio writing assistance through to content auditing and bulk operations at scale. For process orchestration, Sanity now offers native automation through Functions and Agent Actions.
However, the message from most of them is the same: you should not have to leave the CMS to run your content operations. That framing deserves a closer look, because “content operations” and “what your CMS manages” are not the same thing (historically).
The efficiency case is real
Before I push back on anything, I want to be clear about what these tools are solving. Content operations produce a real coordination overhead: approval chains, translation handoffs, SEO review, scheduling, localisation checks. These eat real hours.
Storyblok cites research suggesting marketers spend over six hours a week on content coordination alone, which is consistent with a wider pattern: Asana's Anatomy of Work Index (source: Asana), which surveys over 10,000 knowledge workers annually, finds that coordination, approvals, and status-chasing account for nearly 60% of the average working day, time spent managing work rather than doing it.
So routing a content event through an approval sequence, triggering a translation job, updating metadata, and publishing to a schedule: is definitely a useful capability. The question I am asking is whether the CMS is the right home for it.
Content operations starts well before the CMS
The CMS historically is where content lands. For most of the organisations I work with, it is typically not where content is made, planned, reviewed, or approved. Those activities involve writers, subject matter experts, editors, campaign managers, and legal teams, and they happen in project management tools, Google Docs, Slack, and review tools.
Map out a typical content lifecycle and you get:
- 1
Strategy
- 2
Briefs
- 3
Production assignments
- 4
Writing
- 5
Subject matter expert review
- 6
Editorial approval
- 7
Editing
- 8
Asset enrichment (or via DAM solution)
- 9
Distribution coordination,
- 10
Publication scheduling.
You are therefore aligning the solution with the last part of the journey. The coordination overhead that eats most of the time (planning cycles, review loops, approval handoffs between people who may not even have CMS access) lives upstream. A CMS-native automation layer only activates once content has crossed into the platform. Everything that happens upstream of that boundary is largely out of its reach.
Shifting that to the left, can be a valid and deliberate strategy. But it is worth being clear about what it means beyond the automation layer itself. You are deciding how a broader group of people (writers, reviewers, campaign managers, possibly legal) will interact with the content process. People who were not previously CMS users may need to become ones, which involves substantial change. Approval chains and task assignments that once lived in Monday or email now live in the platform. So you are not just turning on a workflow trigger, you are committing to the CMS as the operational system for a broader group of people, and tying their day-to-day to a vendor’s roadmap and commercial trajectory.
Worth noting too: most of these automation capabilities sit behind enterprise tiers or paid add-ons. That cost compounds as the process expands and should be accounted for from a TCO perspective.
We have been here before
In case you are thinking this is a new development: it is actually not.
The ambition to own content operations from within the CMS has been part of the enterprise CMS story for a ‘long’ time. Adobe Experience Manager had approval workflows, content review chains, and DAM-integrated publishing processes long before “content operations” became an industry term. In tightly governed enterprise environments they were actively used. And yet the coordination work involving people outside the CMS consistently ended up in other systems. The CMS handled what happened inside it. Everything upstream lived elsewhere.
What is more telling: Adobe later acquired Workfront (in 2020), a project management and work coordination platform, and positioned it as the orchestration layer alongside Creative Cloud and Experience Manager. Even with one of the most feature-rich CMS environments in the market, they recognised the workflow problem extended beyond what the CMS could contain.
AI accelerates that ambition and makes the pitch more credible, because automation can now handle complexity that brittle rule-based workflows could not. The underlying structural question, though, remains the same.
However, do take basic task management as a cautionary signal. CMS platforms have offered boards, content calendars, and assignment workflows for years, and adoption often has been underwhelming. For a fact, almost none of the teams I talk to use the CMS for this, even when the feature is right there.
They use Monday, Notion, or Jira, because those tools handle everything else: campaigns, product launches, agency coordination, budget tracking. The content work lives next to everything else it belongs to. The CMS task feature did not fail because it was badly built. It failed because the team’s operational gravity was elsewhere.
That is the pattern worth watching. Content work is not an isolated process, and the tools that handle the broader operational context tend to win regardless of feature parity. If workflow automation follows the same adoption curve as task management, a lot of teams will end up with potent and powerful orchestration features inside their CMS that nobody actually uses. So if you go that route, make sure adoption is pursued, otherwise it’s a missed opportunity.
Where should the logic actually live?
Orchestration logic has to live somewhere. Every workflow automation feature in every CMS is essentially saying: let that somewhere be us. But there is a reasonable argument that content events should be inputs to a process engine, rather than the process engine being embedded inside the content system itself.
A meaningful content workflow touches a project management tool, a translation service, a DAM, a review step in Slack or email, an SEO audit, possibly a personalisation layer, and a deployment pipeline. The content lives in the CMS. The process that governs it does not. Putting orchestration logic inside the CMS means one of two things: either the process stays narrow (only touching what the CMS can reach), or the CMS grows into a general-purpose integration hub.
Both have pros, cons and definitely costs. There is also a practical risk: teams build early workflows inside the CMS because it is the path of least resistance, to then discover twelve months later that half the process falls outside what the CMS can orchestrate. Migrating that logic is not quick work.
The general-purpose platforms point toward a different answer. FlowMotion is a useful illustration: Storyblok built it on top of n8n, a workflow automation platform with a visual workflow designer and its own AI capabilities. What you are buying as an Enterprise add-on is a managed instance with pre-built content event triggers and a tighter integration surface. The underlying infrastructure is not proprietary to the CMS vendor. The orchestration layer is assembled from existing automation tooling, with the CMS integration as the differentiator.
Worth looking at alongside the CMS-native options is the category of open-source, self-hostable workflow platforms. n8n is the most visible example: it is what Storyblok used as the foundation for FlowMotion, which says something about where it sits in this ecosystem. What platforms like n8n all share is that they sit close to your infrastructure, connect to any system with an API, and let you own the orchestration logic without handing it to a SaaS vendor. They can thus more easily reach the full content lifecycle, not just the CMS end of it.
Zapier and Make operate at a different level: managed, no-code, and built for breadth rather than depth. Both have been adding AI capabilities steadily: agents, natural language workflow creation, MCP support. The trade-off is that your process logic runs on someone else’s infrastructure, subject to their pricing tiers and rate limits. For less technical teams or simpler processes, that can be the right call. For more complex or sensitive workflows, it is worth factoring in.
There is a broader tension worth naming here, and it runs through the whole category. Headless CMS platforms were originally built on a clear philosophy: do the content part well, stay out of everything else, and integrate cleanly with whatever surrounds you. Separation of concerns. That was the founding argument against monolithic platforms like Adobe Experience Manager. You pick the best tool for each job, and the CMS is the best tool for managing and delivering content.
What is happening now pulls in a different direction. Every major platform is adding orchestration, workflow automation, AI agents, and operational logic. Some are explicit about the ambition: the pitch is no longer just “manage your content here” but “run your content operations here.” The CMS is reaching for the centre of the stack, not just a well-integrated part of it.
That is not necessarily wrong. But it is worth recognising it as a shift. The platforms that won on the argument of being focused and composable are now building toward the kind of surface area they once positioned against. For teams choosing or evaluating a platform, that shift matters. You may be buying into a focused content tool today and an operational platform tomorrow, with the roadmap, pricing, and dependencies that come with it. Whether that is the right direction depends on your organisation. But it is a different question than the one most teams ask when they evaluate a CMS.
The managed abstraction inside the CMS is easier to get started with and easier for non-engineers to maintain. But its scope is bounded by the CMS itself. For teams whose content process extends into planning, campaign coordination, or cross-functional review, that boundary matters.
How I would think about the decision
I would not frame this as a simple choice between CMS-native tools and external ones. In practice the question is about scope.
If your content workflow is largely self-contained (translation, SEO review, approval, publish) and your content team operates independently from the rest of the organisation, CMS-native automation is probably a reasonable choice. The integration surface is small, the convenience is real, and you are not forcing the tool to do something it was not built for.
If your content workflow is part of a broader campaign or product process, if it touches systems outside the CMS, if the people coordinating the work already run everything else through a project management tool, then placing your orchestration logic inside the CMS will create a split. Part of the process lives in one place, part of it in another, and at some point you will need to bring those two sides together. That reconciliation tends to be harder and more expensive than making the right call upfront. In those situations, a workflow platform (genre: n8n, Activepieces, Windmill, etc..) close to your infrastructure and connected to the full process surface is likely a better fit than anything native to the CMS.
The question I would ask before any of these decisions is not “which vendor has the best automation feature?” It is: what is the actual scope of the process we are automating, and which system is already the operational home for the people running it? Those two questions tend to point to the answer more reliably than any feature comparison does.
Let's talk about it
This is a conversation I am having with a lot of teams right now, and the answer keeps being different depending on where the real complexity sits in their organisation. If you are working through this decision, or if you have landed somewhere on it that I have not considered here, I would like to hear about it. Let’s have a chat.
Book a call with us