nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Populate JSM with reporter account profile data?

Darryl St_ Pierre

We automatically provision Atlassian accounts for all new staff, and add them to a group that has Customer access to JSM. We sync multiple details from our Identity Provider, such as Department and Title, to name a few.

Our submission forms include questions such as Department, Phone Number that we would like to automatically capture from a user's profile rather than ask them to fill it out.

I see that with the introduction of Customer Service Management we can create new fields for this, but it requires a separate import. Wondering if that's our only option, or if we can utilize the information that's being included in account creation.

Accepted answers

Scott Boisvert

You would want to make an API call in your automation to the Get details of a user in a directory API. You can then parse through the JSON returned in the automation to get the department, etc.

Unfortunately, I don't believe there is a more direct way to do that.

Sami Shaik

@Darryl St_ Pierre ,

@Scott Boisvert has the right call, and I want to add why it is needed and a design that keeps it out of every rule you write.

Why the form cannot just read the profile. Automation's user smart values expose exactly six things: accountId, active, avatar URLs, displayName, emailAddress and timeZone (smart values for users). Department, title, organisation and phone are managed-account attributes: they are synced by Guard from your identity provider into Atlassian Administration, but they are not stored on the Jira user object, so no smart value and no JQL sees them. Atlassian tracks automation access to those attributes as ACCESS-822.

Two ways to read them, one way to use them well.

Per rule, as Scott says: Send web request to <a href="https://api.atlassian.com/users/%7B%7Bissue.reporter.accountId%7D%7D/manage/profile" target="_blank" rel="nofollow noopener noreferrer">https://api.atlassian.com/users/{{issue.reporter.accountId}}/manage/profile</a> with an organisation API token (not a Jira API token), Delay execution ticked, then {{webResponse.body.account.extended_profile.department}} and .job_title in an Edit action. Works today; the cost is one web request per request created and an org-admin token living in a space's rule.
Once per user, then smart values everywhere: write the attributes into user entity properties at provisioning time (a scheduled rule or a small script calling PUT /rest/api/3/user/properties/{key}?accountId=...), and from then on every rule reads {{reporter.properties.department}} as an ordinary smart value, no web request, no admin token in the rule (user entity properties in automation). One sync job, refreshed weekly against your IdP, and the forms fill themselves through a "Work item created" rule that copies the properties into the fields.

On Customer Service Management: the customer detail fields you mention are the right long-term home if you are on CSM, because they attach to the customer record rather than to a work item, and queues, SLAs and the agent view can read them. The import is a one-off or an API push, so it is the same sync job as option 2 pointed at a different target. If you are already on CSM, feed the detail fields and read them from the work item; if not, entity properties give you the same effect without the plan change.

Either way, the sentence to keep: profile attributes never reach Jira on their own; something has to copy them, and copying once beats fetching every time.

All comments

Scott Boisvert

You would want to make an API call in your automation to the Get details of a user in a directory API. You can then parse through the JSON returned in the automation to get the department, etc.

Unfortunately, I don't believe there is a more direct way to do that.

Sami Shaik

@Darryl St_ Pierre ,

@Scott Boisvert has the right call, and I want to add why it is needed and a design that keeps it out of every rule you write.

Two ways to read them, one way to use them well.

Per rule, as Scott says: Send web request to <a href="https://api.atlassian.com/users/%7B%7Bissue.reporter.accountId%7D%7D/manage/profile" target="_blank" rel="nofollow noopener noreferrer">https://api.atlassian.com/users/{{issue.reporter.accountId}}/manage/profile</a> with an organisation API token (not a Jira API token), Delay execution ticked, then {{webResponse.body.account.extended_profile.department}} and .job_title in an Edit action. Works today; the cost is one web request per request created and an org-admin token living in a space's rule.
Once per user, then smart values everywhere: write the attributes into user entity properties at provisioning time (a scheduled rule or a small script calling PUT /rest/api/3/user/properties/{key}?accountId=...), and from then on every rule reads {{reporter.properties.department}} as an ordinary smart value, no web request, no admin token in the rule (user entity properties in automation). One sync job, refreshed weekly against your IdP, and the forms fill themselves through a "Work item created" rule that copies the properties into the fields.

Either way, the sentence to keep: profile attributes never reach Jira on their own; something has to copy them, and copying once beats fetching every time.

Olha Yevdokymova_SaaSJet

Hi @Darryl St_ Pierre

