Project management

Jira knows exactly what happened to an issue. Everyone outside Jira finds out later, or not at all

A bug gets fixed and the issue moves through its workflow to "Done". The customer who reported it hears nothing, because the only thing that happened is a transition inside Jira, and nobody built a step that tells them. A project manager wants the number of open issues on a client dashboard, and gets it by asking a developer to look and reply in Slack.

Jira is precise about what happened to an issue and exactly when. That precision does not travel anywhere on its own — a transition, a custom field or a comment stays inside Jira until something is built to carry it out.

  • Cloud and Data Center need different routes
  • Custom field IDs mapped once, used everywhere
  • From €1,700 plus service fees
The tool

What Jira is, and why Cloud and Data Center are two different integrations

Jira is an issue tracker built around projects, issue types (bug, task, story, epic), workflows and transitions between statuses. Custom fields are how a team adds anything the default issue screen lacks — a client reference, a severity, a specific due date — and each one gets an internal ID like customfield_10047 with no relation to its visible label, often differing between projects in the same instance.

Jira Cloud is Atlassian-hosted, reachable over the internet with a documented REST API and OAuth. Jira Data Center runs on your own or a hosting partner's servers, usually behind a firewall, with its own REST API that overlaps with Cloud's but is not identical to it. Which one you run decides the integration route before anything else does — a connector built for Cloud does not simply point at a Data Center URL and work.

What goes wrong

Three things that go wrong around a Jira instance

Jira's own users rarely feel these — the workflow inside Jira is usually fine. It is everyone standing just outside it who pays for the gap.

A client comment lands in Jira, and the customer never sees the reply

Support runs through a portal or a form that creates a Jira issue, a developer answers by commenting on it, and the comment stays inside Jira because nothing carries it back out. The customer refreshes a page that never updates, then emails asking whether anyone is looking — while somebody has been looking since Tuesday.

What you see instead

A comment added on a linked issue is posted back to the customer's portal or emailed to them directly, with internal-only comments filtered out so nothing meant for the team leaks outward.

The dashboard everyone wants is a person, refreshing

A client or a manager wants to see open issues, story points remaining or the sprint burndown without logging into Jira. In practice that becomes a weekly screenshot, or a person copying numbers into a spreadsheet, which is stale before it is sent and wrong the moment a status changes an hour later.

What you see instead

The numbers read live from Jira through the API onto a dashboard or a portal page, so what a client sees is what Jira actually says at that moment, not what it said last Tuesday.

A field ID that meant one thing in one project means something else in another

customfield_10047 is "Client Reference" in one project and "Severity" in another, because fields get created per project and Jira reuses IDs in ways that are not obvious from the label. An integration built by reading one project's fields and assuming the rest match reads or writes the wrong thing the moment a second project is added.

What you see instead

We map field IDs per project explicitly and verify the mapping before the connection goes live on a new project, instead of assuming it carries over.

The bill for doing it by hand

What manual reporting and relaying around Jira costs

The clearest number is the status update. If a project lead spends fifteen minutes a day gathering issue counts and sprint status for a client or manager, that is over five hours a month turning Jira's own data into a sentence Jira could have said itself.

The support-comment gap is harder to number but often costs more: a customer who has to email asking whether anyone read their ticket has decided the support channel does not work, and that decision shows up nowhere as a line item — it shows up as a phone call instead of a ticket next time.

What we build

We build the thing on the other end too

With Jira the connection nearly always sits inside something bigger — a client portal, a support form on the website, a dashboard — because raw Jira issues are not something you would show a customer directly.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can be connected between Jira and the rest of your stack

Everything below works on both Cloud and Data Center, but not through the same route — we confirm which edition you run before scoping any of it.

  • Website or portal forms as new issues

    A support form or a bug report on the website creates an issue in the right project with the issue type, priority and custom fields already set, instead of an email someone has to turn into a ticket by hand.

  • Transitions and comments pushed to the reporter

    An issue moving to a chosen status, or a public comment being added, reaches the person who reported it by email or in a portal — with internal-only comments filtered out.

  • Issue counts and sprint status onto a dashboard

    Open issues, story points remaining or a sprint burndown, read live from the API and shown on a client dashboard or an internal one, instead of a weekly screenshot.

  • Issues kept level with a CRM or a project tool

    An issue mirrored as a task in HubSpot, Productive or another project tool, matched on the issue key, for teams who need Jira's workflow on the development side and something simpler for everyone else.

  • Time logged against an issue into invoicing

    Worklogs on an issue totalled per client or per epic and passed to an accounting package as billable hours, so an invoice reflects what Jira actually recorded rather than a separate timesheet.

A first Jira project is usually the form-in and status-out pair; the CRM mirror and the invoicing row tend to follow once those two have proven themselves.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

More about system integrations at JKC

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

For Jira specifically: Data Center adds a genuine network conversation on top of the usual scoping, the same way an on-premise ERP does — we settle the route your IT will accept before quoting, not after.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Frequently asked questions about connecting Jira

Both, but not through the same door. Cloud is reached over the internet with OAuth and Atlassian's own REST API; Data Center usually sits behind a firewall, so a connection needs the same kind of network conversation an on-premise ERP does — a VPN, a reverse proxy, or a service inside your network that pushes data out. We ask which one you run before quoting, because the answer changes the integration route rather than only its price.

Often next to this one

Tools that often sit next to this one

Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.

See all integrations

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.

Do the free Growth Scan