How Do You Prove in Jira an SLA Was Broken by Your Supplier, Not You?

[#1]

If you work in procurement or purchasing, you know this situation: when you order materials from a supplier, track the task in Jira, of course, you have an SLA, and then the delivery is late, not because you missed something, but because the supplier didn't ship on time. Now you need to prove that.

Most of the time, the proof sits in your inbox, not in Jira. So when someone asks "why is this SLA broken," you're digging through email or Slack threads instead of pointing to the task.

I used to work as a marketer at a company that manufactures dental units. My role was marketing, but I collaborated with other departments, and that's where I noticed this problem in the purchasing department. Now that I work on AI Apps Builder, I can clearly see a way to solve it.

How purchasing process look like

Imagine a purchasing manager at a manufacturing company. A new part is in development, and it's time to order materials. The manager works with several suppliers at the same time.

Each order goes through a process like this:

1. Fill out a Smart Form to place the order. This creates a Jira task.

2. The task gets an SLA, set based on past experience with the supplier.

3. The manager communicates with the suppliers.

Most of the time, we use email to communicate, not Jira. This creates a problem because the SLA does not consider who caused the delay. If the supplier is late, it still looks like the manager missed the deadline unless they can show proof. Here is another step to help:

4. Link all communication with the supplier to the related task.

I understand this takes extra time. But what if it could happen automatically?

What I build to make this true

I’ve created a custom app for Jira, an Issue panel called Gmail Issue Linker, with a Gmail integration.

Here's what it does:

• You link one or more Gmail addresses to a Jira issue (the supplier, a logistics contact, whoever you're depending on).

• The app automatically pulls emails to and from those addresses and posts them as comments on the issue.

• Syncing runs once a day on a schedule, and you can also hit "Sync now" if you need proof immediately.

No manual copy-pasting. No searching your inbox when someone asks about a delay. The evidence is already sitting in the task.

The prompt I used

To build my Forge app, I used AI Apps Builder for Jira, a security platform that lets you create custom apps, third-party integrations, and AI agents using natural language prompts.

Here is my AI prompt:

Build an Issue Panel app for Jira with Gmail integration.

The panel should let a user link one or more Gmail email addresses to a Jira issue.
Once linked, the app should:

• Fetch all email messages exchanged with those addresses

• Post each new email as a comment on the issue (sender, date, subject, message body)

• Automatically sync once per day via a scheduled trigger, adding any new emails as comments

• Also let the user manually trigger a sync from the panel (a "Sync now" button), for cases when they need up-to-date evidence immediately

• Let the user unlink an email address from the issue at any time

• Avoid adding duplicate comments for emails already synced

The panel should show:

• A field to add/remove linked email addresses

• A list of currently linked addresses

• A status indicator showing when emails were last synced (date/time of last sync)

• A "Sync now" button for on-demand sync

Use Gmail as the third-party integration (OAuth 2.0). Generate the admin page needed to connect the Gmail account.

AI Apps Builder generated the full Jira app: the issue panel, the Gmail OAuth admin page, the scheduled sync, and the resolver logic.

How Gmail Issue Linker looks in practice

My Forge app includes a few Jira modules:

1. An issue panel that I add to my Jira task. It shows a field for an email address, a list of linked addresses, and a "Sync now" button.

2. An admin page for Gmail OAuth connection setup.

I tested my app with a real scenario: a supplier email about a shipment delay, sent to the linked address. After clicking "Sync now," the email appeared as a comment on the task showing the sender, date, subject, and the full message.

Where else might this kind of Forge app help?

The pattern isn't specific to supply chains. It works anywhere a task depends on someone outside your team, and the proof of what happened lives in a chat or an inbox:

• A marketer organizing an event, waiting on a vendor or speaker

• An HR manager tracking communication with a candidate

• A partner manager negotiating with future partners

• Any task with an external deadline you don't fully control

And it's not limited to Gmail. AI Apps Builder also supports Slack as an integration, so if your communication with partners or suppliers happens over Slack instead of email, you can build the same panel with a Slack connector.

If your SLA or deadline depends on someone else, this is a way to keep the receipts where the task lives.

Best-case scenario for the purchasing process

Let's revisit the purchasing manager workflow and examine the recommended one in detail.

1. Fill out a Smart Form to make the order

To place an order, I recommend using a Smart Form. This lets you automatically create a Jira task. The form’s fields, such as supplier name, part number, quantity, and expected delivery date, are matched to the same fields in Jira when the task is created. Since the mapping can be adjusted, the form can also send information to SLA-related fields, like priority or supplier risk tier, which helps decide which SLA applies in the next step.

2. Set up an SLA for your task

Note that Smart Form can help you handle situations when SLA is breached. A second Smart Form is sent automatically. A Jira Automation rule triggers this when the SLA is missed or the status changes to "Delayed." The delay form is shared by email and asks for the new expected delivery date and the reason for the delay, so no one has to remember to update it manually.

The supplier or manager fills out the second Smart Form, and their response is written back into the Jira issue fields. For example, the form can update the expected delivery date, add the reason for the delay, and change the issue status to Delayed.

There are two possible ways to connect this process with SLA Time and Report, depending on how the procurement deadline should be tracked.

In the first scenario, the team can use a negotiated date SLA for the original delivery deadline. The first Smart Form fills in the Expected Delivery Date field when the order is created. Then, in SLA Time and Report, this Jira date field is selected as the target field for the negotiated date SLA. As a result, each order is tracked against its own agreed delivery date, which is useful when every supplier request has a different deadline.

If the second Smart Form later updates the Expected Delivery Date field, the SLA target follows the updated Jira field. This keeps the delivery deadline connected to the latest information submitted through the form, without asking the manager to manually update the SLA configuration.
In the second scenario, the team can use a time-limit based SLA to track the delayed stage separately. When the second Smart Form changes the issue status to Delayed, this status can become the Start condition for a separate delay SLA. The timer then stops when the issue moves to the status that means the delay has been resolved, such as Delivered, Confirmed, or Done.

This delay SLA helps the team measure how long the order stays in the delayed stage. For example, one day of delay may still be acceptable, while seven days may trigger a penalty, escalation, or supplier review. By tracking the delayed stage separately, the team can keep the original missed SLA visible and also measure the real business impact of the delay.

Together, Smart Forms and SLA Time and Report keep the process structured: the form collects and updates the delivery details, while the SLA shows whether the original deadline was met, whether the issue moved into delay, and how long that delayed stage lasted.

3. Communicate with the supplier and automatically link all messages to the task.

Most conversations happen by email or sometimes on Slack, depending on what your supplier or logistics contact prefers. These messages are important if the delivery date changes because they show who said what and when.

To keep this evidence with the task, instead of lost in your mailbox or Slack, you can use AI Apps Builder and build a Jira Issue Panel app that links straight to it. If your team uses email, connect to Gmail. If you use Slack, connect Slack.

You can use my prompt or write your own based on how your team communicates and what you need to track. If you want tips for better results from your own prompts, I explained more in the article: "How to Write Effective AI Prompts: Best Practices and Practical Examples".

What is the AI Apps Builder that I used?

If you haven't heard of AI Apps Builder for Jira before, it's a security building platform that lets you create custom Jira apps and Rovo agents by describing what you need in plain language, no coding required. I'm not a developer, and I built the app in this article myself, with a prompt.

Have a real Jira problem like I described — something that depends on someone outside your team, and no proof when things go wrong? Install AI Apps Builder and try solving it yourself. You don't need to code, and our team is always open to help.