Syncing Salesforce Case Data to Jira Without Leaking Customer PII: Field Rules, Custom Objects and API Limits
Last updated: November 2026
A safe Salesforce to Jira integration sends engineers the context they need to fix a problem and nothing more. In practice that means syncing a small, agreed set of Case fields, replacing customer identifiers with Account-level context or references, masking or removing personal data in free-text fields, and running the integration as a dedicated, minimum-access user authenticated through a connected app. It also means designing the sync to stay well within your Salesforce org's daily API request allocation. In ZigiOps, the no-code integration platform by ZigiWave, each of these controls is configured in a guided UI instead of in code.
Escalating Salesforce Cases to Jira is one of the most common CRM-to-engineering integrations. Support agents need bugs fixed, account teams need to know when, and engineers need enough detail to reproduce the problem. The risk is that a quick "sync all fields" setup copies customer names, email addresses, phone numbers and contract details into a system with a much wider audience and a different data retention policy.
This guide covers the three design areas that decide whether a Jira Salesforce integration is safe and stable: which fields to sync, how to handle personal data and custom objects, and how to authenticate and stay within API limits. It applies whether you use a Marketplace connector, an AppExchange app, an integration platform or custom code.
Why Salesforce to Jira integrations leak personal data
Salesforce is built around customer records. A Case links to a Contact (a named person) and an Account (a company), and both carry personal and commercial data. Jira is built around work. Projects are often open to entire engineering departments, contractors and partner teams, and Jira issues are copied into other tools such as chat, dashboards and AI assistants.
Personal data usually leaks through three paths:
- Identifier fields. Contact name, email and phone are synced because they are "useful context".
- Free text. Case Description and comments contain whatever the customer wrote, including signatures, phone numbers, account numbers and sometimes passwords.
- Attachments. Screenshots, exports and email threads carry data that nobody reviewed before syncing.
Under data protection rules such as GDPR, copying personal data into another system is processing that needs a purpose and minimisation. Even where regulation is not the concern, customer contracts often restrict who can see customer data. Design the integration so that the default is to leave personal data out.
Step 1: Decide which Salesforce fields Jira actually needs
Start from the engineer's questions
An engineer looking at an escalated bug needs to answer a few questions: What is broken? How bad is it? Which product, version and environment? Can it be reproduced? Who should be told when it is fixed? Only the last question involves a person, and the answer can be "the support agent who owns the Case", not the customer.
Salesforce field types and what they mean for sync
Salesforce field types affect how values travel. Picklists map cleanly to Jira select fields. Lookups (such as AccountId or ContactId) are IDs that mean nothing in Jira unless you resolve them to a value. Rich text and long text areas can contain HTML and must be converted. Formula fields are read-only and calculated, so they can be sent to Jira but never written back. Encrypted text fields return masked values to users without permission to view them.
| Salesforce field | Field type | Sync to Jira? | Jira target | Notes |
|---|---|---|---|---|
| CaseNumber | Auto number | Yes | Custom text field, for example "Salesforce Case" | Correlation ID; no personal data |
| Subject | Text | Yes, after review | Summary | Agents should write subjects without customer names |
| Description | Long text area | Yes, masked | Description | Apply masking rules for emails, phones and card numbers |
| Priority | Picklist | Yes | Priority | Use a mapping table |
| Status | Picklist | No (Jira status flows back instead) | Not applicable | Jira owns engineering status |
| Product or version (often custom, __c) | Picklist | Yes | Component or custom select field | Map values explicitly |
| AccountId | Lookup | Resolved, not raw | Custom field "Customer tier" or "Account segment" | Send tier, region or segment, not necessarily the name |
| ContactId, SuppliedName, SuppliedEmail, SuppliedPhone | Lookup, text, email, phone | No | Not applicable | Personal data; engineers contact the support agent instead |
| OwnerId | Lookup | Resolved to name | Custom field "Support owner" | Employee data; usually acceptable |
Account context without the account name
Engineers often need to know that a bug affects a large or strategic customer, because it changes priority. They rarely need the company name. Send derived values instead: customer tier, region, contract level or the number of open Cases on that Account. If your organisation decides account names are acceptable in Jira, restrict the field's visibility (see Step 3).
Step 2: Mask personal data in free text
Field rules are not enough, because customers put personal data into Description and comments. Masking is the second line of defence.
What to mask
- Email addresses
- Phone numbers
- Payment card numbers and bank account numbers
- Government ID formats relevant to your markets
- Strings that look like passwords, API keys or tokens
- Email signatures and reply chains below the first message
How to mask
Most integration tools let you apply a transformation or regular expression to a field before writing it. Replace matches with a neutral placeholder such as "[email removed]" rather than deleting them, so engineers know information existed and can ask the support agent for it. Test masking rules against real, anonymised Case text, because customer writing is messier than test data.
How this works in ZigiOps: ZigiOps field mapping supports expressions and regular expressions, so you can replace email addresses and phone numbers with placeholders before the Jira field is written. Because it does not store the data it transfers, unmasked values are not kept in a middle layer either.
| Data type | Detection approach | Replacement |
|---|---|---|
| Email address | Regular expression for name, at sign and domain | [email removed] |
| Phone number | Regular expression for digit groups with optional country code | [phone removed] |
| Card number | 13 to 19 digit sequences, optionally checked with the Luhn algorithm | [card number removed] |
| Token or key | Long strings of mixed letters and digits after words such as "key", "token" or "password" | [secret removed] |
| Email signature or thread | Text after common markers such as "Best regards" or "From:" | [earlier messages removed] |
Regular expressions will miss some data and occasionally mask harmless text such as version numbers. Treat masking as risk reduction, not a guarantee, and combine it with field rules and access controls.
Comments and attachments
Case comments and email messages follow the same rules: mask before syncing, and sync only comments marked as public or flagged by the agent. For attachments, the safest default is not to sync automatically. Let the support agent choose which files to send, or allow only specific types such as log files after the agent has checked them.
Step 3: Restrict access on the Jira side
Even with careful field rules, some synced issues will contain sensitive context. Jira gives you several controls to limit who sees them:
- Issue security schemes (company-managed projects) restrict issues to specific roles or groups. Set a security level automatically on issues created by the integration.
- A dedicated escalation project with tighter permissions keeps customer escalations separate from general backlogs. Engineers move or link work into their team projects once the problem is understood.
- Field configuration can hide sensitive custom fields from screens where they are not needed.
- Comment restrictions limit synced Salesforce comments to a project role.
Also check where Jira data flows next. If Jira issues feed a data warehouse, a chat channel or an AI assistant, the personal data you sync will flow there too.
Step 4: Handle custom objects and related records
Many Salesforce orgs store important escalation context in custom objects (API names ending in __c), such as product installations, environments or entitlements. Engineers often need this context more than they need Case fields.
Patterns for custom objects
- Flatten onto the issue. Read the related custom object record (for example, Installation__c linked from the Case) and write selected fields, such as version and hosting region, into Jira custom fields. This is the simplest pattern and works for one related record.
- Summarise in text. For several related records, build a short summary in a single Jira field, for example "Environments: EU-prod v5.2, US-prod v5.1".
- Sync the object separately. If the custom object represents real work, such as a feature request, sync it as its own Jira issue type and link it to the escalation issue.
Use the Salesforce object reference and your org's Object Manager to confirm API names, field types and relationships before mapping. Custom object field names are case-sensitive in the API and must include the __c suffix.
How this works in ZigiOps: ZigiOps treats related records as part of the sync, so you can apply conditions to them as well. Its Data Explorer view shows the Salesforce schema it has retrieved, which is the quickest way to confirm that a custom object field is visible to the integration user before you map it. ZigiOps can also link many Salesforce Cases to a single Jira issue, so when several customers report the same problem, engineering receives one copy of the escalation context instead of several, which keeps the data in Jira to a minimum.
Step 5: Authenticate with a connected app and a minimum-access user
The integration user
Create a dedicated integration user instead of using an administrator's account. Salesforce offers an API-only integration user license and profile for this purpose in many editions. Grant access through a permission set that includes only the objects and fields the integration needs. Field-level security then enforces your field rules at the source: if the integration user cannot read Contact email, no misconfiguration can send it.
How this works in ZigiOps: ZigiOps connects to Salesforce as the dedicated user you configure, so field-level security applies to everything it reads. According to its security documentation, ZigiOps encrypts stored authentication details such as passwords and tokens with FIPS 140-2 compliant AES encryption using a 256-bit key.
Connected app and OAuth
Authenticate through a connected app (or the newer external client app framework where available) using OAuth. The JWT bearer flow and the client credentials flow are suited to server-to-server integrations because they do not depend on a person's password. Salesforce has been steering integrations away from the username-password flow, so check your org's security settings before relying on it.
About Salesforce security tokens
Many older guides tell you to get a Salesforce security token and append it to the password. The token is generated by the user through "Reset My Security Token" in personal settings and is emailed to them. It is needed only for username-password logins from outside trusted IP ranges. If you use OAuth with a connected app, you do not need a security token at all, which is one more reason to prefer OAuth.
| Method | Suited to | Main consideration |
|---|---|---|
| OAuth JWT bearer flow | Server-to-server integrations | Requires a certificate uploaded to the connected app |
| OAuth client credentials flow | Server-to-server integrations | Runs as a designated execution user; check availability in your org |
| OAuth web server flow | Tools where an admin authorises access once | Refresh tokens must be stored securely |
| Username, password and security token | Legacy integrations | Depends on a password; may be restricted by org settings |
Step 6: Stay within Salesforce API limits
How the allocation works
Salesforce gives each org a total API request allocation over a rolling 24-hour period, based on edition and licences. You can see current usage in Setup under Company Information, and programmatically through the limits resource of the REST API. When the allocation is exhausted, further API calls fail until usage drops, which breaks every integration in the org, not just yours.
How integrations waste API calls
- Aggressive polling. Querying for changed Cases every 30 seconds uses calls even when nothing has changed.
- Record-by-record reads. Fetching each Case, then its Account, then its custom objects in separate calls multiplies usage.
- Re-syncing everything. Comparing all open Cases on every cycle instead of only those modified since the last run.
How to reduce usage
- Query only records modified since the last successful sync, using SystemModstamp or LastModifiedDate.
- Use SOQL relationship queries to fetch the Case with its Account and related custom object fields in one call.
- Filter at the source, for example only Cases with an "Escalate to engineering" flag set.
- Consider event-driven options such as Platform Events, Change Data Capture or outbound messages for near real-time sync, so the integration reacts to changes instead of polling.
- Set a polling interval that matches the business need. For most escalations, a few minutes is enough.
- Monitor usage and alert well before the allocation runs out.
How this works in ZigiOps: ZigiOps queries Salesforce on a schedule you set, and its Last Time expression collects only records newer than the last one it processed. Combined with a source filter on escalated Cases, this keeps API usage proportional to the number of escalations rather than the size of your org.
Choosing an approach
Options for connecting Salesforce and Jira include AppExchange and Atlassian Marketplace connectors, standalone integration platforms and custom code using both REST APIs. ZigiOps, a standalone no-code platform, lets you pick fields individually, apply masking expressions before writing, connect through a dedicated integration user and collect only changed records, and it keeps no transferred data, only a few kilobytes of runtime state. Other platforms such as Exalate, Getint or Workato take script-based or recipe-based approaches. When you compare them, check four things specifically: whether you can choose fields individually rather than syncing whole records, whether transformations such as masking can be applied before writing, whether the tool supports OAuth with a dedicated integration user, and how it fetches changes and handles API limits. Also ask where the tool stores data in transit and for how long.
Testing checklist
- Create a Case with a Contact and confirm no Contact name, email or phone reaches Jira.
- Put an email address, phone number and card-like number in Description and confirm each is masked.
- Confirm the integration user cannot read fields excluded by field-level security, even if a mapping refers to them.
- Confirm Account context arrives as tier or segment, not as raw IDs.
- Confirm custom object fields arrive for a Case with one and with several related records.
- Confirm Jira issues created by the integration receive the correct security level.
- Run the integration for a day in a full sandbox and compare API usage before and after.
- Revoke the connected app's access and confirm the integration fails safely and alerts someone.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Customer emails appear in Jira | Contact or Supplied fields mapped, or Description not masked | Remove the mapping, add masking, restrict field-level security |
| Jira shows IDs such as 001... instead of names | Lookup fields sent raw | Resolve lookups with a relationship query |
| Custom field values missing | Wrong API name, missing __c suffix or no field permission | Check Object Manager and the integration user's permission set |
| Integration stops with request limit errors | Daily API allocation exhausted | Reduce polling, use incremental and relationship queries, review other integrations |
| Login fails after a password change | Username-password flow with security token | Move to OAuth with a connected app |
Frequently asked questions
What Salesforce data should sync to Jira?
Sync the Case number, subject, masked description, priority, product and version, and Account context such as tier or region. Leave out Contact details and other personal data unless there is a clear, documented need.
How do I connect Jira and Salesforce securely?
Use a dedicated integration user with a minimum-access permission set, authenticate through a connected app with OAuth, enforce field-level security, mask free text and restrict access to synced issues in Jira.
Do I need a Salesforce security token for a Jira integration?
Only for username-password logins. If the integration authenticates with OAuth through a connected app, no security token is required.
Can custom objects be synced to Jira?
Yes. Read them through their API names (ending in __c) and either flatten selected fields onto the Jira issue, summarise several records in one field, or sync the object as its own issue type.
How many API calls does a Salesforce to Jira integration use?
It depends on polling frequency, query design and volume. Incremental queries, relationship queries and event-driven triggers keep usage low. Check consumption in Setup under Company Information.
Can ZigiOps mask personal data when syncing Salesforce Cases to Jira?
Yes. ZigiOps applies expressions and regular expressions in field mapping, so email addresses, phone numbers and other identifiers can be replaced with placeholders before the Jira issue is written. ZigiOps also syncs only the fields you map, and it does not store the transferred data.
Is masking enough to make the integration GDPR-compliant?
No. Masking reduces risk but is one control among several. Combine it with field minimisation, access restrictions, retention rules and a documented purpose, and involve your data protection officer.
Key takeaways
- Design the Salesforce to Jira integration around what engineers need, not around what Salesforce contains.
- Leave Contact details out, send Account context as tier or segment, and resolve lookups instead of sending IDs.
- Mask personal data in Description and comments, and do not sync attachments automatically.
- Enforce rules at the source with a minimum-access integration user and field-level security, authenticated through OAuth.
- Restrict access to synced issues in Jira and check where Jira data flows next.
- Protect your org's API allocation with incremental queries, relationship queries and event-driven triggers.
- ZigiOps lets you configure field selection, masking expressions, a minimum-access integration user and incremental collection without code, and it stores no transferred data.