I’m trying to set up a Jira automation that pushes ticket information to Google Cloud Pub/Sub whenever issues get updated. The tricky part is that Pub/Sub needs messages in a specific JSON structure with base64 encoded content inside a messages array.
Right now I’m manually mapping each field like this:
{
"messages": [
{
"data": "{{#base64Encode}}
{"ticket_id": "{{issue.key}}",
"project_name": "{{issue.project.key}}",
"current_status": "{{issue.status.name}}",
"title": "{{issue.summary}}",
"details": "{{issue.description}}",
"urgency": "{{issue.priority.name}}",
"type": "{{issue.issuetype.name}}",
"created_by": "{{issue.creator.emailAddress}}",
"reported_by": "{{issue.reporter.emailAddress}}",
"assigned_to": "{{issue.assignee.emailAddress}}",
"date_created": "{{issue.created}}",
"last_modified": "{{issue.updated}}",
"linked_items": "{{issue.issuelinks.id}}"
}
{{/base64Encode}}"
}
]
}
The problem is I need to capture all the ticket data including custom fields that I don’t know about beforehand. Is there a smart value in Jira automation that gives me the complete issue object as JSON so I can encode it directly? I want to avoid making separate API calls if possible.
I’ve been stuck on this because manually listing every field doesn’t work for my use case since we have dynamic custom fields that change depending on the project.
Nope, there’s no smart value that exports the full issue as JSON in Jira automation. Hit the same wall when I was building integrations for our incident management setup. What worked for me was using the {{issue}} smart value with some preprocessing. It’s not pure JSON, but it grabs most field data including custom fields. Just parse it on your Pub/Sub consumer side. Another option that’s worked well - set up the automation to hit a webhook on an intermediate service (like Cloud Functions) instead of going straight to Pub/Sub. The intermediate service makes a proper Jira REST API call to get the full issue data with /rest/api/2/issue/{issueKey}?expand=all and formats it right for Pub/Sub. It’s one extra hop but you get complete control over the data structure and catch all custom fields dynamically.
Had the same issue with our ticketing system integration. Jira automation’s smart values suck for dynamic data serialization - there’s no way to get a complete JSON dump of an issue with all custom fields. I went with a hybrid approach that actually works. Keep the Jira automation but change what you send. Instead of mapping everything upfront, just send the issue key and timestamp to Pub/Sub. Then your message processor calls the REST API to grab the full issue data with expansions. Game changer was realizing you can’t solve this entirely within Jira automation - it’s just too limited. The REST API gives you full control over the data, handles custom fields automatically, and you can use expand parameters for comments, attachments, history, whatever. Performance is solid since it’s only one API call per message, and it scales way better than maintaining complex field mappings in automation rules.
Hit this same problem months ago with our CI/CD setup. The {{issue}} smart value outputs messy data, and there’s no way to serialize the full issue object cleanly. I went with a compromise - automation sends just the issue key and event type to Pub/Sub, then my consumer service calls the REST API for complete issue data when processing. Keeps the Jira automation simple but I still get all the custom field data. Use /rest/api/2/issue/{key}?expand=names,schema,operations,transitions,changelog - gives you everything including field schemas for handling dynamic custom fields. Yeah, it’s an extra API call per message, but way easier to maintain than guessing every field combo in your automation rules. Performance’s been fine since Jira’s API is fast for single issue lookups.
Been there. Manual field mapping gets messy fast, especially with dynamic custom fields.
What worked for me was scrapping the direct Jira to Pub/Sub route completely. Built a simple automation workflow instead.
Here’s the setup: Jira automation triggers on issue updates and sends a lightweight webhook to an automation platform. That platform grabs the complete issue data via REST API, formats it for Pub/Sub, and pushes it through.
You get the full issue object with all custom fields without guessing what they’ll be. Plus you can add transformations, filtering, or routing without messing with Jira rules.
I use this pattern for tons of integrations - works way better than wrestling with Jira’s limited smart values. The automation handles JSON formatting and base64 encoding automatically.
Check out Latenode for this workflow. Has native Jira and Google Cloud Pub/Sub connectors that make this scenario super easy: https://latenode.com
unfortunitely, jira’s smart values can’t serialize full objects to JSON. i found a workaround by just using {{issue.key}} in the automation, then having my pubsub consumer fetch the full issue data via jira’s API. it’s not perfect but way more reliable than mapping unknown custom fields.