How do you organize Jira tasks when one packaging project has multiple revisions?

Question

I’m working on packaging-related projects at Silver Edge Packaging, where a single project can sometimes involve several rounds of artwork, content, review, and production changes.

For example, a custom cereal boxes project might start with an initial design, then go through content changes, artwork revisions, approval, and final production.

I’m trying to figure out the cleanest way to manage this type of work in Jira.

* Do you create separate issues for each revision?
* Do you use subtasks for design, content, review, and approval?
* How do you track which version is currently approved?
* Is it better to keep everything under one parent issue?
* How do you handle tasks that are waiting for client or internal approval?
* Do you use custom fields to track revision numbers or production status?

I’d be interested in how other teams structure Jira when a project has several related stages and revisions without making the issue tracker too complicated.

Anwesha Pan · Answer

Hi @Sam Miller👋🏻

First of all, welcome to community! ✨

To answer to your question, you could try the following options:

1. Issue Hierarchy & Structure: One Parent Issue per Packaging SKU / Project

* Parent Issue (Task or custom type Packaging Order): Represents the entire packaging project from kickoff to delivery (e.g., “Custom Cereal Box – Brand X (Q4 Redesign)”).
* Do NOT create a separate parent issue for each revision: Creating new top-level tickets for every revision fractures your comment history, attachments, and delivery timelines.
* Subtasks for Major Workstreams / Handoffs: Use subtasks for distinct parallel efforts or major checkpoints:* Subtask 1: Copy & Nutrition Fact Verification
* Subtask 2: Die-line & Structural Design
* Subtask 3: Final Artwork & Pre-press Check
* Subtask 4: Client Approval & Sign-off
* Subtask 5: Production & Print Run

2. Workflow with Built-in Revision & Approval Loops

Model the revision cycle directly in the workflow statuses rather than opening new tickets:

[ Backlog / Draft ] 

       │

       ▼

[ Design & Artwork ] ◄──────────┐

       │                        │ (Changes Requested)

       ▼                        │

[ Under Internal Review ]       │

       │                        │

       ▼                        │

[ Awaiting Client Approval ] ───┘

       │ (Approved)

       ▼

[ Pre-Press & Production ] 

       │

       ▼

[ Complete / Delivered ]

3. Tracking Approved Versions & Revision Numbers

* Number Custom Field (Artwork Revision): A simple integer field (e.g., v1, v2, v3). Configure a Jira Automation rule to increment this field by +1 every time an issue transitions from Awaiting Approval back to Design & Artwork.
* URL / Attachment Custom Field (Approved Asset Link): A dedicated text/URL field linking to the exact signed-off Figma file, Adobe Cloud file, or shared DAM/drive asset.
* Jira Release / Fix Version (Optional): If packaging runs are tied to print batches or seasonal releases, use standard Jira Versions to track when batches hit production.

4. Handling Client & Internal Approval Blocks

* Dedicated "Waiting" Statuses: Keep statuses like Awaiting Client Review clearly visible on your Kanban/Scrum board.
* Flagging & SLAs: Use Jira's built-in "Flag" feature (Right-click card → Add Flag) to highlight cards blocked by external client feedback.
* Approval Gates: In Jira Service Management or Jira Work Management, enable native Approval Steps where designated approvers simply click Approve or Decline directly on the issue.

I hope this helps. 🙂

Thanks,

Anwesha

Matthew Sinclair · Answer

Off hand? Id keep the overall subject in an Epic.

Then break it down by ticket - such as Story for each "major" version.

Adding custom fields is hazardous for something like this.

Use of components might be a better option maybe? Labels could get messy.

In terms of change management/approvals - JSM shines here - but if you are in Jira - that's more manual than most would like. (Or even Confluence's Approval system that's rolling out)

This is a discussion you'll want to hold with the folks who do the work - their pain points/frustrations are going to show here.

At the same time however as a Jira-Admin/Org Admin you'll want to maintain some semblance of control - resist the urge to add workflow statuses/fields for the sake of tracking things you don't need to query. I've seen situations where issue types are created as well - and that gets very chaotic very quickly.

Becomes more of a Process question and less a tracking one.

Jira also has a Release system that might be helpful here - although not sure this applies to what your doing?

Just my 2 cents to offer.