Rules
Part of Getting marketing workflow management right the first time: the 2027 view
Pull systems versus push schedules in marketing workflow management
Pull systems let receiving teams accept work when capacity exists, while push schedules assign it by date. The difference decides where queues form.
What to take away
Marketing workflow management turns on one choice: who decides when work starts. Pull systems versus push schedules in marketing workflow management answer that question in opposite ways, and the difference decides where queues form. Most teams inherit an answer without noticing.
- A pull system starts work when the receiving team has capacity; a push schedule starts it on a date chosen upstream.
- Push schedules suit fixed deadlines and shared launches. Pull systems suit variable work with different owners per stage.
- Both need a named accepted finish, a visible queue, and a work-in-progress limit, as in Jira Software columns or Azure DevOps board lists.
- Push fails when upstream dates ignore downstream capacity. Pull fails when nobody owns the queue.
- Pick per workflow, not per department, and record which one you picked.
Pull systems
In a pull system, a stage signals when it has room, and the previous stage releases work to fill it. The receiving role accepts, rejects or returns the item. Nothing moves because a date arrived.
Kanban boards, support ticket queues and most agency intake desks run this way. The unit of control is capacity, not calendar. A designer with two open slots pulls two briefs. Trello list card limits, Jira Software column WIP limits and Azure DevOps board WIP limits all cap how much work sits in one stage.
The method comes from Toyota's factory floor in the 1950s, where a signboard, or kanban, told an upstream station to send more parts. Taiichi Ohno modeled it on a supermarket that restocks only what shoppers take.
Pull needs three things. A visible queue of eligible work. A stated limit on what is in progress. A receiving role with authority to say no. Remove any one and the queue becomes a dumping ground.
Little's Law from queueing theory links the numbers: average lead time equals work in progress divided by throughput. Halve the work in progress at a steady finish rate, and items wait about half as long.
Jira Software sets a minimum and a maximum per board column and flags a column that breaks the maximum. Trello needs a Power-Up or a Butler rule to show the same limit. Businessmap, formerly Kanbanize, ships work-in-progress limits and flow metrics as first-class settings.
Push schedules
A push schedule assigns work to a person or team on a date, decided upstream. The campaign calendar is the classic case: creative is due the 14th because launch is the 21st, not because creative has room.
Timeline and calendar views in Asana, Monday.com and Smartsheet put the date first. That is the push shape in software: a slot exists, so work is placed in it. Smartsheet adds dependency links, so moving one date shifts every date after it.
Linear runs on cycles, time-boxed periods of about two weeks, and unfinished issues roll into the next cycle. Microsoft Project carries the same shape across longer dependency chains.
Push is the right shape for fixed dates. Product launches, seasonal retail, event deadlines and regulatory filings do not move because a team is busy. Push also suits work with one owner from start to finish, where no handoff needs signaling.
Push fails predictably. The upstream date is set from the launch date backwards, with no reference to downstream capacity. When the date arrives, the work lands regardless, and the receiving team absorbs the overrun silently.
Pull versus push, and where each one belongs
The two shapes differ on five things worth stating out loud.
Pull versus push
Pull system
- Who sets the start
- The receiving stage, when capacity frees up
- Unit of control
- Capacity, held by a work-in-progress limit
- Where the queue sits
- In front of the receiving stage, visible
- Best fit
- Variable volume, different owner per stage
- Typical failure
- Nobody owns the queue
- Tool example
- Jira Software or Azure DevOps columns with WIP limits
- Typical software cost
- Per seat, typically $7 to $30 per user per month on annual plans, limits included
Push schedule
- Who sets the start
- An upstream planner, by date
- Unit of control
- The calendar date
- Where the queue sits
- Behind the date, often invisible
- Best fit
- Fixed deadline, one owner end to end
- Typical failure
- The upstream date ignores capacity
- Tool example
- Asana Timeline, Smartsheet dependencies, Linear cycles
- Typical software cost
- Timeline, Gantt and dependency features usually sit on a mid or business tier of the same tools
The same test applied to common marketing situations:
Where each one belongs
| Situation | Better fit | Why |
|---|---|---|
| Fixed public launch date | Push | The date is external and cannot move; an Asana Timeline or Smartsheet sheet holds it |
| Variable creative volume | Pull | Capacity varies week to week |
| Single owner, whole task | Push | No handoff to signal |
| Multi-stage with different teams | Pull | Each stage knows its own room |
| Regulated filing deadline | Push | The date is set by someone else |
| Ongoing maintenance work | Pull | It competes with project work for the same people |
| Agency retainer intake | Pull | Trello or Jira Software columns cap how many briefs one team holds |
| Two-week editorial cycle | Push the dates, pull the load | Linear cycles set the dates; Jira Software columns cap the work inside them |
Mixed stacks are normal. A launch campaign can push the deadline to the team while the team pulls individual assets inside it.
Make either one visible
Both systems need the same record: what is active, what is waiting, what is blocked, and who owns the next move. Status should update from the underlying event where practical, with human correction and an audit history kept.
A tidy board that omits side-channel requests is worse than no board. The work still exists; it has just left the system you are managing from.
Set work-in-progress limits from observed capability, and hold back capacity for maintenance, recurring obligations, leave and incidents.
When the limit is reached, finish or unblock rather than raising it. A limit raised twice in a month is usually hiding a priority or staffing problem, not a capacity one.
Jira Software's Control Chart plots cycle time and lead time per issue, so the limit becomes a number you can defend. Azure DevOps analytics views and Businessmap flow metrics do the same.
Handoffs and quality
Whichever system you run, define the payload, version, evidence, owner and expected response for each handoff. Define rejection reasons, the return path and escalation. Teams that write these down keep a marketing workflow management checklist covering intake, priority and evidence.
Checks Near Creation
- Brief completeness before commitment
- Evidence before claims review
- Right version before approval
- Audience permission before activation
- Rollback before release
Place checks near creation rather than at a final gate. Confirm brief completeness before commitment, evidence before claims review, the right version before approval, audience permission before activation, and rollback before release. A single large gate at the end finds basic defects late, when they cost the most to fix.
The UK Government's design principles argue for starting with user needs and doing less; the service standard expects iterative delivery informed by observation and data. Applied here, that means changing one workflow rule at a time and watching what happens.
Automate with a way back
For each automated rule, record these items:
- trigger
- condition
- action
- permission
- owner
- exception
- alert
- retry
- override
- audit entry
Test duplicate inputs, missing inputs, absent users, integration outages and items already in flight.
Measure whether the work reached a correct outcome, not whether the automation ran. A rule that fires on time and produces the wrong asset has failed.
Keep a manual recovery route until the new path has survived ordinary weeks and a failure. Review flow and system design separately. Track lead time and item age as distributions, and pair them with acceptance, rework, defects and operator effort.
Zapier, Make and Power Automate each keep a run history per task, which supplies the audit entry above. Entry plans for these tools typically run from a free tier to about $30 per month for a small team, billed by task volume.
The NIST Privacy Framework offers a voluntary process for assigning privacy risk owners; it is not legal clearance. The CISA logging guidance explains how event records support later review, which is not the same as validating a metric.
Common questions
What is the difference between a pull system and a push schedule?
A push schedule names a start date in advance, upstream of the work. A pull system names the start when the receiving stage has room. The first fixes timing, the second fixes flow.
Should every marketing workflow use Kanban?
No. Use whichever method makes work, ownership, capacity, evidence and exceptions clear enough to manage. Jira Software, Trello and Azure DevOps boards are pull implementations, not the only ones.
Can a team run pull and push at the same time?
Yes, and most do. Push the fixed external deadline to the team, then let the team pull individual assets inside that window. An Asana Timeline date can sit above a Jira Software board with column limits. Record which parts are which.
What should a team change first?
Pick the highest-consequence constraint visible in real work. Change one policy or boundary, then compare flow alongside quality and outcome evidence. More questions are answered in common marketing workflow management questions, and the operating detail sits in how to manage marketing workflow management.
