Requests raised on behalf of customer not visible in their requests?

[Kaisha Billings]

Did I read correctly that you cannot raise a request on behalf of a customer and have it show under their requests? Documentation says you have to use one of the external channels to see it under My Requests. Does anyone have a good workflow you've frankenstein-ed together for this very basic task?

[C_Faysal _CFcon_ · Accepted solution]

Hi @Kaisha Billings 

Yeah, you read that right — it's a frustrating limitation that's been around forever. Requests created from the agent view won't show up under the customer's My Requests, even if they're set as the reporter.

If you have ScriptRunner installed, I'd try a different angle: instead of creating the ticket through the normal issue API, use the JSM Service Desk REST endpoint directly:

POST /rest/servicedeskapi/request

My Requests only shows tickets created through this specific endpoint, not through regular issue creation. It also accepts a raiseOnBehalfOf parameter with the customer's account ID, which should create the request properly from their perspective. With ScriptRunner you could wrap that in a Script Listener or a small custom REST endpoint and trigger it from the agent view.

Haven't tested this exact scenario myself so I can't promise it works, but given that the root cause seems to be which endpoint is used to create the ticket, it feels like the right place to start. Worth a quick test in a dev environment if you get the chance.

[C_Faysal _CFcon_]

Ok i ran a quick test for you without Scriptrunner addon. plain API calls

Here's a working step-by-step example using the JSM REST API to create requests on behalf of a customer:

Prerequisites:
- You need an Atlassian API token (create one at https://id.atlassian.com/manage-profile/security/api-tokens)
- Your account must be a Service Desk Agent

---
Step 1. Find your Service Desk ID

curl -s -u your-email@example.com:YOUR_API_TOKEN \
"https://your-instance.atlassian.net/rest/servicedeskapi/servicedesk" \
-H "Accept: application/json"

Note the id of your service desk from the response.

Step 2. Find available Request Types

curl -s -u your-email@example.com:YOUR_API_TOKEN \
"https://your-instance.atlassian.net/rest/servicedeskapi/servicedesk/{serviceDeskId}/requesttype" \
-H "Accept: application/json"

Note the id of the request type you want to use.

Step 3. Create the customer (if they don't exist yet)

curl -s -u your-email@example.com:YOUR_API_TOKEN \
-X POST "https://your-instance.atlassian.net/rest/servicedeskapi/customer" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{"displayName": "Jane Doe","email": "jane.doe@example.com"}'

The customer will receive a portal invitation email.

Step 4. Create the request on behalf of the customer

curl -s -u your-email@example.com:YOUR_API_TOKEN \
-X POST "https://your-instance.atlassian.net/rest/servicedeskapi/request" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{
"serviceDeskId": "2",
"requestTypeId": "10",
"raiseOnBehalfOf": "jane.doe@example.com",
"requestFieldValues": {"summary": "Access request for new employee",
"description": "Please set up accounts for the new team member."}
}'

Key points:
- raiseOnBehalfOf takes the customer's email address. no need to look up their accountId
- The ticket will show the customer as the Reporter, not the agent
- The customer can see and interact with the ticket in the portal under My Requests
- If the customer doesn't exist yet, you must create them first (Step 3) - otherwise the API returns a 400 error

This is the cleanest approach for automation, onboarding flows, or any integration that needs to file tickets on behalf of end users.

Result is verified:

I used my original @cfcon.org account creating a SD Request in my Portal.
using my token and 

"raiseOnBehalfOf": "myMail@icloud.com"

when i registered to the portal using my icloud.com i found the issue i created with the above mentioned guide under "My Requests"

Hope this helps someone here who actually willing to try :)

best regards

cF

[Anton Ukhanev]

I want to flag that the accepted answer here does not hold for Customer Service Management (CSM) projects, at least not as of today (Jul 2026).

I tested the exact sequence described (`POST /rest/servicedeskapi/customer` to explicitly pre-create the customer, then `POST /rest/servicedeskapi/request` with `raiseOnBehalfOf` set to that same email) on a real CSM project. To rule out any permission/scope difference, I used a full site-admin's own classic API token (not a limited service account), and a genuinely fresh customer record with no prior history on the site.

Result: identical failure to plain `raiseOnBehalfOf` without pre-creation. Specifically:

- The ticket's `reporter` is correctly set to the customer (as expected).
- But `creator` remains whatever account made the API call, not the customer.
- The ticket's `Channels` field (a CSM-specific custom field, `customfield_10639` on our site) stays `null`.
- The ticket does **not** appear in that customer's "My requests" on the support website — confirmed by logging in as the actual customer and checking, not just inspecting the API response.

By contrast, I confirmed a ticket created by a genuine inbound email from that same customer's address **does** get `Channels` populated (`channelKey/email`) and **does** show up correctly in "My requests" — so this isn't a permissions or portal-configuration issue on our end, it's specifically about how the ticket-creation API call itself is authenticated/channeled.

This appears to be the exact behavior tracked in Atlassian's own public bug tracker: [CSM-33 - "Requests created in Jira/via API don't appear in the Help Center"](https://jira.atlassian.com/browse/CSM-33) (Bug, In Progress, 13 votes as of writing). That ticket's own description states plainly: *"There is currently not such mechanism by design, only support requests created through CSM channels are represented in the support site."*

It documents a partial workaround (writing a `sd.channel.context.key` issue property, plus attaching+submitting a Form via the Forms API) which I've also tested — the property write does make a ticket appear in the customer's request **list**, but clicking into it currently throws a "network error," seemingly because the Forms API can't resolve CSM's Customer-Experience-scoped form templates to complete the remaining steps. So even that workaround isn't fully production-ready today.

Given all this, I'd suggest editing the accepted answer (or at least adding a prominent caveat) to clarify it may only apply to classic/non-CSM JSM service projects, since it does not reproduce on CSM as of this testing.

[student300]

This is not the case with JSM, this needs to be fixed!

[Nancy Thomas]

Thanks for sharing this information.