組織で通常使用される問題検証用のルーティングを、個々のユーザーやグループ全体でオーバーライドできるようにすることが可能です。たとえば、報告した問題が修正されたかどうかをユーザーが確かめたい場合もあるでしょう。
このようなオーバーライドを許可するには、[問題検証の優先設定] 権限をユーザーやグループに付与します（その手順については、「ユーザー アカウントの管理」や「カスタマイズ権限」の説明に従います）。このセキュリティ権限があれば、ユーザーは [優先設定] ページ（[設定｜優先設定]）から、以下の 3 つの戦略のいずれかを選択することができます。採用できる戦略は以下のとおりです。
• [常に標準のルーティングを使用する] ： 検証用の標準ルーティング。問題は適切な QA 用受信箱に送られます。
• [常に自分の問題を検証する] ： ユーザーが提起した問題を通常の QA 用受信箱ではなくユーザー自身の受信箱に送って検証するように指定します。
• [新規の問題ごとに指定する] ： 問題が報告されるたびに、通常のルーティングをオーバーライドするオプションをユーザーに提示するように指定します。
問題の再割り当ては、この章で説明した自動ルーティング メカニズムをオーバーライドする手動ルーティングの手段の 1 つです。ユーザーは明示的に再割り当てアクションを取って、問題を別のユーザー（通常は同じグループ内のユーザー）の受信箱に送ることができます。たとえば、開発者 Bill はこれから休暇を取るので、開発準備完了状態のバグを同僚の開発者 Dan に再割り当てするといった場合です。このバグは開発準備完了状態のままですが、再割り当てされています。
再割り当てされた問題がワークフローにおける以前の状態に戻ったとき（たとえば、Dan がバグ修正を却下した場合など）、Issue Manager はその再割り当てを記憶しておき、後で、その問題が当初送られた受信箱（上記の例では Bill の受信箱）ではなく手動で送られた受信箱（同じく Dan の受信箱）に問題を戻します。
例
再割り当てがいかに効率的に動作するかを理解するために、ある例について考えます。この例では、バグが 2 回（開発準備完了状態のときに 1 回、QA 準備完了状態のときに 1 回）再割り当てされ、QA エンジニアがバグ修正を却下して、バグをワークフローにおける以前の状態に戻します。
1 新しいバグが開発準備完了状態でワークフローに入ります。ルーティング ルールにより、このバグが開発者 Bill の受信箱に自動的に送られます。
2 Bill は、このバグを開発者 Dan の受信箱に再割り当てします。
3 Dan はこのバグを修正した主張し、その結果、バグが QA 準備完了状態に移行します。
4 ルーティング ルールにより、このバグが QA エンジニア Mike の受信箱に自動的に送られて検証を受けます。
5 Mike は、このバグを同僚の Sarah の受信箱に再割り当てします。
6 Sarah は修正結果を却下し、その結果、バグが開発準備完了状態に戻ります。
7 Issue Manager は、この開発準備完了状態のバグを Dan の受信箱に送り返します。その状態のバグを最後に処理した開発者は Dan だからです。
8 Dan はこのバグを再度修正し、QA 準備完了状態に戻します。
9 Issue Manager は、この QA 準備完了状態のバグを Sarah の受信箱に送り返します。その状態のバグを最後に処理した QA エンジニア開発者は Sarah だからです。
機能強化されたルーティングがなければ、開発準備完了状態の問題（ステップ 7）は Bill の受信箱に送られ、そのあと Bill が問題を再度 Dan に再割り当てしているでしょう。同様に、QA 準備完了状態の問題（ステップ 9）は Mike の受信箱に送られ、そのあと Mike が問題を再度 Sarah に再割り当てしていることでしょう。