How to Build an AI Agent for Salesforce and Jira

The workflow problem

Product-led companies live and die by their ability to turn customer feedback into shipped features. The feedback lives in Salesforce – captured in support Cases, logged as notes on Opportunity records, mentioned during renewal conversations tracked as Activities. The engineering work lives in Jira – broken down into epics, stories, and bugs, prioritized in backlogs, and executed in sprints.

The gap between these two systems is where customer requests go to stagnate. A customer success manager hears that three enterprise accounts need the same integration. They write a feature request in Salesforce, maybe send a Slack message to the product team, and hope someone picks it up. The product manager, meanwhile, has a Jira backlog of 400 items and no structured way to see which requests have revenue attached to them.

Even when a feature request does make it from Salesforce to Jira, tracking its progress is manual. The CSM checks in with the product manager periodically, asking “any update on that API rate limiting feature?” The PM checks the Jira ticket, reports the status, and the CSM relays this to the customer. This back-and-forth chain adds latency and introduces errors. The customer hears “it’s in development” when the ticket is actually blocked, or “it should ship next quarter” when the sprint plan has changed.

This disconnect means product teams build without full customer context, and customer-facing teams cannot give accurate delivery timelines.

Why an AI agent, not just automation

You could build a Salesforce-to-Jira automation that creates a ticket whenever a Case of type “Feature Request” is created. But this approach creates more problems than it solves. Every feature request becomes its own Jira ticket, leading to hundreds of duplicate tickets for the same underlying capability. The tickets lack engineering context – a CSM’s description of “the customer wants better reporting” does not translate directly into an actionable engineering spec.

An AI agent handles the translation between customer language and engineering language. When a CSM logs a feature request saying “Customer needs the ability to export data in CSV format from the analytics dashboard,” the agent searches existing Jira tickets for related work. If there is already an epic for “Analytics Export Functionality” with a story for CSV export, the agent links the Salesforce Case to the existing Jira ticket and adds the customer context as a comment rather than creating a duplicate. If no matching ticket exists, the agent creates one with a properly structured description that includes the customer use case, the business impact (deal size, account tier), and suggested acceptance criteria.

The agent also handles the reverse flow. When a Jira ticket’s status changes – moving to In Progress, delivered to staging, released to production – the agent updates the linked Salesforce Cases and notifies the account team. This bidirectional awareness means the CSM can tell their customer “the feature you requested shipped in last Tuesday’s release” without having to check Jira or ask the PM.

Prioritization is another area where intelligence matters. The agent can surface to product managers which Jira backlog items have the most customer revenue attached, helping them prioritize based on business impact rather than gut feeling.

How it works with ACP

The Agentic Control Plane connects to Salesforce and Jira through their respective OAuth flows, giving the agent API access to both platforms.

On the Salesforce side, the agent reads and writes Cases, Opportunities, Accounts, Contacts, Tasks, and custom objects like Feature Request records if you use them. It can query using SOQL, read activity histories, and access account metadata like ARR, tier, and renewal date. On the Jira side, the agent can create issues, update issues, transition statuses, add comments, search with JQL, read epics and sprint boards, and access custom fields.

You describe the agent’s responsibilities: “When a feature request Case is created in Salesforce, search Jira for existing tickets that address the same capability. If found, link the Case and add customer context. If not, create a new Jira story with the customer use case and business impact. When Jira tickets linked to Salesforce Cases change status, update the Case and notify the account owner.”

Here is a detailed example:

Salesforce Case created: “Feature Request: Webhook retry logic with configurable backoff” Account: NovaTech Solutions ($180K ARR, Enterprise tier) Description from CSM: “Customer’s event processing pipeline drops webhooks when their endpoint is temporarily unavailable. They need configurable retry logic with exponential backoff. This is blocking their expansion to the Enterprise Plus plan ($280K).”

Agent processing:

