nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Using Smart Values in the Work Flow Post Function

David Frager _gmail_

We have been using JIRA automation to update fields in an issues, and the updates rely on using Smart Values.

lately, we have started to hit limits in the number of Automation Requests, and because of that, our processes are getting disrupted.

We are not ready to jump to the higher levels of JIRA that provide increased automation.

I am looking for alternative solutions.

The Specific Use Case I am trying to address is:

* An issue owner enters a 1 line daily update.

* Automation will get triggered to take that 1 line update, pre-pend date / time / User Name and then add it to the top of a read-only field that has the full list of updates.

It would be great if this could be handled within the workflow post function, however, Smart Values are not supported.

Accepted answers

All comments

Vladislav Tsaregorodtsev

If I am not mistaken, the post-function requires a transition. Do your issues transition to another status when the automation adds the values entered by the user?

Does your automation run every time the value is added or does it run once a day? If it runs every time, maybe you could consider changing it to run daily (for example at 00:00). It should save you some automation executions.

Tomislav Tobijas

Hi @David Frager _gmail_ ,

I know that some of our clients lean toward buying a Marketplace app (e.g., ScriptRunner or JWME) if they want to reduce the number of automation executions, as these apps can do the same thing while there's no execution limit. 👀
Still, that's an additional cost, as you need to actually buy the app.

As you're looking for something related to workflows (which would require user to actually trigger some kind of transition)... Potentially, you could explore using Trigger agent action if you're able to use Rovo/AI. Basically, you could built an agent that would do all of those things you require and it would be triggered on workflow transition.

This would still be relatively experimental but should be fairly easy to build.

Apart from that, you could try out this as well > Build custom Forge apps in Rovo Studio - no code required! > Pretty much build your own 'app' that would handle these things, even without the need for a manual workflow trigger. 🤔

Note that all of this, related to AI, is subject to change. Meaning, potential limitations on tokens, usage, etc., will be applied, so while it might work now, you'll have to deal with it at some point.

Cheers,
Tobi

Rilwan Ahmed

Hi @David Frager _gmail_ ,

Optimizing your existing Jira Automation Rules would give relief for some extent in your case.

If you prefer to keep your current Jira Automation setup, you can drastically reduce execution consumption by :

Scope Rules to Single Projects: Multi-project or Global rules consume your global monthly execution quota faster. Single-project rules often have higher or separate allowances depending on your plan.
Use Workflow Transition Triggers Instead of Field-Value Changed:
- A Field Value Changed trigger runs every time an issue edit event occurs, which can accidentally trigger multiple runs.
- Change the trigger to Issue Transitioned (or a dedicated transition button) so the rule executes only when explicitly submitted.

Andrey - Guenov Labs

Smart values are only available inside Automation actions — they were never wired into native workflow post functions (Cloud or Server/DC), so that path is a dead end regardless of plan tier. A few ways to keep this working without eating more Automation executions:

Cut your execution count before anything else. Two common ways teams accidentally multiply executions on a rule like this: having a separate rule per project/issue type instead of one rule with branches (each separate rule execution counts on its own, even for the same trigger); or an extra JQL/lookup-issues condition on top of the trigger, which adds an execution per match rather than per fire. If your rule has an "additional search" step you don't strictly need, dropping it alone can meaningfully cut usage.
If you want this fully off Automation's quota and can't move plan tiers, the standard route is a Marketplace app that runs its logic as a workflow post function with its own execution engine — untouched by the Automation allowance. JMWE (Jira Misc Workflow Extensions) has a "Set field value" post function that supports templated/computed values (you can build a "{date} {user}: {text}\n{existing value}" style prepend) — probably the closest drop-in for what you're describing. ScriptRunner for Jira gives you a custom script post function where you write the concatenation directly in Groovy, also running synchronously in the transition rather than through Automation.
If the field update should fire on every issue update rather than a specific transition, scope the trigger tightly to just the 1-line update field ("field value changed") rather than a broad "issue updated" trigger — that mismatch is a common silent cause of blowing through the monthly cap.

Worth checking #1 first — it's free, takes ten minutes to verify in the rule's execution log, and is a more common cause of hitting the cap than people expect.

David Frager _gmail_

The automation is properly scoped. I am currently investigating work flow extentions.

thanks

David Frager _gmail_

thanks...we will investigate this option

David Frager _gmail_

in the case i am working on currently, the automation is based on transitions.

i have considered more of a batching of these requests, which would be possible, however, i was holding off this as a last resort.

Using the extended workflow plugin or rovo would be a more ideal solution

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

cloud

jira-cloud

jira-server