Additional information to show in Audit Log:

• Automation audit log doesn't show much information for permission errors. The automation fails when the Actor of automation does not have adequate permission against the space, page or blog. Especially when the scope is set to Global (All spaces), you'll encounter this issue more frequently. The automation state becomes SOME ERRORS but there is no way to find out why.

• Add a brief overview of rule executions in the past 90 days under the rule's audit log, containing the total and how many successful/failed executions
• on rule details, I can select an option for verbose audit logging
• the default value of verbose audit logging is disabled
• when verbose audit logging is enabled, details of component process are logged the same as if the debug qualifiers were added
• when verbose audit logging is enabled, all issues acted upon in the rule are logged.  (currently triggers, branches, etc. truncate the display of information logged which is available to Jira users)
• bonus: audit log list provides a visual indicator that verbose information is available without the need to expand the log entry display
• Add more details for the error on the Automation Audit logs instead of Generic error message(Internal server error)
• When the event that triggered the rule happened on the issue to track delays.

Reduce confusion from misleading Audit Log messages:

• Automation's Edit Issue Action registers in the Audit Log as Successful even if it didn't actually change the Issue: Have it represent what actually results from the action
• Change the message error "Inactive user" in the Audit Logs to be more accurate - At the moment, the lookup of a user picker field is by ID and not text, so when a rule tries to populate the field A4J shows a message saying "Inactive user" even if the user is active. That said, changing the message error in the Audit Logs to be more accurate such as "You can only populate a user picker field by ID".
• Change the language in the Issue view that could potentially say “No rules run in the last 90d” instead of “No executions recorded against this issue yet”, which could be factually incorrect
• The automation rule to clone issues throws the following error message even when the issue was cloned successfully and the problem field skipped:
  Unknown fields set during clone, they may be unavailable for the project/type. Check your custom field configuration. Fields ignored -
  Description (description)
• When an automation that has an edit action needs to edit a field value, but this field already has the value that the automation was supposed to add, the automation audit log shows that the issue was edited, but the issue's history doesn't show any update. It makes the status misleading and hard to identify whether it was a problem with the automation rule logic or something else. Adding a new status block in the automation audit log like Issue already has this value would help.
• When an Automation rule fails due to API rate limiting, a generic error is logged relating to the automation rule action, this leads a user to suspect an issue with the rule or to question it's intermittent operation with support. We should log that a rule failed due to Atlassian API rate limiting and the endpoint in question so that it's clear why the failure occurred, the customer can then take the appropriate action to reduce usage. This should be described in such a way that it is easy to distinguish from Automation rule execution limits. 

Other suggestions

• Some customers would like to have the ability to go back in their usage history for global and multi-project automation executions further than the 90 days available at the moment to be able to retrospectively analyze the data.
• It could also be helpful to include the ability to export the data in some way for the customer to process it as they see fit.

Business case:

While automation for Jira continues to evolve and improve, the documentation and knowledge of this feature is still growing.  Thus rule development and validation is often a trial and error process.  Providing a built-in mechanism for verbose audit logging will help rule writers accelerate their writing by eliminating the need to add/remove individual actions for logging or debug qualifiers.  This new feature would also reduce errors which could occur when the removal of manual logging is done.

Scenarios where more info needed in Audit Log:

• Errors in Send Email action in Automation rules audit log should inform the key of affected issues
• Add trigger issue key to the audit log when the rule is throttled

Notify users when rule is failing

We could add more detail in these areas:

