Map selected Pipedrive deal fields into the initial Jira description using clear labels, readable option values, and explicit currency and date formats. Decide how missing values should appear and whether later deal changes update the description, appear in a panel, or create a comment. Those are separate behaviors to verify.
BacklogBridge's Pipedrive integration describes including selected deal fields in the initial Jira description. The mapping below is a design and acceptance example to verify against your installed version; it is not a claim that every Pipedrive field type is supported.
Start with the fields delivery actually uses
Ask the delivery team which facts it needs to take the next action. A compact onboarding description might need purchased service, region, agreed scope, requested date, and a source deal reference.
Exclude internal sales notes and personal data that the Jira audience does not need. Mapping a field also copies its information into another access context.
Use this example as a specification:
| Pipedrive information | Desired Jira text | Behavior to verify |
|---|---|---|
| Service tier, single option | Service: Standard onboarding | Human-readable label, not an option ID |
| Contract value, monetary | Contract value: 12,000 USD | Both amount and currency preserved |
| Requested date | Requested start: 2026-10-12 | Date meaning preserved without timezone drift |
| Regions, multiple options | Regions: EU; UK | All selected labels shown once |
| Scope notes, long text | A labeled paragraph | Line breaks and meaningful content retained |
| Missing optional value | Not provided or an omitted optional line | Chosen rule applied consistently |
All values are fictional. Contract value is sales context; it does not automatically become an approved delivery budget.
Identify fields by more than their display names
Pipedrive documents several custom field types, including option lists, monetary values, dates, and references to other records. These types have different representations. Pipedrive field-type documentation.
For a custom implementation, use the account's actual field metadata. Pipedrive's API explanation of custom fields notes that field keys differ between accounts. Two fields with the same label are not necessarily the same integration field.
Keep an internal mapping record with the source object, field identifier, type, destination, required status, and fallback rule. Update it when an administrator replaces a field rather than merely renaming it.
Compare a mapping against explicit expected output
The mapping test cases provide six fictional inputs with expected text. These are normalized review records, not raw Pipedrive payloads. They specify a desired description contract that you can check against your installed integration.
| Input condition | Expected handling |
|---|---|
Service option 12, mapped to “Standard onboarding” | Service: Standard onboarding |
Amount 12000 with currency USD | Contract value: 12,000 USD |
Date-only value 2026-10-12 | Preserve that calendar date |
Region choices eu, uk, eu | Resolve labels and show Regions: EU; UK once each |
| Missing optional reference | Optional reference: Not provided under this chosen contract |
Service option 99 absent from the supplied metadata | Flag the mapping for review; do not invent a label |
The local reference formatter passes all six cases, including the unmapped-option outcome. That verifies the fixture and expected formatting, not connector support for every type or fallback. In a real account, use its current field and option metadata, then compare the created issue with the expected text.
Record unsupported cases explicitly. If required context cannot be mapped, decide how the handoff should be stopped or reviewed using capabilities the connector actually provides. A missing option label is useful diagnostic evidence when following the webhook investigation guide.
Decide whether the description is a snapshot
There are at least three possible behaviors after issue creation:
- The description retains the original handoff values.
- The integration changes selected fields or sections.
- New values appear elsewhere, such as a comment or deal panel.
Check the actual behavior. A live panel does not mean that the original description is refreshed, and a comment does not change the value used by a Jira report.
For a creation snapshot, make the boundary explicit in the text: “Sales handoff captured when this issue was created; use the linked deal for current commercial details.” Avoid promising automatic updates unless your test shows the required behavior.
Protect delivery's own notes
If a connector rewrites description content, find out how it identifies the section it owns. Ask what happens after a delivery user edits the same area.
Use separate labeled sections where the integration supports them. Do not design a workflow that depends on the app preserving free-form edits unless that behavior has been verified. If controlled updates are unsupported, a creation snapshot plus a link to the source may be easier to maintain.
Test difficult values before ordinary ones
Create a sample deal with fictional information and include:
- An option whose label differs clearly from its internal identifier.
- A monetary value with an explicit currency.
- A date near a timezone boundary if the field includes time.
- A multiline note with punctuation and a harmless URL.
- An empty optional field and a missing required field.
After creating the issue, compare the rendered description with the source. Then change a source value and inspect the description, comments, and panel separately.
Record any truncation, raw identifiers, unwanted formatting, or ambiguous empty values. Fix the rule or narrow the supported mapping before applying it to real handoffs.
Use structured Jira fields only when the connector supports them
If a value must drive a filter, dashboard, or workflow condition, free text in a description may be a poor destination. Consider a supported structured field, but check the connector's capability and Jira's required value format first.
Do not describe a description-template feature as universal custom-field synchronization. They solve different tasks and have different validation requirements.
Use the deal-to-issue walkthrough to validate the complete handoff. If the mapping looks correct but no issue arrives, investigate the webhook and delivery path.