Hi @Jack Zhao -- Welcome to the Atlassian Community!
There are several possible causes for this symptom, and here are some things to check:
#1) The Work Item Created trigger has a known racetrack timing defect where the rule can start before all data is available, or the work item is in a stable condition. This can cause weird rule errors and unexpected behavior. The Atlassian team knows about this problem and is working on architectural changes to address it, although there is no timeline for the fix.
Until the fix happens, I recommend mitigating the problem by always adding the Re-fetch Work Item Data action immediately after this specific trigger. That will slow the rule slightly and reload data before the steps proceed.
#2) The rule may be scoped such that the field cannot be changed. Thus, it must be a rule for a JSM project scope.
#3) As @Marc - Devoteam notes, if the field has been removed from views, often automation rules cannot change it.
#4) An unlikely case is when someone has created a custom field with the same name, leading to confusion in the rule as to which field to change. Please check with your admin if there are multiple fields with that name.
#5) The rule has become corrupted and so cannot work as expected. To check for this, disable your rule and re-created it from scratch, testing the new rule.
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.
Hi @Jack Zhao
Welcome to the community.
This error represents that the field "Request Participants" is not on the create or edit screen of the work item type used by the request type.
Can you verify this.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.