Update which I feel this will be helpful for the community, after a few rounds of Salesforce-Jira integrations, here's what's consistently saved us troubleshooting time: 

1. Don’t sync everything: Concentrate on business-critical fields (Case, Bug, Story, Priority, Status, Assignee, Resolution). A leaner scope will result in better performance, lower API usage and less conflicts. 

2. Go event-driven over scheduled polling: Keeps Support, Engineering, and Product on the same current data. 

3. Map fields before you build: Picklists, Statuses, Priorities, Record Types rarely map 1:1 across systems. 

4. Assign source of truth per field: Avoid update loops e.g. Engineering owns Resolution/Sprint, Support owns Customer Impact/Case Priority. 

5. Think about API limits. Bulk updates burn your allocation fast. Use batching, retries, error handling. 

6. Filter attachments/comments: Not everything should cross systems; filter by visibility, user type or keywords to keep internal notes internal 

7. Support multiple Jira projects/instances: Configurable mapping scales better than hardcoded routing logic 

8. Monitor failed syncs proactively: Logging + retry queues + alerts catch issues before they silently break workflows 

For

a Salesforce Jira connector, handles bi-directional sync without middleware and covers most of this out of the box. 

What I have seen from my personal experience: 

• Jira user-based price skyrockets as companies look to scale.
• Organizations require a single Salesforce Case to sync with numerous Jira issues but not all connectors enable this natively in SF.
• Parent-child Case circumstances necessitate workarounds particularly for enterprise support teams.
• Validating skills beyond the demo - real-world workflows help to identify shortcomings.
• Comment synchronization is an area that is often overlooked, yet it can have a significant influence on collaboration if it is not trustworthy.
• Also, don't just ask if it's 'bi-directional'; inquire about whether it's genuinely real-time and how it handles conflicts and retries.

These are just patterns I've observed across customer conversations and implementations.