Jira integration inside your workflow, not next to it
A technical team's Jira is not a task list. It is an issue type scheme, a workflow with conditions on transitions, and screens where some fields are required. We wire it into your CRM, service desk, code repository and warehouse so an automation takes the same route a person does. A customer request gets linked to the technical issue, and reports come from a JQL query, not a spreadsheet export.
- 2 to 6 weeksfrom the workshop to a wired-up Jira, depending on how many projects and how many workflows enter the scope
- 14 daysfrom the workshop to the first automation running on your own project in Jira
- 5 to 10 secondswhat BOND needs to answer a question about the state of your issues, without anybody opening a board
The problem
Why does the automation fall over on a status change in Jira?
The contract is signed, somebody creates an epic in Jira by hand and pastes into it the deadline, the contract value and the company name from the CRM. A bug report arrives by email to support, somebody writes it up in their own words as a new issue, and from then on the same case lives in two places. The client asks when the fix ships, and answering that means checking the team board, the release list and the repository history.
On top of that sits the part nobody sees from outside. A team that has worked in Jira for three years has its own issue type scheme, a workflow with a dozen or more statuses, conditions on transitions, validators, and screens with required fields. A person handles all of it on reflex, because the form says what is missing. An automation told to move the issue to testing gets no such prompt.
The technical layer decides the whole schedule here. The Jira Cloud REST API v3 documentation puts it plainly: an issue status cannot be set from outside, you can only execute a transition, and if that transition has a screen, the same call has to carry the fields from that screen. One required field missing and the API refuses. So a Jira integration starts by reading the list of transitions and their fields for a specific issue type, not by writing a scenario.
- The same bug lives as a customer request and as a separate team issue
- A project manager pastes the deadline, the contract value and the company name from the CRM into a new epic
- The client hears that a fix was released only when they ask
- The report for the management board is built from a spreadsheet export, once a month
- An automation trips over a required field nobody told it about
- Nobody knows how many hours a project has eaten until the month closes
Why now
What changed, so you do not have to rebuild your Jira projects?
Jira configuration can be read today instead of guessed. Through the API we pull the issue types available in a project, the list of transitions for a specific issue together with the fields required on the transition screen, and the permission scheme that says what the integration user is allowed to do. Changes arrive as webhook events, so the automation starts a second after somebody drags a card on the board, rather than at the next poll.
The second change is about where the logic lives. Automation built into Jira is the best place for rules about Jira itself: a subtask created on a status change, an owner assigned, a comment added on a transition. Once a rule has to ask the CRM for a contract value, the billing system for a payment status, or append a row to a warehouse, the logic moves to n8n or Make, and Jira stays the place the result is written. The technical layer we describe separately, on the page about API integration.
The third change is dull and the one most often skipped: permissions. Jira hands out access through schemes attached to a project, so the same transition can be open to one role and closed to another. The integration runs as its own user, with permissions narrowed to the projects in scope, not on an admin account because that was quicker on day one. That way the issue history shows what a person changed and what the automation did.
The fourth thing is an AI agent. JQL will answer any question about issues, but somebody has to write it first, and neither your management nor your support team knows the syntax. BOND, our company AI agent, turns a question asked in a plain sentence into a query against Jira and answers in 5 to 10 seconds. Which customer requests have been waiting longer than 5 days is then asked by a person who has never opened the team board.
What changes
What do you get from a Jira that is wired in?
The automation walks the workflow the way a person does
Before every status change the integration asks Jira which transitions are available for that specific issue and which fields the transition screen requires. If a field is missing, it fills it from the source system, or leaves the issue where it is with a comment, instead of going quiet.
Transitions and required fields read through the API before the first write, separately for each issue type
The business case linked to the technical one
A won deal in the CRM creates an epic with the deadline, the contract value and the client name in fields you already have. Closing the epic goes back to the CRM as a project stage change, so the salesperson stops asking the team for a status.
The link works both ways: the issue key stored in the CRM, the deal id stored in Jira
A customer request reaches the team that will fix it
Jira Service Management is a world of its own: the customer writes through the portal or by email, the request lands in a queue with its own request type and an SLA clock. A confirmed bug gets a linked issue in the technical team's project, and closing that issue comes back to the customer as a reply in the same thread.
One customer request, one technical issue, a link between them instead of two descriptions of the same case
A report without building a report
A JQL query is a recipe for a list: issues by project, type, assignee, label, version and time in status. The result goes where somebody reads it, which is Slack on Monday morning, a sheet in Google Sheets, or a table in BigQuery refreshed once a day.
The same JQL query feeds the Slack message and the table in the warehouse, with no manual export
You can see what shipped and when
Issues linked to the code repository and assigned to a version show which fix is already released and which is still waiting. After a release the client gets a message with the list of closed issues, without anybody writing it out.
The release list assembled from the version field in Jira and the linked changes in the repository
Hours from Jira turned into project margin
Logged time goes to the warehouse once a day and sits next to the rate from the CRM and the invoices. A manager sees which project is eating more hours than the budget has left in the same week, not after the month closes.
Time per issue and per sprint in BigQuery, next to the contract value from the CRM
And in your company
What if our Jira looks different?
Four sentences we hear most often about Jira, and what we answer to each of them.
Below them, the systems we wire Jira into most often. If something is missing from the list, there is one question: does it have an API or webhooks.
Our workflow has fourteen statuses and nobody touches it.
And we will not touch it either. The integration reads the workflow as it is, with the conditions and validators on every transition. If the workshop shows that two of your statuses mean the same thing, or that one transition is blocked for everybody except a single person, we say so and leave the decision with you.
Our projects are team-managed, not company-managed.
That is an important difference and we ask about it at the start. In a team-managed project the issue types, workflow and fields are local, so what we build for one project does not carry over to the next on its own. In a company-managed project the schemes are shared, so one change touches every project that uses them. For reporting across the whole company the second model is easier to live with, and we will tell you that.
Jira is for developers, support lives in an inbox.
Then we start by asking how many customer requests come in per month, and whether anybody today can say how many of them have been waiting longer than a week. If the answer is that nobody knows, Jira Service Management as a separate project with a portal and queues, linked to the technical issues, makes sense. If there are a handful of requests a week, we say the inbox is enough.
We want AI that closes issues on its own.
We do not build that, and we say why. An AI agent answers questions about the state of your issues, drafts a comment and proposes a transition, but the close stays with a person, because a closed issue is a statement made to the customer. We close automatically only what has an unambiguous rule, a duplicate matched on its identifier for example.
- Atlassian
- Jira Software, Jira Service Management, Confluence, Bitbucket
- CRM and sales
- HubSpot, Pipedrive, Salesforce, LiveSpace
- Team work
- Slack, Microsoft 365, Google Workspace, Notion, ClickUp, Asana
- Code repository and releases
- Bitbucket, GitHub, GitLab
- Data, reporting and invoices
- BigQuery, Google Sheets, SQL databases, Xero, Fakturownia, Comarch Optima
- Automation layer
- n8n, Make, Zapier, custom API integrations
The Jira configuration every integration has to reckon with
These are the things we read before the first line of a scenario is written. Each of them can stop an automation that looks correct.
| Configuration element | What follows from it for an automation | Where we read it |
|---|---|---|
| Issue type scheme | which types exist in the project and which fields each of them requires | project metadata read through the API |
| Workflow and transitions | a status cannot be set, only a transition can be executed | the list of transitions for a specific issue |
| Transition conditions and validators | a transition can be blocked for the integration user | a trial transition on a test project |
| Transition screen with required fields | one missing field means the write is refused | fields pulled together with the transition list |
| Team-managed or company-managed project | whether the schemes are local or shared across the company | project settings |
| Permission scheme | who may comment, move and close issues | the scheme attached to the project |
| Versions and releases | what went into a release and when to tell the client | the version field plus the changes in the repository |
A first rollout usually takes one project and one workflow. The next ones go in only once the first is running in production.
How we do it
Five steps from pasting by hand to a Jira that is wired in
Each step ends with something you can judge before you decide on the next one.
Workshop
We lay out the route an issue takes: where it comes from, who creates it, which statuses it passes through and where somebody pastes data by hand. Customer requests we take separately, because that is a different process from the technical team's work. We check which projects are team-managed and which are company-managed.
Reading the configuration
Through the API we pull the issue types, the workflow, the transitions together with their required fields, the permission scheme and the list of custom fields. This is the moment the forgotten required fields surface, along with transitions open to one role only.
Integration design
We settle which system owns each field: Jira, the CRM or the billing system. We pick the tool: automation built into Jira for rules that stay inside Jira, n8n or Make for everything that leaves it. We create a separate integration user with permissions narrowed to the projects in scope.
Rollout on a test project
Scenarios run on a copy of your project, on real issues from the last few weeks. We check the cases that break automations: an issue with a required field left empty, a transition blocked by a condition, a duplicate, and an issue somebody closed by hand halfway through.
Production and measurement
We switch over with error monitoring and leave documentation that shows what happens on every event. After 30 and after 90 days we look at the numbers: how many issues are created without a person, how many refusals the API returned, and how many customer requests wait longer than the SLA.
Before and after
How the week changes for a project manager
Before
- Spends the morning creating epics for contracts signed last week
- Hunts for whether a customer request already has an issue with the team
- Builds the report for the board out of a spreadsheet export
- Writes the client a list of fixes in a release, going through issue after issue
After
- The epic exists with the deadline and the contract value the moment the deal closes in the CRM
- A customer request has a linked technical issue and a status anyone can see
- The JQL list is waiting in Slack on Monday morning
- The release note goes out from the list of issues assigned to the version
The first issues created without a person show up on the day you switch over. API refusals and the handling time on customer requests we judge after 30 days.
For the person signing this off
What an operations director gets out of it
The question of where client X's project stands stops requiring a lap of the team, because the answer sits in one place and follows from statuses people set anyway. Instead of trusting a declaration made at the weekly review, you look at how long issues spend in each status.
The second thing weighs more in a conversation with the board. Hours from Jira set against the contract value show which project pays for itself and which one you deliver out of ambition. That is an argument about pricing and about staffing that you do not have today, because the data sits in two systems at once.
- The route an issue takes written down and the same for the whole team, not held by one person
- Customer requests in a queue with an SLA clock, rather than in a private inbox
- The rollout runs on a copy of the project, so production keeps working until testing ends
- Project margin visible in the same week, not after the month closes
What it costs
The workshop has a published price, the integration is quoted after it
The process workshop costs EUR 3,500 net per week. On Jira one to two weeks is usually enough, because the route an issue takes comes with a map of fields and permissions on top. We quote the integration after the workshop, once we know how many projects are in scope, how many workflows have to be handled, and whether Jira Service Management is part of it.
Atlassian licences you pay to Atlassian, and the cost of running the scenarios to the tool vendor, or to nobody if n8n sits on your own infrastructure. No commission from us and no markup on somebody else's invoice.
Process workshop
EUR 3,500 net
per week, on Jira usually one to two
A self-contained piece of work. It ends with the route an issue takes written down, a field map and a plan your own team can execute without us.
- A map of the route an issue takes, from the client and from the team, with the manual pasting marked
- A list of the issue types, transitions and required fields that enter the scope
- A decision on which system owns each field: Jira, the CRM or billing
- A tool recommendation: automation in Jira, n8n, Make or the API
- A list of the required fields and transition conditions that will block an automation
- A note on what is not worth automating in your company, and why
- Most popular
Workshop and Jira integration
Quoted after the workshop
scope follows from the number of projects and workflows
The option most companies choose. A working integration within 2 to 6 weeks of the workshop, tested on a copy of your own project.
- Everything in the workshop
- Scenarios in n8n, Make or through the API, wired to the CRM and the warehouse
- Transitions and required fields handled properly, instead of trying to set a status
- Customer requests from Jira Service Management linked to technical issues
- JQL lists into Slack, Google Sheets or BigQuery
- Documentation and training, so your team can change the rules itself
Jira and an AI agent
Quoted after the workshop
for companies where people outside the team ask about status every day
Everything in the integration plus BOND, the company AI agent that answers questions about issues asked in a plain sentence.
- Everything in the Jira integration
- An AI agent reading from Jira, the CRM and the warehouse, an answer in 5 to 10 seconds
- Alerts on issues breaching the SLA and on projects past their hours budget
- Access for the support team and for management, with no JQL to learn
The workshop ends with a document that stands without us: the route an issue takes, a list of fields and a rollout plan. If it turns out Jira is too big a tool for your team, because there are no releases, no customer requests and no need to record who changed what, we say so at the workshop and show you the simpler road. The matter then ends at the workshop, rather than at an integration you do not need.
Frequently asked questions
What is a Jira integration?
It is Jira wired into the systems where the team's work starts and ends: the CRM, customer service, the code repository, the data warehouse and invoicing. Issues are created from data that already exists somewhere, they move through your workflow with nobody pasting anything by hand, and the changes go back to the source system. People stay with the decisions instead of retyping deadlines and company names.
How long does a Jira integration take?
One to two weeks of workshop and 2 to 6 weeks of rollout, with testing on a copy of your project. The first automation usually runs 14 days after the workshop. The timing depends mostly on how many workflows are involved and whether customer requests are in scope, because Jira Service Management is a separate process with its own request types and SLA clocks.
Why can an automation not simply change the status of an issue?
Because Jira does not allow a status to be set from outside. A status changes only through a transition, and a transition can carry a condition, a validator and a screen with required fields. An automation that does not supply a required field gets a refusal, and that is the most common reason scenarios work in a demo and stall in production. So before every change we ask Jira which transitions are available and what fields they need.
What is the difference between a team-managed and a company-managed project?
In a team-managed project the configuration belongs to the team and is local: issue types, workflow and fields are not shared with other projects. In a company-managed project the same schemes serve many projects, so one change touches all of them. For an integration the difference is practical: in the first model every project has to be read separately, in the second one field map covers the whole company.
Do you integrate Jira Service Management as well?
Yes, and we treat it as a world of its own, because that is what it is. The customer writes through the portal or by email, the request drops into a queue with a request type and an SLA clock, and the reply comes back in the same thread. A confirmed bug gets a linked issue in the technical team's project, so one case does not turn into two independent descriptions.
How do we get a report out of Jira without building a dashboard?
With a JQL query. It filters issues by project, type, assignee, label, version and time in status, and we send the result where somebody will read it: a Slack message on Monday morning, a sheet in Google Sheets, a table in BigQuery refreshed once a day. The advantage of JQL is that the query can be read and corrected, while a dashboard chart has to be rebuilt from scratch.
Will the integration show what went into a release?
Yes, as long as issues are assigned to a version and linked to the code repository. Then the release list comes from the version field and the linked changes, and the message to the client goes out from that list instead of being written by hand. It is also the only sensible way to answer a client asking whether their fix is already in production or still waiting.
When does a company not need Jira?
When the team is a few people, there are no releases and no environments, customer requests run to a handful a week, and nobody needs a record of who changed a status and when. Jira then adds the cost of configuration without the benefit, and a lighter task tool is enough. We say that at the workshop rather than quoting an integration for a tool not worth keeping in your company.
Let us find where the time goes in your Jira
The free consultation takes 30 minutes. You tell us how many projects you run, where issues come from and who pastes data between Jira and the CRM today. We show you what can be wired up right away and what needs the fields and permissions sorted out first. You do not have to share any systems at this stage.
We run at most two rollouts at a time, so that someone is actually sitting on each of them.
Book a free consultationPS. If somebody at your company created an issue by hand this week with data that was already in the CRM, that is exactly this problem. An integration that knows your transitions and your required fields does it itself, and leaves no second version of the same case. That is where the workshop starts.