I have an automation that calculates the time to resolution for a project, and the automation works perfectly. However, there is an exception with tickets created from another automation that creates scheduled tickets. In other words, if I create a ticket manually, the time to resolution automation works perfectly. But, if the ticket is created from another automation that makes scheduled issues, the time to resolution does not function correctly. Do you have any ideas on how to fix this issue?
This is the automation that calculates the time to resolution:
And this is one of the automations that when a ticket is created from it, the time to resolution does not work:
Thanks in advance
Hello Daniel Bermudez,
Can you u please tell me which type of custom field is "Time to Resolution" weather Number,Text,Date and Time.
Please can u specify us.
Regards
Preeti
Please post images of the audit log details for your rule which calculates the time to resolution, showing an example of when the rule works as expected and when it does not (e.g., for an issue created by your other, scheduled trigger rule). Those may help explain what you are observing.
Until we see that information...
What is used to create the variable NumberOfminutesToResolveCPP? Seeing that information may help explain what is different about the issues that causes them not to work as expected?
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is the rule that we use for the variable:
And this is the image of the audit log:
The issue CCP-741 was created by myself and it works without any problem:
But the CPP-740 was created with the automation and it does not work:
As you can see here, the time to resolution for CPP-740 is empty
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You appear to have a custom field named Start_Date_First_Response.
If that correct, I hypothesize the value of that field is set by another automation rule.
If that is also correct, it is possible the symptom is caused because the actions of one rule (the creation of the issue by the scheduled trigger rule) are not trigging your rule to set the custom field...and so the later calculation of the time to resolution uses a null value.
By default, the actions of one rule cannot trigger other rules. This is to prevent errors and run-away conditions. When you want a rule to trigger another, you may enable the option "Allow Rule Trigger" in the details of the downstream rule.
Thoughts?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes thats correct, we have this automation also:
So what you are saying is that I need to allow this option?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, that is the option. Please try enabling that, and...
For a rule triggered on Issue Created, I recommend always adding the Re-fetch Issue immediately after that trigger and before any other steps.
That trigger can fire so quickly the issue data is not yet available, leading to unexpected results and weirdness in the remaining rule steps. The Re-fetch Issue action will slow the rule by about one second and reload the data before proceeding with the other steps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This one, to re-load an issue during the rule execution: https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Re-fetch-issue-data
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Oh ok I see... but how do I add the re fetch issue? sorry for the confusion
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
In your rule triggered on Issue Created, add the Re-Fetch action just after that, and before the Edit Issue fields to set the custom field.
Back to your original question: have you tested enabling the option for "Allow Rule Trigger" to see if that helped?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello, it worked perfectly! Thank you very much
Addionally I had to add this CF to the screen because without that the automation was showing an error.
Is there a way to hide this CF? It is because our client does not need it to be visible, but the CF is needed for the automation to work, so idk what can I do, any ideas?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am glad to learn that helped!
Regarding field visibility, that is an unfortunate need for custom fields to be editable by rules. An alternative is using an entity property as that would not need to be visible for rules to access it. How are you using that field such as in reporting? That may impact if using entity property would work. Please look here to learn more:
https://developer.atlassian.com/cloud/jira/platform/jira-entity-properties/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.