• Searched Jira for related tickets. Found PLATFORM-3421: “Implement webhook delivery retry mechanism” (Epic: Webhooks V2, Status: Backlog, Priority: P3)
• This ticket already has 2 linked Salesforce Cases from other customers (combined ARR: $95K)
• Agent actions:
  • Linked Salesforce Case to existing PLATFORM-3421
  • Added Jira comment: “Additional customer request from NovaTech Solutions ($180K ARR, Enterprise). Specifically needs configurable backoff intervals. This is blocking a $100K expansion to Enterprise Plus. Total customer ARR requesting this feature: $275K across 3 accounts.”
  • Updated Jira priority: P3 to P2 (based on cumulative revenue impact)
  • Added Jira label: revenue-blocker
  • Updated Salesforce Case: Status = “Linked to Engineering,” Jira Ticket = PLATFORM-3421, Engineering Status = “Backlog - P2”

Two weeks later, Jira ticket PLATFORM-3421 moves to “In Progress”:

Agent: Updated 3 linked Salesforce Cases with status “In Development.” Created Tasks for each account owner: “Notify customer that webhook retry feature is now in active development. Estimated delivery: Sprint 52 (March 28).”

The agent creates a closed loop between customer needs and engineering delivery.

Governance and security

Salesforce Cases may contain customer-reported security vulnerabilities, proprietary system details, and confidential business information. Jira tickets may reference internal architecture, unreleased features, and competitive positioning. The bridge between them must be carefully controlled.

Salesforce OAuth scoping restricts the agent to specific objects and fields. The agent can be configured to read Cases and Accounts but not access financial data on Opportunities, employee records, or other sensitive objects. Field-level security prevents the agent from reading fields that contain PII, credentials, or internal-only notes.

Jira OAuth scopes are limited to read:jira-work and write:jira-work. The agent can create and update issues but cannot modify project configurations, delete issues, or access admin-level settings. You can further restrict the agent to specific Jira projects, ensuring it only creates tickets in the product backlog project and cannot access security-related or HR projects.

The ACP audit log captures every cross-system action: which Salesforce Case triggered a Jira search, what search query was used, whether a match was found, what was written to Jira, and what updates were sent back to Salesforce. This bidirectional audit trail is essential for product teams who need to demonstrate that customer data is handled appropriately when it flows into engineering systems.

Information filtering is configurable. When the agent creates a Jira ticket from a Salesforce Case, you can specify which fields to include and exclude. Customer names and account details might be relevant for prioritization, but customer contact information, contract terms, or internal pricing can be stripped before the data reaches Jira. This prevents engineering teams from seeing information they do not need.

Data flow direction can be asymmetric. Customer context flows from Salesforce to Jira, but technical implementation details in Jira (architecture decisions, code references, infrastructure details) do not flow back to Salesforce unless explicitly configured.

Example use cases

• Feature request deduplication: The agent searches Jira for existing tickets before creating new ones, preventing duplicate engineering work. When multiple customers request the same feature, it links all Cases to one ticket and aggregates the revenue impact.

• Revenue-weighted prioritization: Product managers see which backlog items have the most customer ARR attached, making it possible to prioritize features based on quantified business impact rather than individual lobbying from account teams.

• Bidirectional status sync: When Jira tickets move through the development lifecycle (backlog, in progress, in review, released), the linked Salesforce Cases are updated automatically, and account teams receive tasks prompting them to notify the customer.

• Customer escalation routing: When a Salesforce Case is marked as an escalation or linked to a renewal at risk, the agent creates a Jira ticket with elevated priority and flags it for the engineering lead’s immediate attention.

• Release notification generation: When a sprint ships, the agent identifies all Salesforce Cases linked to the delivered Jira tickets and creates a batch of notifications for account teams to communicate with affected customers.

Getting started

Connect your customer feedback loop to engineering delivery in three steps.

1. Sign up at cloud.agenticcontrolplane.com. Free accounts include Salesforce and Jira connectors.

2. Connect your tools. Authorize Salesforce (standard connected app flow) and Jira (Atlassian OAuth with project-level scoping) from the Data Sources page.

3. Describe your agent. Define the workflow: “When feature request Cases are created in Salesforce, find or create matching Jira tickets. Include customer ARR and use case. Sync Jira status changes back to Salesforce Cases. Notify account owners when tickets ship.” The agent starts processing immediately.