How to export GUIDs for each individual user

[Vikram Jammula]

Hi Team,

We are running into a reporting issue in Jira and need your help resolving it. Example ticket where our associate <Name>logged multiple hours: 

When we go to Reports > Sprint Report and download the sprint details, the exported work log shows the user as a GUID rather than a readable ID. For <Name> entry we see:

03/Aug/26 5:14 PM ; ug:<ID> ; 28800

However, when we export the list of user IDs from the admin profile, <Name> appears as:

712020:<ID>

The two identifiers do not match, which is creating confusion in our reporting.

Could you please help us with one of the following ?

1. Ensure the Jira user ID (712020:...) is used in the sprint report work log export instead of the ug: GUID, or

2. Provide a way to export the ug: GUID from the admin profile so we can map it to the user ID.

[Andrey - Guenov Labs]

This is a known inconsistency on Atlassian's side, not something misconfigured on your end. The Sprint Report's CSV export runs on the legacy Agile/GreenHopper reporting backend, which has its own internal reference for "who logged this" — it isn't guaranteed to reuse the same accountId format (712020:...) that the rest of the Jira Cloud Platform REST API uses. Two related, still-open bug reports document this exact mismatch between worklog-author display and the platform accountId: JRACLOUD-77921 and JRACLOUD-77830. So neither of your two options is really configurable client-side — it's a backend gap Atlassian hasn't unified yet.

Practical workaround: don't try to reconcile the identifier the Sprint Report gives you. Pull the worklog data straight from the REST API instead, which consistently returns accountId in the same format your admin export uses:

GET /rest/api/3/issue/{issueIdOrKey}/worklog

For a whole sprint, loop the issues via GET /rest/agile/1.0/sprint/{sprintId}/issue, then call the worklog endpoint per issue — every entry's author.accountId will match your admin user list directly, no GUID translation needed. More calls than a single CSV export, but it sidesteps the report's legacy identifier entirely.

[Javier Martínez]

Hi Vikram,

What you are seeing is related to the way Jira Cloud represents user identifiers in some native CSV/report exports.

The important point here is that these two values should not be expected to match:

• 712020:... → this is the user’s Atlassian accountId, which is the standard identifier used by Jira Cloud REST APIs.
• ug:<GUID> → this is an internal user reference that can appear in some Jira Cloud worklog/CSV exports. It should not be treated as the user’s Jira accountId.

Since the GDPR-related changes in Jira Cloud, Atlassian uses accountId as the supported identifier for users in the REST APIs instead of the old username/userKey identifiers. However, unfortunately, not every native export represents user information in exactly the same way.

Regarding your two options

1. Can the Sprint Report export be configured to use the accountId instead of ug:<GUID>?

As far as the native Jira Cloud functionality is concerned, there is no configuration available to change the identifier format produced by that export.

Therefore, I would not recommend building the reporting logic around the ug:<GUID> value.

2. Can we export a mapping between ug:<GUID> and accountId from the admin user export?

There is no standard Jira Cloud admin export that exposes this ug:<GUID> value as a supported user identifier alongside the Atlassian accountId.

For that reason, trying to correlate both identifiers through the admin CSV is not a reliable approach either.

Recommended approach

If the objective is to build reporting based on who logged the work, when, and for how long, I would recommend retrieving the worklogs through the Jira Cloud REST API instead of relying on the Sprint Report CSV.

For example, the worklog endpoint:

GET /rest/api/3/issue/{issueIdOrKey}/worklog

returns each worklog together with its author, where Jira exposes the user’s accountId (and, depending on profile visibility, information such as displayName).

That gives you a consistent identifier that can then be matched against the users in Jira and used safely for reporting.

So, in short:

Sprint Report CSV
ug:<GUID> → internal representation → not suitable as the main user identifier

Jira REST API
author.accountId → Atlassian account ID → recommended identifier for reporting

If this report needs to cover multiple issues/sprints, the usual approach would be to retrieve the relevant issues first and then collect their worklogs through the API, using author.accountId as the user key.

I hope this helps clarify why the two IDs do not match.