Hi Atlassian Community! 👋
Access requests are one of the most common things a service desk handles, and one of the easiest to get slightly wrong.
The application list in the portal is typed in by hand, so it slowly drifts away from what is actually configured in Okta. And when the request lands, the agent sees a name and an e-mail, then opens Okta in another tab to find out who is asking, what their job title is and who their manager is.
A Jira Okta integration built on connected custom fields removes both frictions: a select list reads the active applications straight from Okta, and a read-only table shows the requester’s name, job title and manager on the request. Nothing is copied into Jira and nothing is written back to Okta. To be clear, this is about displaying data, not about SSO or provisioning.
I’m the Product Marketing Manager for Elements Connect at Elevatic, the app used in this guide, so I’ll also tell you where it isn’t the right fit. Let’s walk through it.
What does a Jira Okta integration for JSM requests actually do?
It puts Okta data where agents already work. Instead of typing an application list by hand and opening Okta to identify a requester, both come straight from Okta. The mechanism is connected custom fields: real Jira custom fields whose values come from an external source, here Okta's REST API.
 | Without the integration | With the integration |
|---|
Application list | Typed manually, updated when someone remembers | Read from Okta, active applications only |
Requester context | Name and e-mail | Name, job title and manager on the request |
Agent workflow | Open Okta in another tab, or ask the requester | Everything is on the request |
Admin workload | Keep the list in sync | Nothing to maintain on the Jira si |
How do you set up a Jira Okta integration with Elements Connect?
The setup has three parts: Okta (a token), Elements Connect (a datasource and two fields) and JSM (the request type and a post-function). Here is what you need before starting.
Requirement | Detail |
|---|
Okta | Permission to create an API token |
Elements Connect | Installed on your Jira Cloud instance; the read-only table type needs a recent version (Elements Connect version 7) |
1 - Generate an API token in Okta
Elements Connect reads Okta through its REST API, so the first job is to get a key it can use.
In the Okta admin console, you generate an API token (under Security > API > Tokens). Treat it like a password: Okta shows it only once, so keep it somewhere safe before closing the dialog.
2 - Create the Okta datasource in Elements Connect
Now you tell Elements Connect where Okta lives and how to authenticate. You create a datasource of type REST API, point it to your Okta domain [VERIFY exact format] and pass the token as an API key.
It is the only connection you configure: both fields below reuse it. The exact header format and screenshots are in the Okta tutorial of the Elements Connect documentation.
3 - Create the Application select list
This is the field that replaces the hand-maintained list. You create a connected custom field named Application, of type Select list, on the Okta datasource.
- What it fetches: only the applications that are active in Okta, so deactivated ones never show up.
- What the user sees: the application's name.
- What is stored: the application's Okta ID, so the value survives a rename
Because the list is read from Okta each time, there is nothing to keep in sync on the Jira side. The query and display templates are in the documentation page above.
4 - Create the User information table
Create a second connected custom field named User information, of type Read Only table, on the same datasource. Its columns are First Name, Last Name, Title and Manager, each mapped to an attribute of the Okta user profile.
The query looks up the user from the reporter's e-mail address, not from the current user. The field is filled by a post-function (Step 6), and at that moment the app itself is the identified user, so the current-user variable can't be used. See the documentation on dependencies on the current user.
5 - Add the fields to your request type
With both fields ready, you add them to your JSM request type from the Add field to portal action. The requester sees the Application list on the portal, and agents see both fields on the request, in the portal form or the work item view.
6 - Fill the user information automatically at creation
Without this step, User information would stay empty until someone opened or edited the field. A post-function on the workflow's Create transition fixes that: it recalculates the field the moment the request exists, so the agent finds the requester's profile already there.
You add the Update Elements Connect custom field value rule to that transition and select User information. The details are in How to update your custom field value on transition.
Which Jira custom fields and settings should you check before rollout?
Test with a handful of real users first. Three checks catch most problems.
Check | Why it matters | What to do |
|---|
E-mail matches Okta login | The lookup uses the reporter's Jira e-mail; no match, empty table | Test several users; adapt the query if your login format differs |
Columns shown | Agents see everything you display | Keep job title and manager; skip phone numbers unless needed |
Post-function | A table filled only after opening the field defeats the purpose | Create a test request and check the table at creation |
When is this the right approach, and when is it not?
It fits when agents need to see who is asking without leaving the request, and you'd rather not maintain an application list by hand. It does not grant or enforce access. Other apps also bring external data into Jira fields, and you can compare them on the Atlassian Marketplace.
Your goal | Better fit |
|---|
Show requester context and a live application list | This setup |
Grant, revoke or enforce access | Okta workflows, or an Automation rule calling Okta's API |
Sign users in, create or remove accounts | SAML SSO and SCIM provisioning, such as Atlassian Guard |
Conclusion
A Jira Okta integration based on connected custom fields gives a JSM request a live application list and the requester's profile, with Okta as the single source of truth. Remember the three essentials: the setup displays data but does not provision access, the reporter's e-mail must match the Okta login, and the post-function is what fills the table at creation.
Next step: once this works, the same Okta connection can set the reporter's manager as approver. The configuration is described in How to set the Reporter's Manager as Approver from Okta.
