Instead of just explaining how to do it, an AI agent connects to Jira, creates the issue, updates the appropriate fields, and returns the ticket number. That’s exactly what IBM watsonx Orchestrate (wxO)<\/a> enables through its prebuilt Jira integrations.<\/p>\n\n\n\n In this blog post, I’ll walk through how I connected Jira Cloud to watsonx Orchestrate using the prebuilt Issue Manager<\/strong> agent from the wxO Catalog, what happens behind the scenes, and some lessons learned during setup.<\/p>\n\n\n\n Many business processes eventually end up in a ticketing system.<\/p>\n\n\n\n Typical examples include:<\/p>\n\n\n\n Instead of switching between tools and manually creating tickets, users can simply describe what they need in natural language.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n The agent handles the Jira interaction and translates user intent into API calls.<\/p>\n\n\n\n IBM provides a prebuilt Issue Manager<\/strong> agent in the watsonx Orchestrate Catalog.<\/p>\n\n\n\n This agent already includes multiple Jira tools, including capabilities such as:<\/p>\n\n\n\n Because these tools are already packaged and governed, there is no need to build custom APIs or write code.<\/p>\n\n\n\n You simply configure the Jira connection and the agent can immediately begin interacting with your Jira environment.<\/p>\n\n\n\n For demonstration purposes, I created a simple Jira Cloud project using the Kanban template.<\/p>\n\n\n\n The project contained the following work types:<\/p>\n\n\n\n Kanban is an ideal starting point because it provides a simple workflow:<\/p>\n\n\n\n There are no sprint configurations, backlog management activities, or additional Scrum artifacts that need to be configured beforehand.<\/p>\n\n\n\n For demo environments, simplicity is usually your friend.<\/p>\n\n\n\n Before the agent can create issues, it needs permission to access Jira.<\/p>\n\n\n\n This is where OAuth 2.0 comes into play.<\/p>\n\n\n\n In simple terms:<\/p>\n\n\n\n No passwords need to be shared between systems.<\/p>\n\n\n\n A key component of this process is the Callback URL<\/strong>.<\/p>\n\n\n\n Think of it as the return address.<\/p>\n\n\n\n The flow looks like this:<\/p>\n\n\n\n Without a valid Callback URL, the OAuth flow cannot complete.<\/p>\n\n\n\n The first major step is creating an OAuth 2.0 application inside the Atlassian Developer Console<\/a>.<\/p>\n\n\n\n When creating the application, you will need:<\/p>\n\n\n\n One lesson learned during setup:<\/p>\n\n\n\n Account-Level Access worked successfully<\/strong>, while Resource-Level Access caused repeated authentication challenges during testing.<\/p>\n\n\n\n If you encounter unexplained authentication issues, this is one setting worth verifying.<\/p>\n\n\n\n The application requires Jira permissions, called scopes.<\/p>\n\n\n\n Scopes determine what the application is allowed to do.<\/p>\n\n\n\n Examples include:<\/p>\n\n\n\n One of the most confusing parts of the setup was identifying the correct scope configuration.<\/p>\n\n\n\n Initially, I tried using only a minimal set of Jira scopes.<\/p>\n\n\n\n Although the authorization screen appeared correctly, the final authentication process repeatedly failed.<\/p>\n\n\n\n The solution was to use the complete scope set generated by Atlassian’s Classic Jira Platform REST API configuration.<\/p>\n\n\n\n Once the proper permissions were configured, authentication completed successfully.<\/p>\n\n\n\n Inside watsonx Orchestrate, the prebuilt Jira connection must be configured. Go to connections and search for the prebuilt connection for Jira with OAuth, click the dots on the right and edit connection.<\/p>\n\n\n\n The connection requires:<\/p>\n\n\n\n In addition, one important parameter needed to be added manually:<\/p>\n\n\n\n audience = api.atlassian.com<\/strong><\/p>\n\n\n\n Without this value, authentication completed up to the consent screen but failed afterward.<\/p>\n\n\n\n This was perhaps the most important troubleshooting discovery during the implementation.<\/p>\n\n\n\n If you switch to “Live” you can just “Paste Draft Configuration” and then save as Team Credentials so other can use the credentials as well.<\/p>\n\n\n\n Like many integrations, most of the effort was not spent on creating tickets but on configuring authentication correctly.<\/p>\n\n\n\n Some of the most important lessons learned:<\/p>\n\n\n\n I initially assumed that because Atlassian displayed the authorization screen, everything was configured correctly.<\/p>\n\n\n\n In reality, the OAuth process can still fail after consent has been granted.<\/p>\n\n\n\n Always verify that the token exchange completes successfully.<\/p>\n\n\n\n Using incomplete scopes resulted in repeated failures.<\/p>\n\n\n\n If authentication issues persist, review the generated authorization URLs and compare them with the configured scopes.<\/p>\n\n\n\n The OAuth flow ultimately succeeded only after ensuring that:<\/p>\n\n\n\n was included.<\/p>\n\n\n\n For customer demonstrations, Team Credentials are often easier because users do not need to perform individual authentications.<\/p>\n\n\n\n Start with simple validation steps:<\/p>\n\n\n\n Only then move on to:<\/p>\n\n\n\n This makes troubleshooting dramatically easier.<\/p>\n\n\n\n Once connected, the experience becomes surprisingly natural.<\/p>\n\n\n\n A user can ask:<\/p>\n\n\n\n “Show my Jira projects.”<\/em><\/p>\n\n\n\n The agent retrieves available projects.<\/p>\n\n\n\n Next:<\/p>\n\n\n\n “What issue types exist in project KAN?”<\/em><\/p>\n\n\n\n The agent identifies available work item types.<\/p>\n\n\n\n Finally:<\/p>\n\n\n\n “Create a bug in project KAN for login timeout issues affecting customer portal users.”<\/em><\/p>\n\n\n\n The agent creates the issue and immediately returns the newly generated Jira ticket.<\/p>\n\n\n\n From the user’s perspective, it feels less like interacting with Jira and more like collaborating with a digital team member.<\/p>\n\n\n\n Many AI demonstrations focus on summarization or question answering.<\/p>\n\n\n\n While useful, these scenarios don’t always show business value.<\/p>\n\n\n\n The Jira integration demonstrates something much more tangible:<\/p>\n\n\n\n The AI is no longer just providing information.<\/p>\n\n\n\n It is performing work.<\/p>\n\n\n\n That shift from information retrieval to action execution is what makes agentic workflows so powerful.<\/p>\n\n\n\n
\n\n\n\nWhy Integrate Jira with watsonx Orchestrate?<\/h1>\n\n\n\n
\n
\n
\n\n\n\nMeet the Issue Manager Agent<\/h1>\n\n\n\n
![\"\"](\"https:\/\/felixaugenstein.com\/blog\/wp-content\/uploads\/2026\/10\/jira-issue-manager-wxo-catalog-1024x444.png\")
<\/figure>\n\n\n\n\n
\n\n\n\nCreating a Jira Project for the Demo<\/h1>\n\n\n\n
\n
\n
\n\n\n\nUnderstanding the OAuth Connection<\/h1>\n\n\n\n
\n
\n
\n\n\n\nSetting Up the Atlassian OAuth Application<\/h1>\n\n\n\n
\n
\n\n\n\nConfiguring OAuth Permissions<\/h1>\n\n\n\n
![\"\"](\"https:\/\/felixaugenstein.com\/blog\/wp-content\/uploads\/2026\/10\/jira-oauth-1024x390.png\")
<\/figure>\n\n\n\n\n
\n\n\n\nConfiguring the Jira Connection in watsonx Orchestrate<\/h1>\n\n\n\n
![\"\"](\"https:\/\/felixaugenstein.com\/blog\/wp-content\/uploads\/2026\/10\/wxo-prebuilt-jira-connection-1024x406.png\")
<\/figure>\n\n\n\n\n
![\"\"](\"https:\/\/felixaugenstein.com\/blog\/wp-content\/uploads\/2026\/10\/jira-connection-values-1024x491.png\")
<\/figure>\n\n\n\n
\n\n\n\nThe Biggest Troubleshooting Lessons<\/h1>\n\n\n\n
1. The Consent Screen Doesn’t Mean Success<\/h2>\n\n\n\n
2. Scope Configuration Matters<\/h2>\n\n\n\n
3. Verify the Audience Parameter<\/h2>\n\n\n\n
\n
4. Use Team Credentials for Shared Demos<\/h2>\n\n\n\n
5. Test Incrementally<\/h2>\n\n\n\n
\n
\n
\n\n\n\nDemonstrating the Integration<\/h1>\n\n\n\n
\n\n\n\nWhy This Is a Great Agentic AI Use Case<\/h1>\n\n\n\n
\n
\n\n\n\nFinal Thoughts<\/h1>\n\n\n\n