If you’ve ever tried integrating an external system or website with Jira Service Management (JSM), you’ve probably hit one or more roadblocks, especially when it comes to creating requests on behalf of end users without using the default Jira Service Management portal.
The good news? You don’t need to hand over admin access or build a fragile, permission-heavy API integration. There’s a smarter way, and it’s already built into Jira: Automation + Webhooks.
Let me walk you through a real-world case, how I tackled it, and how you can replicate it.
Your company already uses JSM as an IT Service Desk to handle internal workflows like incident reporting, service requests, and change approvals.
It works well, especially via the standard customer portal, where employees or internal users can log in, choose request types, and track their tickets.
But now there’s a new need, coming from outside IT.
The marketing team wants to collect complaints and suggestions directly from the public website, using a custom-designed form that blends with the brand’s style. No redirects. No JSM interface. Just a native-looking form built into your company site.
The website is managed by an external supplier who has no access to your Jira instance.
Despite that, the supplier needs to:
In short: you want your supplier to push structured data into your JSM queue without exposing internal systems or admin permissions.
Option 1: Issue Collector
The Issue Collector is meant to embed a form on a website, but unfortunately, it doesn’t support Jira Service Management (JSM) projects.
After several attempts, it became clear that this feature does not support request types, customer creation, or JSM-specific flows. It fails silently, or returns cryptic errors.
Option 2: REST API
The REST API is a solid plan. With it, you can:
BUT, to create a customer, the API caller must have Jira Administrator Global permission!
To run POST /rest/servicedeskapi/customer
, your integration must act as a global admin.
And that’s a deal-breaker if you’re delegating this to an external supplier or third-party service.
Here’s the winning pattern we used instead – built entirely with JSM Automation.
We exposed a webhook that the supplier could call from their frontend. The webhook triggers an automation rule that:
What’s a Webhook?
A webhook is an HTTP endpoint (URL) exposed by JSM Automation that can receive data from external systems (like your custom form). It’s asynchronous, secure (via URL Token + Secret), and doesn’t require any JSM credentials.
When triggered, the webhook activates an Automation rule in JSM that processes the incoming data. You control everything through Jira’s no-code Automation engine.
Example Payload Sent to Webhook
{
"projectKey": "COMPLAINTS",
"summary": "Feedback on recent service experience",
"description": "I booked a home installation service for May 15, but the technician never showed up. No call, no email. I’d like to understand what happened and reschedule as soon as possible.",
"requestType": "Complaint",
"reporter": {
"email": joe.doe@example.com",
"displayName": "Joe Doe"
},
"customFields": {
"complaint_category": "Home Installation",
"scheduled_date": "2025-05-15",
"mobile_phone": "33312345332"
}
}
Automation Rule in Jira Service Management
The rule consists of these key steps:
"requestType"
field is "Complaint"
; otherwise, it stopsAdd service project customer"
Create work item with request type
webhookData
Raise on behalf of
using “Customer created by this rule”No global permissions. No API tokens. No admin handover. Just a webhook and a rule.
Since JSM webhooks always return 200 OK, it’s essential to design your own security layer.
Reverse Proxy or API Gateway
Don’t expose the JSM webhook URL directly.
Instead, route external requests through a reverse proxy (like NGINX) or an API Gateway. From there, you can:
Only after a request passes all checks should your proxy forward the call to the real JSM webhook URL.
Optional Callback Verification
For high-sensitivity use cases, send a POST back to the supplier’s system for confirmation (e.g., “did you really send this?”) before proceeding.
This adds another layer of trust and allows for dispute handling or duplicate detection.
With this approach, you’ve built a smart and secure bridge between your external website and JSM, without compromising control or maintainability.
You’ve enabled an external system to submit structured requests, ensured they’re properly attributed to real users, and done it all without exposing admin privileges requested APIs.
No admin rights needed. No external plugins.
Just clean, declarative automation – exactly how JSM intended it.
When your workflows extend beyond your internal teams, the ability to collect structured data from the outside – safely and efficiently – becomes essential.
This approach gives you exactly that:
It’s scalable, maintainable, and easy to monitor.
Whether you’re collecting complaints, processing service feedback, or opening tickets on behalf of users – this is a robust and elegant solution that fits right into your existing JSM environment.
No complexity. Just smart automation that works.
Here are the key resources mentioned throughout this article:
Did you find this article interesting? Does it match your skill set? We’re often presented with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.