Problem

Customers want approvals started from an Automation rule to be recorded as started by the rule Actor (the account set in the rule details). Today the "Evaluate as" choices are the account the component is logged in as, a selected user, or a user from a work item field.

Change

• New "Evaluate as" option in the Automation action: "Rule actor". It is not offered in the workflow post function.

• With it, the approval is started, archived or deleted as the rule Actor, and that account is shown as the approval starter.

• If the Actor is "Automation for Jira" (the default), the approval shows "Automation for Jira" as its starter. Atlassian never lets an app act as Automation for Jira, so whatever the app would otherwise do as that account (start conditions evaluated as the current user, archive and delete) is done with the app's own access.

• If the Actor is a person, everything runs as that person, exactly as with "Selected user". A person the app cannot act for (someone who has never had access to the app) cannot start an approval whose definition has a condition evaluated as the current user; the run is recorded in Instance errors, as for "Selected user".

• If the rule actor cannot be read at run time, nothing is started, archived or deleted and the run is recorded in Instance errors.

• The existing options and saved rules work as before; the default stays "Account this action is logged in as".

• The documentation page for the Automation action describes the new option (text in tasks/AP-2462-docs.md).

Fixes included

1. When the evaluating account was Automation for Jira or no user at all, the app tried to act as an account it can never act for: archive and delete failed silently for both, and for Automation for Jira start conditions evaluated as the current user failed too. This applied to the existing options, for example a post function set to "User triggering the action" on a transition made by an Automation rule, an anonymous transition, or "User from work item field" holding Automation for Jira. These runs now use the app's own access.

Release order

• Backend on every node before the Forge deploy: a backend without this change rejects a configuration that uses "Rule actor", and an old node that picks up a queued "Rule actor" job drops it.

Acceptance criteria

• A rule with Actor = user X and "Evaluate as: Rule actor" starts an approval shown as started by X, whichever account the component is logged in as.

• A rule with Actor = "Automation for Jira" starts the approval and shows "Automation for Jira" as the starter, also for a definition with a start condition evaluated as the current user.

• Archive and delete with "Rule actor" work for both kinds of Actor and record the Actor as the one who archived or deleted.

• Reopening a saved action shows "Rule actor" selected.

• Existing options ("Account this action is logged in as", "Selected user", "User from work item field") and the workflow post function work as before.

Manual tester notes

• Actor list: global admins can pick any user, project admins only themselves or Automation for Jira, and Jira also offers "User who triggered the event". Check each kind once with Start.

• Person as Actor with a definition that has a start condition evaluated as the current user: works only if that person has used the app (has access); otherwise expect an AUTOMATION instance error "…Condition evaluator couldn't be found".

• Automation for Jira as Actor: the approval's starter in the approvals list, Activity and exports reads "Automation for Jira"; reminders and notifications meant for the starter are not delivered (it has no mailbox).

• Release order: deploy the backend first, then the Forge app; check one existing rule (saved before the release) still runs unchanged.

• Fix 1: a workflow post function "Archive all approvals" with "User triggering the action", on a transition made by an Automation rule whose actor is Automation for Jira, now archives the approvals (before: nothing happened).

• The action keeps answering immediately; failures appear only in Instance errors (type Automation), not in the Automation audit log.