How to manage deliverables(like documents) in jira issue.

[Kristy]

I have a question.

When I finished each task, such as 'output an PPT' or 'output user manual', I should upload the deliverables to related jira issue. The thing is in my team, some people like to upload to jira Attachment area, some like to link confluence page, some just send the link to Comment area. 

In addition, current way is messy, but we hope to archive all the deliverables and name the version.

Do you have any good practice for manage deliverables or if any APP can be considered?

[Dorota Popowska - Vilisoft · Accepted solution]

Hi @Kristy 

I would also recommend keeping the deliverables in an agreed-upon company repository, such as SharePoint, OneDrive, Google Drive, or another document management system, and using Jira mainly to reference them.

The team should define:

• one authoritative location, or a clearly defined set of locations, for deliverables;

• a consistent folder structure, for example, by project, customer, or workstream;

• a file naming convention;

• one consistent place in the Jira work item to add the deliverable link.

A simple naming convention could be:

YYYYMMDD_JIRA-123_Deliverable-name_v1.0.ext

For example:

20260716_PROJ-245_User-manual_v1.2.pdf

At a minimum, I would include the document name, version number, and creation or publication date. Adding the Jira work item key makes it much easier to identify the context of the file. Placing the date at the beginning in the YYYYMMDD format also ensures that files are sorted chronologically.

Links to deliverables should be added in a dedicated Jira field or in a predefined section of the work item description, rather than being scattered across comments. This rule can also become part of the team’s Definition of Done.

I would avoid storing separate copies of the same deliverable both as a Jira attachment and in the document repository, as it quickly becomes unclear which version is current. Jira attachments can still be useful for small, static evidence files, such as screenshots, logs, or final exports.

[zoltanersek _outpostlabs_dev_]

I'd recommend agreeing on a single source of truth for deliverables, then using Jira only to reference it.

For example:

• Confluence for living documents (requirements, user guides, runbooks, etc.).
• SharePoint/OneDrive/Google Drive for Office files like PowerPoint or Excel that need collaboration and version history.
• Jira attachments only for evidence or small, immutable files (screenshots, logs, exported reports).

Then make it part of your team's Definition of Done that every work item contains a link to the final deliverable in a consistent field (or at least in a dedicated section of the description), rather than scattering links across comments and attachments.

[Arkadiusz Wroblewski]

Hello @Kristy 

From what you're saying, I think the bigger problem is that your team doesn´t really have a fixed process but more "Freestyle"

The main improvement would be to define one authoritative location for deliverables. Comments, Jira attachments and Confluence links should not all be treated as equal sources, because users will eventually be unsure which copy is current.

Best,

Arek🤠

[Dave Mathijs]

Hi @Kristy That's doesn't seem to be a tool issue, but rather a process/people issue. 😉

Another 'app' (tool) will not solve this problem.

I see some questions here:

1. How many different output formats do you have? (Powerpoint, PDF, Confluence page, Word document, ...)
2. Is there a process on which output format to use for which deliverable?
3. Can you use Smart Links or do you have a Sharepoint Connector to 'reference' the output instead of uploading it as an attachment to Jira?
4. 'Files' are attachments, Confluence pages are links, they're not the same.
5. Version management is normally done on file or page level