JIRA Automation is not Retrieving Story Points

Question

Hello Folks, My goal is to create a Sprint Hygiene Report using JIRA Automation for an ACTIVE sprint ( a sprint which is started and currently in progress). Following is the structure of the automation - 1. Automation Name - Hygiene Report Publisher 19 2. Trigger - Schedule: Fixed Rate of every* 1 Days - run a JQL search and pass results to subsequent conditions and actions JQL : project = AND sprint in openSprints() 3. LookUp Issues Action JQL: project = AND sprint in openSprints() AND component in ("ComponentName") AND Sprint is not EMPTY AND issuetype in (Story, Task, Bug) and Sprint is not EMPTY ORDER BY key 4. Send Email Action To: my-email@abc.com Subject: JIRA Hygiene Report - {{sprintName}} Content: Hi All,

{{#lookupIssues}}{{/lookupIssues}}

Key	Issue Type	Summary	Status	Story Points
{{key}}	{{issuetype.name}}	{{summary}}	{{status.name}}	{{#if(equals(customfield_11483, ""))}} Not Pointed {{/}}{{#if(not(equals(customfield_11483, "")))}} {{customfield_11483}} {{/}}
Total Ready				{{lookupIssues.customfield_11483.sum}}

--- The above automation has the following issues (ranked in priority of importance) 1. The contents doesnt not retrieve story points (numerical values) even when the jira (story/bug/task) is assigned with story points. And the "Story Points" name is populated as "Not Pointed". The automation reads story points as empty and hence marks it as "Not Pointed". 2. Sprint Name appears blank in the subject line. Appreciate any leads on solving the above challenges. Thank you in advance!

Andrey - Guenov Labs · Answer

Hi Swapnil — I think the story points problem has a different cause than a wrong field ID, and it's worth checking before you spend time on the ID. 1. Lookup Issues doesn't return custom fields. The Lookup issues action exposes a limited, fixed set of fields, and custom fields aren't in it — so {{customfield_11483}} inside {{#lookupIssues}} renders empty regardless of which ID you use. There's a long-standing open request to widen it (JIRAAUTOSERVER-877). Verify in 30 seconds: add a Log action with {{lookupIssues.first.key}} / {{lookupIssues.first.customfield_11483}} If the key prints and the custom field is blank, that's your cause. Two ways round it: * Branch instead of lookup. Replace the Lookup Issues action with a Branch rule / for each → JQLbranch. Inside a branch you're on a real issue, so every field including custom fields resolves. Downside: you can't easily build one table from a branch, since each iteration is its own scope. * Fetch the data yourself. A Send web request to the search endpoint with fields=key,summary,status,issuetype,customfield_11483, then iterate {{webhookResponse.body.issues}} in the email body. More setup, but you get every field and full control of the table. 2. Your empty-check won't fire the way you expect. An unset numeric field is null, not "", so equals(customfield_11483, "") isn't a reliable test. You can drop the whole if/else pair and use the default-value pipe: {{customfield_11483|Not Pointed}} That prints the value when there is one and Not Pointed when there isn't. 3. You're probably sending yourself a lot of duplicate emails. Your Scheduled trigger has "run a JQL search and pass results to subsequent conditions and actions" ticked, and you have a separate Lookup Issues action. The trigger's JQL makes the rule execute once per matching issue — so if the sprint has 40 items you get 40 identical emails a day, and 40 executions against your monthly limit. Untick the JQL box on the trigger so the rule fires once, and let Lookup Issues do all the fetching. 4. Sprint name. Right that {{sprintName}} isn't a smart value. One caution on the replacement: sprint is a list — an issue carries every sprint it's ever been in — so .sprint.name renders them all comma-separated. Use: {{lookupIssues.first.sprint.last.name}} (and note this has the same custom-field caveat as #1 if lookup doesn't return sprint data on your instance — the branch or REST route sidesteps it). One thing worth confirming: the thread is tagged Cloud, but your issue link points at jiradc-awm... — is this actually Data Center? It changes the answer materially: the REST paths differ, and the Lookup Issues field limitation is stricter there. Happy to adjust if you can confirm which one you're on.

Habib__Plugio__ · Answer

Hi @Swapnil Two separate causes here: Story points showing empty — first verify customfield_11483 is actually the field holding the values: open https:///rest/api/2/issue/?fields=customfield_11483 in a browser for an issue you know is pointed. If it returns null, you're referencing the wrong field — instances commonly have multiple story points fields (on Cloud, "Story Points" and "Story point estimate" are different fields depending on project type). If REST does show the value but the email doesn't, and you're on Data Center, older Automation for Jira versions return only a limited field set from Lookup Issues — add a Log action with {{lookupIssues.first.customfield_11483}} to confirm. Blank subject — {{sprintName}} isn't a smart value, so it renders empty. Since your JQL already scopes to open sprints, use {{lookupIssues.first.sprint.name}} instead. Hope this helps.