Auto Assign configuration

When an issue reaches a status, hand it to the right person automatically. "A bug moves to testing, the QA lead picks it up", without anyone having to remember. Rules live per project, or in named sets you attach to many projects at once so one edit changes them everywhere.

A rule never overrules a person. If the same change that moved the status also set an assignee by hand, the manual choice stands.

On RedminePRO Cloud

Availability

Business and above.

Turn it on

Per project: Project → Settings → Modules → tick Auto Assign. An Auto assign entry then appears in the project menu for whoever holds the permission below.

Permissions

Administration → Roles and permissions, in the Auto Assign section:

Nobody needs a permission for rules to apply — they are part of how the project works, not something a person invokes.

Settings

None workspace-wide. Everything is configured per project, or in the shared rule sets at Administration → Auto assign.

Using it

1. Enable the module on the project and open Auto assign in its menu.
2. Add a rule: pick a tracker (or All trackers), the status that triggers it, and Assign to.
3. Assign to accepts a specific person or group, or one of the automatic choices — Author (whoever reported it), Previous assignee, or Nobody (clear the assignee).
4. A rule naming a specific tracker beats a rule for All trackers on the same status, so you can set a general rule and carve out exceptions.
5. Copy rules from another project brings an existing set over as a starting point.

Rule sets are the way to run one policy across many projects. Administration → Auto assign → New rule set. Attach a set to a project from that project's rules page; its rules then show as Inherited from a rule set. A project's own rule for the same tracker and status wins, and the inherited one is shown as overridden by a project rule so you can see what is happening rather than wonder.

Sets are referenced, not copied: editing a set changes every project using it, and Used by tells you how many that is before you edit.

Rules apply wherever an issue is saved — the issue form, inline editing, a board drag, a bulk edit and the API — because the rule runs at the model, not in one page's code.

Troubleshooting

Nothing was assigned. Check the module is on for the project, that a rule matches this tracker and status, and that the same save did not also set the assignee by hand — a manual choice always wins.

The wrong rule fired. A rule naming the tracker beats one for All trackers. Look for a more specific rule on the same status.

A project rule is being ignored. It is not — a project rule beats an inherited one. The inherited row is marked overridden by a project rule.

A rule shows (deleted). Its target person, tracker or status no longer exists. The rule stops matching rather than assigning to nothing; edit or delete it.

Editing a set changed several projects. That is what a set is for — sets are referenced, not copied. Used by shows the count before you edit.