Jira - Limit Projects and Types for Tickets

Apps HubSpot Native Apps
1

We’d like to be able to create certain Jira issues from a support Ticket. The Jira app allows us to do that but we want more control over:

  • What Projects a ticket can be linked to
  • What Issue Types a ticket can be linked to

This would be helpful for us to prevent our support staff from accidentally creating the wrong type of issue or in the wrong project since we want all support ticket issues to be in a specific Jira project.

We’d need to use a paid Jira account to limit what projects the connected Jira user has access to, which we’d prefer not to do since we don’t currently need it for our development team. Even if we did that, I don’t think we’d be able to limit the Issue Type.

We’re also planning on figuring out how to use a work flow to create a Jira Issue by having our support staff submit a custom form on HubSpot, so if anyone has experience with that it’d be helpful.

2

Hi @GSneed

Thanks for sharing the details — that’s a frustrating experience, especially when everything looks correct in the CRM but not in the Chrome extension.

I’d like to bring a few Community members into the conversation who are familiar with the HubSpot Chrome/Gmail extension and property visibility rules.
@MDittrich @seosiri @TomM2 — hope you’re all having a great week! Have you seen cases where custom contact properties don’t appear in the Gmail extension toolbar, particularly on the Free plan? Any clarity on plan limitations, supported property types, or extension-specific settings that could explain this would be really helpful.

Appreciate any guidance you can share.
Victor

3

You’re right that the native Jira app gives limited control. To prevent mistakes and avoid a paid Jira user, consider these options:

1) Middleware / Automation (Recommended)

Use tools like Zapier, Make (Integromat), Workato, or Power Automate to create Jira issues from support tickets.

Hard-code the Jira Project and Issue Type

Map only allowed fields

Trigger only from specific ticket pipelines, tags, or form submissions

This fully prevents creating issues in the wrong project or type.

2) HubSpot Form → Workflow → Jira

Create a custom HubSpot form for support → trigger a workflow → send data to Jira (via webhook or automation tool).

Support staff never see Jira project/type options

You control everything in the workflow logic

Clean, auditable, and scalable

3) Jira Automation Rules (Partial Control)

Use Jira Automation to:

Auto-move or block issues created outside the target project/type

Or auto-convert them to the correct setup

This helps, but doesn’t fully prevent mistakes at creation time.

Best practice

:backhand_index_pointing_right: Use HubSpot form + automation tool to create Jira issues in one fixed project with one fixed issue type. This provides full control without requiring Jira account upgrades and maintains support workflows as simple as possible. Glance: :link: HubSpot docs on installing & using the Jira integration — includes creating Jira issues from HubSpot tickets:

:backhand_index_pointing_right: Connect HubSpot and Jira

@Victor_Becerra, thanks for notifying

4

We ended up creating a manually triggered workflow to create an issue with our desired project and type and added the enroll in workflow action panel to tickets. As a note on effective use, we also made it unenroll if the Jira issue ID is known, to prevent submitting the same ticket multiple times.

We haven’t set up the forms yet for more complex issues that need specifics filled out, but this is a great first step.

5

Great approach—manually triggering the workflow while adding safeguards like unenrolling once the Jira issue ID is known is a smart way to prevent duplication and maintain clarity.

Starting simple and planning to layer in forms for more complex cases later is exactly how scalable systems are built. Stay updated with new implementations and integrations—because a flawless environment helps build a great workspace. :rocket:

#NeverGiveUp