• Automation audit log usage tracking available for more than 90 days
• Display issue keys in audit logs without having to click on 'Show more'
• Provide an information on an automation name in the audit log / issue history
• Provide proper audit log for Automation rule blocked by IP Allowlist
• Lets log the actual value that the compare condition failed against - May need to protect this with a checkbox for security reasons (don't want to store sensitive information in the audit log).
• Deep link audit log entries for rule failed emails
• Add audit log entry when rule is auto disabled due to failures -
  When there are 5 (or more) failures for SLA rules, 10 for others, the rule is automatically disabled. When this happens an entry should be added to audit log to avoid confusion.
• Audit log should link to other audit logs if triggered by another execution -
  For complex flow of rules, we should allow people to navigate through the related (trace id?) executions and trace where the rule is triggered from
  POssibly even have a special view to give an overview of where things have flowed to
• Log the initiator of the rule in the audit log - For manual and event based triggers. (scheduled are a bit special here)
• Improve fields not on screen audit log error - Lets include a link to docs page with permission & where is my field helper. This keeps coming up in support all the time. (edit failing with this error)
• Log manual schedule executions differently to scheduled execution - For the 'Scheduled' trigger we should log a message in the audit log when the rule was triggered manually by hitting the 'Run Schedule' button.
• Improve permission error around field editing - Maybe just a minor suggestion, if the error indicated in the audit log can be clearer for this case, for example if it states that “The actor of the rule does not have permission to perform the action on the tickets due to permission right”, instead of indicating that “No fields or field values to edit for issues (could be due to some field values not existing in a given project)”
• Add audit message for ignored/unknown values in issue fields - We need to pass in the auditItemBuilder so the fields can add an error. e.g. trying to set an unknown version, or a rendered value is unknown.
• Improved error messaging on create action, e.g. better job with field screen error messages and validation, log status code when action fails with no error -
  • This is the error in the audit log: Unknown fields set during create. Field may not be on Create screen for project/type. Fields ignored -
    labels. We could perhaps to do some linking to the right screen and or perform validation in the create/edit/transition issue action if we know the project/issue types.
  • consider adding suggesting a workaround in the Cloud error message when a field isn't on the screen
• _____
  • Create action occasionally fails with no error message
    Occasionally when creating/transitioning an issue, the JIra Cloud API may fail with a 403 and return an HTML snippet like:

    <html>
    <head>
        <title>Forbidden (403)</title>

    This will get logged as "Error creating issue" with no extra information, since the response isn't in a valid JSON format.

• Provide more details on the Send email action - such as to which domain of email addresses the email was sent for security audit if it was sent to non-Jira users or external users. 
• Provide more details for the Clone issue action: Currently, when cloning issues with required fields or fields expected to have values that are missing, the audit log only displays a generic message, such as: "Error creating issue: Bad Request (400). Issue was created successfully, however, some unexpected errors occurred". It would be beneficial if the log included specific reasons for the error, allowing for more efficient troubleshooting and resolution.

Fixes

We should:

(1) Ensure that the at least the status code gets logged in the AuditLog to provide some guide as to what the the underlying problem might be.
(2) Somehow workaround / work with Atlassian about the cause of the 403. Raised with Atlassian at https://ecosystem.atlassian.net/servicedesk/customer/portal/14/DEVHELP-2916

Customers are complaining about the error icon besides the rule name when the execution goes wrong.
They want to clear the audit logs in order to have this error icon cleaned whenever they like to.

There are scenarios when the rule is not executed however the audit logs shows success.

In such cases if rule is not executed, the audit log should report 'no actions performed' or something similar instead of 'success' message.

If branches find no issues rule should report "no actions performed" -

If a rule does not perform any actions because branches do not find any related issues, the rule should report no actions performed, rather than success.

It might be nice for JQL branches to also log the JQL that was executed if no issues were found to help with debugging.

Audit logs in the "Recent executions" should only should only show rules that ran - By default, we should filter out "No actions performed". Doesn't make much sense to show rules that didn't actually run against the issue

While you’re here would be good to be clear to the user that we’re showing the last 8 executions (sometimes people think that this is all the executions). So if list size == 8 then show a helper text

___________

Ability to access full audit item - At the moment we truncate lots of items but sometime it is useful to see the complete list of issues.
There should be an option to load these.