Jira Integration Basics

Integration Model

• All Jira actions are initiated from within Salesforce via the Pharos platform.

• The integration does not allow Jira to directly push data into Salesforce. Instead, Salesforce users interact with Jira through Pharos.

• Ticketing rule templates in Pharos govern what Salesforce data is passed to Jira. This ensures that the scope of data transfer is under administrator/user control.

Jira Operations Supported

The following operations can be performed against Jira from Salesforce:

1. Create Jira Tickets

   • Salesforce issues/events can trigger the creation of new Jira tickets.

   • The ticket contains data fields mapped via the ticketing rule templates.

2. Associate Salesforce Records with Jira Tickets

   • Existing Salesforce objects can be linked to existing Jira tickets.

   • This provides bidirectional visibility while maintaining Salesforce as the source of initiation.

3. Add Comments to Jira Tickets

   • Salesforce users can post comments directly into a Jira ticket.

   • Comments flow one-way from Salesforce into Jira.

4. View and Inline Access to Jira Tickets

   • From Salesforce, users can pull up the Jira ticket details in an inline view.

   • This is a read-only interaction for visibility and does not push additional data.

5. Update Jira Ticket Status (Optional)

   • Certain workflows allow status updates to be triggered from Salesforce.

   • This depends on how rule templates are configured.

Relevant oAuth scopes:

• read:jira-user

• read:jira-work

• write:jira-work

• offline_access

Data Handling and Security Notes

• Data Control: The content pushed into Jira is explicitly defined in ticketing rule templates configured by the Salesforce admin or user.

• Scope Limitation: Only the data mapped in these templates will leave Salesforce for Jira.

• Auditability: Because actions originate in Salesforce, audit trails can be maintained within Salesforce on when and by whom a Jira operation was triggered.

Authentication Methods

OAuth Authentication for Cloud Jira

1. Initiation from Pharos

• An administrator in Pharos (running inside Salesforce) selects to connect Jira.

  

• Pharos generates an OAuth request and redirects the admin to Jira’s authorization endpoint.

2. Jira Authentication & Consent

• The admin signs in with their Jira (Cloud or Server/DC with OAuth configured) credentials.

• Jira displays a consent prompt, asking the admin to authorize Pharos as an application with specific scopes:

  • read:jira-user

  • read:jira-work

  • write:jira-work

  • offline_access

3. Authorization Code Exchange

• Once the admin approves, Jira issues an authorization code and redirects back to Pharos.

• Pharos exchanges this code at Jira’s token endpoint for an access token (and optionally a refresh token).

4. Token Storage & Use

• Pharos securely stores the Jira access token within a protected custom setting (scoped to the consent granted).

• All subsequent Jira actions initiated from Salesforce through Pharos (e.g., ticket creation, commenting, linking) are executed via Jira’s REST API using this token.

5. Refresh Lifecycle

• If Jira issues a refresh token, Pharos can silently refresh the access token when it expires, avoiding repeated logins.

• If not, the admin must re-initiate the OAuth flow when the token expires.

API Token Authentication for Cloud Jira

• An API token is generated by a Jira Cloud user from their Atlassian account. It replaces the password in basic authentication.

• Operation:

  • User generates a token in their Atlassian account settings.

  • The token is paired with the user’s email for API authentication.

• Advantages:

  • Eliminates password usage.

  • Tokens can be revoked individually without affecting the user’s main login credentials.

• Limitations:

  • Only available in Jira Cloud (not Server/Data Center).

  • Must be managed at the individual user level.

• Guidance:

  • Suitable for cloud environments if PATs are unavailable.

• Reference: Atlassian: Manage API tokens for your Atlassian account

Authentication for Hosted Jira

Hosted Jira authentication is facilitated via the following methods (depending on availability):

• Username (email) and password
• PAT Token

Username (Email) and Password

• Uses a Jira user’s email address (or username for older Server editions) and their Jira account password for authentication.

• Limitations:

  • Deprecated for Jira Cloud REST API access — Atlassian no longer supports basic auth with raw passwords.

  • Password-based access increases risk exposure (password reuse, lack of token rotation).

• Use Cases:

  • May still be available for some Jira Server/Data Center instances not using Atlassian Cloud.

• Guidance:

  • Avoid where possible. Prefer token-based methods for auditability and reduced credential exposure.

• Reference: Atlassian: Basic authentication with passwords (deprecated)

Personal Access Token (PAT)

• A Personal Access Token (PAT) is a bearer token created by a user in Jira Server or Data Center editions (and in some Cloud deployments, depending on configuration).

• Operation:

  • Generated in the user’s Jira profile (under Personal Access Tokens).

  • Used as a standalone token (no need to provide email/username).

• Advantages:

  • Strongly scoped, revocable, and auditable.

  • Works across both Server/Data Center and, in some cases, Cloud environments.

  • Does not expose user credentials.

• Guidance:

  • Preferred method: Widely available, secure, and typically recommended by Atlassian.

  • Should be used whenever PAT support is enabled.

• Reference: Atlassian: Create a personal access token (Jira Data Center/Server)

Security Recommendation

• Use Personal Access Tokens (PATs) whenever available for hosted Jira.

• For Jira Cloud, use oAuth or API Tokens.

• Avoid password-based authentication except where legacy constraints exist.