Workfront only delivers value when teams actually use it and leadership can trust what it shows. Here is a practical look at how architecting the core objects, Issues, Projects, and Tasks, turns fragmented, anecdote-driven work into one connected narrative that replaces guesswork with data.
The questions behind the architecture
I've always believed that Workfront only matters if people actually use it. Not in a "check the box" way, but in a real way where users feel confident, they can find their work, understand what's expected of them, and trust the system enough to let it guide their day. My job, at its core, is to build that confidence. To build a space where work feels connected rather than scattered.
The implementation I'm supporting now is technically not new. They had Workfront before I arrived, but it was fragmented. Creative was off doing its own thing. Marketing was doing their thing. Both teams depended on each other, yet their Workfront worlds never touched. It was like watching two people try to dance to the same song while wearing noise-canceling headphones.
My role became simple: connect the dots.
-
Where does writing intersect with marketing?
-
Where do handoffs actually happen, not theoretically but in the messy reality of day-to-day work?
-
How do we control intake?
-
How do we define priority in a way that leadership can stand behind?
These questions are the heart of Workfront architecture. They are also the heart of human work.
The big three objects: Issues, Projects, and Tasks
When I talk Workfront with leadership, I always come back to the big three objects: Issues, Projects, and Tasks.
They are not just system objects. They are the narrative structure of how work enters the organization, how it becomes real, and how it gets done. When these three are constructed intentionally, leadership gets a clear, top-down view of the entire marketing and creative ecosystem.
Issues: The gatekeeper of work
An Issue, or Request, is the front door. It is where work first announces itself and says, "I think I belong here."
Issues let us determine:
• whether the work aligns with marketing goals
• whether it fits current priorities
• whether it represents a real opportunity or just noise
A well-built Request Queue becomes the organization's intake guardrail. It ensures that work coming in is the right work, not just the loudest work.
This is where leadership gains confidence that the team is not just busy, but busy with the right things.
Projects: The blueprint for how work gets done
Once an Issue is approved, it becomes a Project. This is where architecture really matters.
Projects are built from templates designed using historical data. They include service level agreements (SLAs) that reflect real delivery timelines, milestones that match actual process flow, resource allocations based on past capacity, and review and approval steps that mirror how work actually moves.
A Project is the organization's promise. "This is how we do this type of work, and here is how long it should take."
It is structure, clarity, and predictability. All the things leadership needs to make decisions without relying on anecdote.
Tasks: The actionable steps that bring work to life
Tasks are where the work becomes human again.
They are the actionable steps inside a Project, assigned to a single User, a Team, or, with Workfront's AI evolution, an Agent or Collaborator.
Tasks show who is doing what, when, and why. They reveal bottlenecks, capacity, and collaboration patterns across Marketing, Creative, and Channel teams.
Tasks are the heartbeat of the system. They are the place where work stops being theoretical and becomes real.
Together, they create a leadership narrative
When these three objects are intentional, leadership gets a clean, layered narrative:
1. What work is being requested (Issues)
2. How that work is structured and resourced (Projects)
3. How that work is executed and shared across teams (Tasks)
It is a top-down view that replaces assumption with clarity, replaces anecdote with data, and replaces "we think" with "here is what is actually happening."
It is Workfront as it was meant to be, a connected ecosystem where intake, planning, and execution tell one unified story.
This is not anecdotal anymore
Before Workfront, most organizations lived in anecdote. Status meetings were basically storytelling hours.
"My project is stuck." "We are waiting on feedback." "We are overloaded."
Leadership would ask for proof, and teams would shrug. Not because they were hiding anything, but because they did not have anything.
Workfront changes that.
Now we can show the last update, the stalled approval, the reviewer who has not responded, the task that keeps slipping, and the process step that is always the bottleneck.
Not to blame anyone. Not to shame a team. But to see reality clearly.
When we look historically and notice that a certain project type always gets stuck at the same step, that is not a people problem. That is a process problem. Workfront gives us the clarity to fix it.
What truly is being resourced
One of the most common refrains I hear from middle management is: "We are understaffed. We are overloaded. We cannot keep up."
Leadership responds with: "Show us the numbers."
Workfront lets us do exactly that, if we build it intentionally.
Estimated hours, durations, and allocations are not just fields. They are the foundation of capacity reporting. They let us break down work by role, by team, by project type, and by season.
Before Workfront, I would see teams and departments do what I call "bean counting". The basic math of one resource being assigned to one project and then assuming that resource was committed for the entire duration. By adding more Projects to the resource, it erroneously showed that they were at or beyond capacity. Someone would say:
"Joaquin is assigned to this project, so he is at 100 percent capacity."
But when we dig deeper, we see Joaquin is only allocated 12 hours over a 6-week project. He is not blocked. He is not overloaded. He is available.
That is the difference between anecdote and architecture.
With Workfront, we can see seasonal spikes. We can see when contract help is needed, not reactively, but proactively. We can plan for the work we know is coming because the data tells us it is coming.
Let's start building the tool to support reality
One of my favorite moments in any implementation is when a team realizes their process does not work the way they thought it did. They have been operating on assumptions for years, and Workfront quietly reveals the truth.
That is the power of data. It wipes away assumptions. It replaces "I think" with "here is what is actually happening."
The first question I ask leadership is:
What message are you receiving from your teams?
If the message is negative, overload, confusion, bottlenecks, my next question is:
Can your teams show you the positives of the work they do?
If the answer is no, then that is our starting point.
Let's build the tool to support the truth. Let's architect Workfront so it reflects reality. Let's give leadership the visibility they need and give teams the clarity they deserve.
Workfront is not just software. It is a mirror. And when we build it well, it reflects the organization exactly as it is, so we can shape it into what it should be.
Frequently asked questions
When should a request become a project?
Treat the Request Queue as your intake guardrail. An incoming Issue earns project status when it aligns with marketing goals, fits current priorities, and represents a real opportunity rather than noise. Once it is approved, it becomes a Project.
How is real capacity reporting different from just seeing who is assigned?
Counting assignments assumes a person is fully committed to every project they touch, which quickly shows them as over capacity. Real capacity reporting uses estimated hours, durations, and allocations, so someone allocated 12 hours across a 6-week project reads as available, not overloaded. You can then break work down by role, team, project type, and season.
Why build projects from templates instead of starting from scratch?
Templates built from historical data carry SLAs that reflect real delivery timelines, milestones that match your actual process, allocations based on past capacity, and approval steps that mirror how work moves. That makes delivery predictable and turns each project into a clear promise about how the work gets done and how long it should take.
How do I answer leadership when they ask us to show the numbers?
When Issues, Projects, and Tasks are structured intentionally, they produce a top-down narrative: what work is requested, how it is structured and resourced, and how it is executed across teams. That lets you surface stalled approvals, slipping tasks, and the process steps that repeatedly bottleneck, so decisions rest on data instead of anecdote.