3M's marketing operations team explain how they replaced a patchwork of manual, hard-to-audit approval processes with one Workfront-based system, cutting cycle time and giving every market a consistent, auditable way to approve content.
Overview
Every organization has a review and approval process. The question is whether that process was intentionally designed, or simply evolved over time.
At 3M, when we inventoried how marketing content was being reviewed across our three large business groups, the approval landscape was a fragmented mix of tools and habits. Some teams relied on email or Microsoft Teams. Others used Power Automate, Adobe Experience Manager Assets, locally configured workflows, meetings, or verbal signoffs. In some cases, approval was effectively a handshake deal with the person sitting behind you.
Individually, many of these approaches had developed for understandable reasons. Collectively, they created a fragmented environment that was difficult to track, audit, support, and improve.
For content going to market, we needed to answer a deceptively simple question: was this approved, and can we prove it?
If the answer depends on finding an old email, locating meeting notes, or remembering who was in the room six months ago, the process is not truly scalable.
Start with the operating model, not the workflow
It would have been easy to approach this as a software project. We already had Adobe Workfront managing a high volume of work across our digital marketing operations organization. We could have started by asking how to build another approval workflow in Workfront.
Instead, we took a step back.
We asked what an enterprise review and approval capability actually needed to accomplish.
We were not simply trying to replace email with another tool. We needed a repeatable operating model that could support different business groups, markets, functional teams, policies, and regulatory requirements while remaining understandable to the people using it.
A handful of principles guided the work:
-
The process needed to be transparent. People should be able to see how an idea moved from concept to approved content and understand why particular reviewers were involved.
-
It needed to be auditable. Content did not just need approval; we needed confidence that it had been reviewed by the right people and that those decisions could be verified later.
-
It also needed to be maintainable. Enterprise implementations can drift toward heavy customization because every organization has unique requirements, but every customization introduces something else to document, test, support, and eventually update. We intentionally resisted over-engineering the solution around every individual process.
-
Workfront would manage the work. Workfront Proof would provide the structured review experience. Workfront Fusion would orchestrate the automation connecting them.
We wanted to maximize the value of Workfront's standard capabilities, then extend them only where doing so solved a meaningful business problem.
That distinction became important. We were not trying to preserve every process exactly as it existed. We were deciding which parts should be standardized, which differences were legitimate, and where automation could simplify the experience.
Make the easy path the right path
Our first step was relatively straightforward. We gave teams access to the out-of-the-box capabilities in Workfront Proof and allowed them to create structured workflows for review and approval.
The feedback was immediate.
People knew who was expected to review the content. They could see when the review was due. Automated reminders reduced manual follow-up, and the workflow created clearer accountability. We also began to see production cycle time move in the right direction.
That initial value mattered because it demonstrated that we did not need to automate everything at once. Standardizing the experience was already better than relying on disconnected emails, meetings, and local processes.
The next challenge was making that experience work across a complex global organization.
A content owner should not need to remember which legal representative, marketer, application engineer, regulatory partner, or regional stakeholder belongs in every review. Even experienced project managers cannot be expected to carry that entire decision tree in their heads.
If the new process still depended on users manually identifying every reviewer, we would simply be replacing one manual process with another.
That led us to dynamic routing, or as we called it, Computed Workflows.
Instead of asking users to construct an approval path themselves, we gave them a mechanism to request a review.
Based on factors such as geography, content type, business requirements, and functional ownership, Workfront and Fusion determined which groups and approvers needed to participate and created the appropriate workflow in Proof.
For the user, the experience became simpler. For the organization, the process became more consistent.
Good enterprise design does not always eliminate complexity. Often, it moves that complexity away from the end user and into a system where it can be managed, documented, and improved.
Automate predictable decisions
The value of dynamic routing was not just fewer clicks. It was consistency.
When approval paths are selected manually, they are influenced by memory, experience, and habit. Two people working on similar assets can assemble different review teams because they interpret the requirements differently.
Automation allowed us to apply predictable decisions consistently.
That did not mean eliminating human judgment. It meant automating the decisions that should already be governed by known rules, while preserving human judgment for the content itself.
We also learned that building automation and building maintainable automation are not the same thing.
Initially, the routing logic appeared relatively straightforward. Once we got deeper into Fusion and started accounting for different markets, business groups, functional responsibilities, and policy requirements, the complexity became clearer.
We could have hidden all of that logic inside the automation. Instead, we invested additional time so administrators, and where appropriate, business super users, could open up the configuration, understand it, and make changes without rebuilding the entire solution.
That extended some timelines of our integration work, but it was the right decision.
A solution is not scalable simply because it can process more work. It also needs to be supported by more than the small group of people who originally built it. If only one specialist can understand or update an automation, the organization has traded one operational risk for another.
Roll out at the pace the business can sustain
Once the solution was ready, we deliberately avoided a big-bang global deployment.
Japan had an existing country solution approaching end of life, which gave us both a deadline and a clear business need. The local team was curious, engaged, and ready to partner with us. That made Japan a strong first market.
Starting there helped us minimize operational risk while maximizing what we could learn from a real production deployment.
We moved from having no central solution to launching in Japan over approximately two months. During the initial hypercare period, we found a few places where the dynamic logic needed adjustment. Someone unexpected might appear in a workflow, for example, and we would trace the rules to understand why that person had been selected.
Those early refinements were not failures. They were exactly the kinds of insights that are difficult to uncover in design sessions but become obvious when real people begin using the system.
The rollout also reinforced that transformation is as much about mindset as tooling.
We developed documentation, training materials, webinars, and internal portal content. Because Japan was the first market, we made sure local-language support was available and that someone could help connect the central implementation team with the needs of the market.
We wanted the solution to feel as though it was being introduced with the local team, not delivered to them.
From there, we continued incrementally, country by country and, in some regions, business unit by business unit. That approach allowed us to keep pace with what the organization could sustain while validating that the solution could be extended without losing its structure.
Measure what changed
We approach major marketing operations initiatives with metrics, KPIs (key performance indicators), and reporting in mind. We only do things that we can measure.
Cycle time was one of our primary indicators. We tracked it monthly during the first year to understand whether content was moving through review and approval faster.
We also measured workflow complexity, including the number of approval stages and reviewers.
The goal was not to reduce scrutiny. It was to make scrutiny intentional. A workflow with ten reviewers is not automatically more compliant than one with five. Too many participants can make ownership less clear, extend timelines, and involve people whose expertise is not required.
Another important measure was time to first activity: how long it took a reviewer to begin working after receiving the notification.
In a traditional email process, an approval request might sit in an inbox for two or three days before anyone opens it. The project owner has little visibility and often needs to follow up manually.
With Workfront and Proof, reviewers began engaging sooner. We saw a 55% faster time to first activity, a 46% reduction in overall review cycle time, and a total financial impact of more than $1 million for the Japan market when considering productivity improvements and cost avoidance.
The results confirmed the approach, but the most important outcome was confidence.
Teams had greater confidence that the right reviewers were involved. Reviewers knew when action was required. Project owners could see where content was in the process. The organization had a clearer record of who approved what and when.
Build for the next review experience
The work also created a foundation for what comes next.
At 3M, we are beginning the next phase of this journey with Adobe Unified Review and Approval, using Frame.io as the review surface. We see that as an evolution of the capability we have already built, not a restart.
The review experience will continue to modernize, but the operating model behind it remains relevant. We still need to determine the right reviewers, apply routing rules consistently, maintain a reliable record of decisions, and give teams visibility into how content moves toward approval.
Because we invested in those foundations first, we are better positioned to adopt a new review experience without having to reconsider the entire process behind it. The interface can evolve while the governance, automation, and decision logic continue to scale with the organization.
That is another reason to design beyond the tool in front of you. A sustainable operating model should be able to support the experience you use today and the one you adopt next.
What I would carry into another implementation
Looking back, I would keep most of the approach the same.
For another organization starting this work, my first recommendation would be: don't start with the technology.
Map the real processes in place today, not just the official process. Understand where reviews begin, who participates, why they participate, how decisions are documented, and where work tends to stall.
Second, separate necessary complexity from inherited complexity.
Some requirements exist for legitimate reasons: regulations, technical claims, copyright policies, legal obligations, or market-specific rules. Other complexity exists because someone was added to a workflow years ago and no one revisited the decision.
The goal is not to make every approval path identical. It is to create a common model that can account for legitimate differences without rebuilding the process for every team or market.
Finally, design for the people who will maintain the solution after the implementation ends. Make routing logic understandable. Surface configuration where possible. Document why the system makes its decisions. A technically impressive automation is not truly scalable if only its creator can support it.
It also takes a village.
Architects, administrators, business stakeholders, functional reviewers, regional partners, and end users all see different parts of the problem. This was not something we could give to one person to solve independently.
The volume of content moving through creative and production pipelines is only increasing. Review and approval cannot become the part of the process that fails as demand grows.
Workfront, Proof, and Fusion gave us the capabilities to bring the initial solution to life. Unified Review and Approval represents the next evolution of that experience. But the lesson remains the same.
Technology makes it possible. The operating model makes it sustainable.
FAQ
Why not just build another approval workflow directly in Workfront?
Because the real problem wasn't a missing workflow, it was a missing operating model. 3M needed a repeatable way to handle transparency, auditability, and maintainability across markets, not just one more tool layered onto existing habits.
What is a Computed Workflow?
A dynamic, rules-based workflow where Workfront and Fusion automatically determine which groups and approvers need to participate, based on factors like geography, content type, and functional ownership, instead of requiring users to build the approval path themselves.
Why did 3M start with Japan instead of a global rollout?
An existing country-specific solution in Japan was approaching end of life, giving the team both a deadline and a motivated local partner. It let 3M minimize risk while maximizing what they learned from a real production deployment.
What results did the new system produce?
A 46% reduction in overall review cycle time, a 55% faster time to first activity, and a total financial impact of more than $1 million for the Japan market from productivity improvements and cost avoidance.
What's the biggest piece of advice for a company starting similar work?
Don't start with the technology. Map your real processes and stakeholders first, separate necessary complexity from complexity nobody has revisited in years, then decide what the technology should automate.