Jira Service Management
Where engineering and service management share a platform, an assistant can answer about requests without sending non-technical people into a tool built for engineers.
Where engineering and service management share a platform, an assistant can answer about requests without sending non-technical people into a tool built for engineers.
What Jira Service Management holds, and why that matters here
Jira Service Management sits alongside Jira software projects, which makes it common in organisations where engineering owns service delivery. Its strength is the link between a request and the work that resolves it; its weakness is that the interface assumes familiarity most requesters do not have.
An assistant closes that gap. Employees and customers ask in words; the assistant answers from the request record without anyone learning a query language or navigating a board.
- Requests — status, queue and assignee.
- Request types — the catalogue of what can be asked for.
- Linked issues — the engineering work behind a request.
- SLAs — targets and how a request is tracking against them.
- Knowledge — linked Confluence content where it is used.
Questions Elbi can answer from Jira Service Management
Where is my request?
Status and queue position without opening Jira.
What is it waiting on?
Linked work and blockers, which is the question requesters most want answered.
How do I request this?
The right request type and what it needs.
When will it be done?
SLA position and any linked delivery estimate.
Raise a request
Correctly typed, with the details gathered conversationally.
Is this already reported?
Matching against open requests to prevent duplicates.
How Elbi works with Jira Service Management
- A dedicated account, not someone's loginThe connection runs as an Atlassian account created for the purpose and added only to the service projects in scope. On Cloud it authenticates with an API token or an OAuth app your administrator approves; on Data Center, with a personal access token. Your team issues that secret and can revoke it.
- Customers and agents are told apartJira Service Management separates customers, who use the portal, from agents, who work the queues. Elbi matches the signed-in person to their Atlassian account, so a customer hears only about requests they raised, joined as a participant, or share through their organisation.
- A request key helps but is not neededPeople can quote the key from their confirmation email or simply describe the request: "my VPN access from last week". Elbi reads its status, request type, assignee and latest reply to the customer, and leaves internal notes alone.
- Linked engineering work, translatedWhere a request is linked to an issue in a software project, Elbi can say the fix is being worked on or waiting for a release, without exposing the development issue, its comments or the team's board to the requester.
- SLA clocks as datesAn SLA such as time to resolution is shown in Jira as a countdown. Elbi turns it into something a requester can plan around, such as "the team aims to resolve this by tomorrow afternoon", in the language they asked in.
- Raising a request, where you allow itIf enabled, Elbi raises the request on the customer's behalf under the right request type, fills its required fields from the conversation and attaches the transcript, so the agent starts with the context. Transitions, approvals and resolution stay with the team.
Jira permissions, request visibility and what stays yours
| Direction of access | Read on the service projects agreed at deployment. Raising a request and posting a reply the customer can see are separate write permissions, each switched on deliberately and each able to wait for a person's confirmation. |
|---|---|
| Who can see what | Project roles, permission schemes and any issue security levels on the dedicated account set the ceiling. Each answer is then narrowed to what the asker could see in the portal or in their own queue. |
| Credentials | API tokens, OAuth apps and personal access tokens are all issued from your side of Atlassian. Revoking one, or deactivating the account, cuts the connection without our involvement. |
| Where data goes | Requests stay in Jira Service Management and are read when a question needs them, not copied. The conversation's message content is destroyed within 24 hours, usually as soon as it ends, and no external AI service sees it. |
| Audit | Elbi logs each lookup with the question, the result, the agent and the conversation. Because it works through its own account, any comment or request it creates is attributable to that account in Jira rather than to a person. |
| If it is unavailable | If your Atlassian site or Data Center cannot be reached, Elbi says so and offers a person. It does not guess at a status or an SLA it was unable to read. |
What this replaces
The distinctive value here is explaining engineering status to non-engineers. A request linked to a development issue has a real answer about why it is waiting, and that answer is usually buried in a tool the requester cannot read.
The second is correct request typing. As with any service catalogue, mis-typed requests route badly and resolve slowly, and the cause is that requesters do not know the taxonomy.
The third is duplicate prevention. Matching a new report against existing requests removes a meaningful share of triage work.
How different teams use a Jira Service Management connection
Technology organisations
Service requests linked to engineering work.
Internal IT
Employee requests without Jira familiarity.
DevOps teams
Incident and change status.
Product support
Customer requests linked to the backlog.
Getting value from Jira Service Management
Start with the portal rather than the queues. The requests customers chase most, whether access, equipment or a fault they reported, show up as comments asking for news, and a JQL filter on recently commented open requests shows where that chasing concentrates.
The first flows are usually the same three. Status of the asker's own requests. The "what is it waiting on" explanation for requests linked to engineering work, which agents find hardest to answer quickly. And request-type selection, so a new request lands in the right queue with the fields the team needs. Knowledge from linked Confluence spaces comes next, offered before a request is raised at all.
Leave transitions, approvals and resolution in Jira. They start and stop SLA clocks and belong to agents; the assistant's job is to spare those agents the status questions, not to move work across their board.
What connecting Jira Service Management involves
- Rank the questions from your requestsRequest types by volume, and the comments that are really "any update?", give a ranked list of what people ask. That list decides the scope, not the list of projects Jira can expose.
- Agree projects, request types and fieldsYour Jira owner signs off which service projects and fields Elbi may read, and which stay out entirely, such as projects handling HR or security matters. That sign-off is the document an auditor will ask for.
- Create the account and its tokenYour administrator creates the dedicated account, gives it the smallest project role that works, and issues the API token, OAuth app or personal access token. The secret stays with your team.
- Map workflows and request typesCustom workflows, status names, request type forms, SLA goals and customer organisations are mapped during deployment, along with the Arabic wording for each status a requester might see.
- Rehearse the awkward casesA request shared through an organisation, a linked issue in a project the customer cannot see, a request type with mandatory fields, the site unreachable during maintenance. Each is tried before launch.
- Launch on status, then widenGo live on request status first, read a month of real questions, then add request creation. Every step stays easy to reverse.
Personal data in Jira Service Management requests
Requests hold whatever customers type or upload: names, mobile numbers, screenshots that show more than intended. Under the Saudi Personal Data Protection Law, reading them to answer a question is processing, and it needs a purpose you can state and a scope you can show.
Keep attachments outside what Elbi reads unless a flow genuinely needs them, and leave projects holding HR or security matters out of the first scope. Remember too that sharing a request with a customer organisation makes it visible to that organisation's members; if that sharing is on in Jira, it applies through Elbi as well. The conversation in which a request is discussed is destroyed within 24 hours, and no external AI service sees it.
What organisations typically see
Atlassian's own options, and where Elbi fits
Atlassian builds its own AI features into Jira Service Management, including a virtual service agent that answers requesters from knowledge held in Atlassian. For a team whose service desk and knowledge base both live there, that is worth evaluating first.
Elbi is the alternative when requesters should be answered from Jira Service Management alongside systems outside Atlassian, such as HR, finance or a customer portal, in Arabic and English, under one set of governance and one audit trail. Jira stays the system of record for the work.
The pitfalls are the same whichever you choose. Exposing engineering issues and their comments to requesters simply because a link exists. Letting an assistant transition requests and quietly pause or stop SLA clocks. And answering from a remembered status when Jira could not be reached.
Common questions
Where the request is linked to engineering work, yes — which is usually what the requester actually wants to know.
Where you enable it, correctly typed.
Yes. Answers are bounded by what the person asking may see.
No. Elbi connects through an account and token that your Jira administrator creates, limited to the service projects you choose. Revoking the token or deactivating the account ends the connection without going through us.
Most sites are. Custom workflows and statuses, request type forms, custom fields and SLA goals are mapped during deployment rather than assumed from a template.
It can raise requests and post a customer-visible reply where you enable each action, optionally after a person confirms. Transitions, approvals and resolution are better left to agents, because they drive the SLA clocks.
Connect Elbi to Jira Service Management
Request status and linked-work answers from your own service projects, in Arabic and English.