Use Cases
Common ways teams use HubSpot for Jira. Each entry links to the page that explains the setup in full.
Automating a single step
Each automation rule solves one recurring problem. These are the scenarios they were built for.
Scenario | Rule |
|---|---|
A customer escalation in Jira should appear in HubSpot without anyone copying details across | |
A support work item should be linked to the Contact or Company that already exists in HubSpot | |
Revenue-impacting work should always have a Deal attached, without creating duplicates | |
A work item is no longer customer-relevant and should stop showing in the CRM | |
A work item moved to internal work and every CRM association should be cleared at once | |
Sales keeps asking for status; owners of linked records should be told automatically | |
A HubSpot Workflow should create work items in Jira |
Connecting several steps
Longer workflows chain the rules together with other Atlassian products.
Jira Service Management requests and HubSpot tickets
A support agent logs a customer request in Jira Service Management, works it, resolves it, and then opens a second browser tab to record what happened in the CRM. The operational detail is captured, but the business context – that this customer has been escalating across several incidents – never reaches the account team.
Two rules close that gap. The first attaches the CRM records when the request arrives. The second turns the agent’s own assessment into a HubSpot ticket.
Trigger | Action | Result |
|---|---|---|
Work item created | The request is linked to the records that already exist in HubSpot: the Contact matched on Email, the Company on Company Name, and the Deal on Deal Name. These are the default unique properties; a rule can match on any HubSpot property marked as requiring unique values instead. | |
Field value changed, on the health score field | A HubSpot ticket is created carrying the score the agent entered, so the account team sees it without anyone retyping it. |
Keeping it to one ticket per request. The article gives three defences against duplicates:
Use Link or Create and Link HubSpot Object rather than Create New HubSpot Object, so the rule looks for a ticket matching the Ticket Name before it creates one.
Make the Ticket Name deterministic – derive it from the request key, not from anything that changes.
Add a condition on the score so the rule only fires at thresholds that matter.
The health score field has to be a type the app can map: Number, Select List (single and multiple choices), Radio Buttons, Short text or Checkboxes. See Supported Property Types.
Full walkthrough: Jira Service Management and HubSpot Tickets: The Two-Trigger Workflow on the resolution blog.