Multi-Deliverable Marketing/Creative Campaign Structure

Hi ​@hbeckner - 

We do something pretty similar, just from a different starting point, and we use single asset projects. To get a more holistic view, we added cross-project predecessors from the asset projects into the campaign project. That way, key milestones roll up and show in the campaign project.

We use Fusion to handle this. You can do it manually, but it gets pretty tedious. The nice part is that when tasks are completed or dates shift in the asset projects, everything updates in the campaign project automatically.

The project owners love this because they can get a quick high-level view of what is going on, then jump into the individual asset projects if they want more detail.

You could also achieve something similar using a report view to highlight key milestones across a campaign, depending on how you prefer to set things up.

I have also tried the one big master campaign project route before, but it can get tricky in larger orgs. People usually want to own their own space and not work in one shared project. It really just depends on how your team likes to collaborate.

I cannot give you VicSellers' screenshot, but I can describe the structure I have delivered for a creative team with the same problem, since it landed in a similar place from a different direction and the tradeoffs are worth having side by side.

Same core decision: one project per asset, not one big campaign project with the deliverables as task groups. Multi-deliverable campaigns where the deliverables run on different timelines are exactly where the single-project shape falls apart, because one slipped deliverable drags a schedule the other deliverables do not care about.

Where mine differs is how the asset projects get created. Rather than having the marketing lead submit a separate deliverable request per asset, the intake request itself carries the list of assets, and on approval a scenario creates a project for each asset indicated on the request: named to the team's naming guidelines, task assignments set from business rules over the request's form fields, and the schedule set from that asset type's SLA (or from the requested target date when it is a rush). The team runs about 20 multi-asset requests a week through it and the projects are live within a minute of approval. That collapses your step 3 into the original request, which also fixes the "deliverables don't always get defined upfront" problem, since adding an asset later is a new line on a request rather than a new request to chase.

Two honest costs, because they are the parts people do not budget for:

- You give up the native resolving-object link. Because the projects are not created through the convert action, the request-to-project traceability that convert gives you for free is not there. Decide how you want to report that relationship before you build, not after. This is the single thing I would go back and plan harder.

- The intake form almost always needs a rebuild first. Every field the automation reads has to be required, or you get garbage projects. That work usually exceeds the automation work itself.

On the roll-up question specifically, I would second the report-view option VicSellers raised as the alternative to predecessors. Cross-project predecessors do give you the real dependency picture, but they are a maintenance surface, and they tie schedules together in ways that can surprise you when one asset slips. If what you actually need is visibility rather than dependency, a campaign-level report grouped on the shared campaign reference gets you the same view with far less to maintain. Worth being clear with yourself about which of the two you are solving for, because they pull toward different designs.

I wrote the delivered build up end to end, including the scheduling logic, the rejection criteria, and what broke at launch: https://thousandcuts.ai/guides/creative-request-intake-automation