There are two slightly different things involved here: the attributes stored on the managed Atlassian account and the newer Customer Service Management customer detail fields.

For managed accounts, Atlassian does support syncing attributes such as Department and Job title from your identity provider. The limitation is that those profile attributes aren't currently exposed directly to JSM request forms or as standard Jira Automation smart values.

For Department, there is now a native workaround documented by Atlassian:

Let the customer submit the request without asking for Department.
Trigger Jira Automation when the work item is created.
Use Send web request to retrieve the reporter's profile using their accountId.
Read the Department value from the API response and write it to a Jira field.

So you can reuse the Department information you're already provisioning rather than maintaining it separately in Customer Service Management. The trade-off is that the value is populated after submission, rather than appearing prefilled on the request form.

Customer Service Management customer detail fields are a separate data store. If you want Department, Phone, etc. available there as customer-profile data, Atlassian currently provides API/CSV import for populating those fields.

I'd also treat Phone Number separately. Department and Job title are supported Atlassian account profile attributes, but I wouldn't assume a phone number synced from your IdP is exposed through the same Jira user API without checking your specific provisioning setup.

Another approach you might consider, if you want the values populated before submission rather than after the request is created, is Smart Forms for Jira, developed by my team at SaaSJet. Smart Forms supports pre-filling text fields through URL parameters or sending pre-filled form from Jira smart values so an internal portal that already knows the logged-in employee's Department/Phone can pass those values into the form without displaying or asking for them. Those values can then be mapped directly to Jira fields when the request is created.

Resources
https://support.atlassian.com/atlassian-cloud/kb/sync-job-title-attribute-to-managed-atlassian-accounts-with-azure-ad-scim-provisioning/
https://support.atlassian.com/atlassian-cloud/kb/populate-a-custom-field-with-the-reporters-department-using-jira-automation/

Alan Bruce

We got tired of waiting for Atlassian to implement this so we just built an Asset Schema for Users and do a daily sync with the user information. Seems like this should not need be needed but it helps. Of course, now Atlassian wants to charge for Automation executions which was the main way to create 'workarounds' for stuff that was not working out of the box. For some reason I keep thinking about the Dog chasing its tail image.

Dog chasing tail.jpg

Eduardo Anflor - MindPro

Hi, @Darryl St_ Pierre

This is a common gap — Jira Service Management doesn't expose synced identity-provider attributes (department, title, manager, location) directly to request forms or as out-of-the-box smart values, so most teams end up gluing together automation rules plus REST calls to the directory API just to pre-fill a single form field. It also does not allow you to bring data into your JSM user profile. However, you can track this information inside the tickets, for example.

If this can work for you and you are open to a marketplace solution, I recommend Mindpro Sync. I work at Mindpro, and I believe this app can solve this issue at the source: it syncs user attributes from your identity provider (Entra ID, Okta, Google Workspace, or OneLogin) directly into native Jira/JSM custom fields, so department, title, manager, and location can be visible in the issues these users open.

After establishing the connection, you map your identity provider's attributes into Jira/JSM custom fields:

Screenshot 2026-09-09 at 09.25.21.png

When the user creates an issue, you can display the information directly in the "Details" panel, and also display the hierarchy based on the manager information provided in your IDP:

Screenshot 2025-02-18 at 10.27.52.png

If you prefer, you can also display the information in the customer portal:

Screenshot 2025-02-25 at 09.21.34.png

The system also allows you to set the approver automatically based on the hierarchy and offers some post-functions that can be used for approvals or field updates during workflow transitions. You can set the app to work with the same rules for all spaces or specify different fields per space.

I hope that helps.

Regards,

Eduardo

Darryl St_ Pierre

Thank you @Sami Shaik for a well thought out and meaningful explanation and answer.

Darryl St_ Pierre

Thank you Scott!

Darryl St_ Pierre

@Eduardo Anflor - MindPro , I appreciate the answer. At present, we're trying to limit add-ons where possible, but this is good information for others with the same questions.

Darryl St_ Pierre

@Olha Yevdokymova_SaaSJet , I appreciate the answer. At present, we're trying to limit add-ons where possible, but this is good information for others with the same questions.

Darryl St_ Pierre

I feel your pain @Alan Bruce . This topic arose after someone mentioned a meeting to discuss addressing this information with Automations, which triggered my "we have limits" alarm. Even though I discovered we are seriously below our usage threshold, I'm always trying to make sure we consider all options before adding another.

And... we're using Assets for inventory and are already nearing our included limit of objects.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management