メインコンテンツにスキップ

承認ワークフロー: 管理者ルール

セットアップルール、柔軟な設定オプション、提出後のパラメータロック、およびプロジェクト設定の変更がアクティブな承認リクエストに与える影響について説明する管理者向けガイド。

対応者:Sjaak Velthoven

※この記事は全文機械翻訳されています。

 

承認ワークフローは、プロジェクト内の共有ドキュメント revision に対する構造化されたレビューおよび検証プロセスを確立します。

ワークフローの設定には、将来のレビューリクエストに対するテンプレートルールとアクティブな進行中の承認を推進するプロジェクトチームセットアップのバランスが必要です。

 

注: プロジェクト管理者のみがワークフロー設定にアクセスし、新しい承認ワークフローを作成し、既存のワークフローパラメータを変更できます。

 

この記事では、以下のトピックについて説明します。

 

この記事では次のトピックについて説明します:

 

 

1. プロジェクトの変更が承認ワークフローに与える影響

ワークフローテンプレートが変更されたり、プロジェクト設定が調整されたりすると(プロジェクト設定でチームメンバーを追加または削除するなど)、変更は今後のリクエストと進行中の承認リクエストに異なる影響を与えます。

 

1.1 ワークフローテンプレートの編集

ワークフローテンプレートに加えた変更(送信者チームの追加など)は、更新後に作成された今後の承認リクエストに適用されます。

既に進行中のアクティブなリクエストの構造を書き直すことはありません。

 

1.2 チームメンバーシップの更新

プロジェクト設定でチームメンバーを追加または削除すると、アクティブな進行中の承認に直ちに反映されます。

レビューステップがチームが空であるため停止している場合、そのチームにユーザーを追加すると、すぐにそのユーザーがレビューを再開できます。

 

1.3 依存関係の破損

ドキュメントステータスをアーカイブしたり、チームを削除したり、プロジェクト設定内の他の場所で承認トピックテンプレートをアーカイブしたりすると、ワークフロー更新を保存するときに検証エラーが発生したり、進行中の承認でのトピック作成が停止したりする可能性があります。

 

 

2. 提出前セットアップ(初期作成)

新しい承認ワークフローを初めて作成する場合、テンプレートを保存して有効化する前に、すべての基本的なパラメータを設定する必要があります。

 

このセクションでは次のトピックについて説明します:

 

 

2.1 必須フィールドと提出前警告バナー

新しいワークフローを保存しようとするときに必須フィールドが不完全な場合、システムはページの上部に提出前警告バナーを表示し、テンプレート作成をブロックします。

必須フィールドは以下の通りです。

  • 2.1.1 ワークフロー名
    ワークフローの一意で説明的な名前。

  • 2.1.2 送信者チーム
    承認リクエストを開始するために割り当てられた少なくとも1つのプロジェクトチーム。

  • 2.1.3 レビューステップ
    割り当てられたレビュアーチームと少なくとも1営業日の期間を含む、少なくとも1つのレビューステップ。

  • 2.1.4 最終承認
    割り当てられた最終レビューチームとともに2つのアクティブなプロジェクトドキュメントステータス(承認された revision 用に1つ、拒否された revision 用に1つ)。

 

2.2 システムの制限とチームメンバーシップルール

2.2.1 パイプラインの制限

単一のワークフローは、最大10個の連続したレビューステップとパイプライン全体にわたる合計20個のレビュアーチームをサポートします。

 

2.2.2 チーム選択対メンバーの有無

初期作成時に、システムは送信者、レビュアー、および最終レビュアーチームが選択されていることを検証します。

ただし、これらのチームに実際のメンバーが含まれているかどうかはチェックしません

 

2.2.3 実行要件と自動承認

承認リクエストを開始から終了まで完了可能にするには。

  • 少なくとも1つの送信者チームメンバーが割り当てられた送信者チームに存在して、リクエストを開始する必要があります。

  • 少なくとも1つのレビュアーチームメンバーが割り当てられたレビュアーチームに存在する必要があります。ただし、そのステップで自動承認が有効になっていない場合を除きます。

  • 自動承認が設定されている場合、空のチームに割り当てられたステップはステップの期日に達すると自動的に承認され進みます。

  • 自動承認が設定されていない場合、空のレビュアーチームはメンバーがそのチームに追加されるまで承認リクエストを停止します。

  • 少なくとも1つの最終レビュアーチームメンバーが最終結果をレンダリングするために存在する必要があります。

 

2.2.4 管理者権限

プロジェクト管理者は自動的な操作上の権限を保有しません。

承認中にアクションを実行するには、管理者が関連するチームの明示的なメンバーである必要があります。

  • 送信者チーム
    承認リクエストを開始するために必要です。

  • レビュアーチーム
    レビュー検証を指示または送信するために必要です。

  • 最終レビュアーチーム
    最終的な決定をレンダリングし、承認を完了するために必要です。

 

 

3. 3. 柔軟な操作(提出前後)

特定の操作は柔軟性を保ち、初期セットアップ中に調整したり、ワークフローがアクティブになった後の任意の時点で更新したりできます。

これらの柔軟な操作は2つの異なるカテゴリに分類されます。

ワークフローテンプレート設定(ワークフローセットアップページで直接編集)プロジェクトチームメンバー管理(すべてのワークフロールールにわたってプロジェクトチームページで編集)。

 

このセクションでは次のトピックについて説明します:

 

 

3.1 3.1 ワークフローテンプレートの変更

これらの設定はワークフロー設定メニュー内でいつでも変更でき、今後の承認リクエストに直接影響を与えます。

 

3.1.1 送信者チーム

管理者は提出後に送信者チームを追加または削除して、このワークフローの下で新しい承認リクエストを開始することが許可されるプロジェクトチームを制御できます。

 

3.1.2 承認トピックテンプレート

特定の結果(承認済みコメント付きで承認済み、または_拒否_)にリンクされた承認トピックテンプレートは、レビュー中のイシュートラッキングを制御するためにいつでも追加、更新、またはリンク解除できます。

 

3.2 3.2 プロジェクトチームメンバー管理(すべてのチームタイプに適用)

個別ユーザーの追加または削除はプロジェクトチームページで実行され、ワークフローテンプレートを編集または再保存する必要はありません。

重要なことに、メンバー管理は3つのワークフロームチームタイプすべてに適用され、アクションを実行できるユーザーに直接影響を与えます。

 

3.2.1 送信者チーム

メンバーを追加または削除すると、新しい承認リクエストを開始するワークフローを選択できるユーザーが変わります。

 

3.2.2 レビュアーチーム

メンバーを追加または削除すると、アクティブなレビューステップにアクセスし、マークアップ/コメントを追加し、ステップ検証表示を送信できるユーザーが変わります。

 

3.2.3 最終レビュアーチーム

メンバーを追加または削除すると、アクティブな承認リクエストに対して最終的な決定をレンダリングして完了できるユーザーが変わります。

 

 

4. 4. 提出後のルールとパラメータロック

ワークフローテンプレートが初めて保存および送信されると、主要な構造パラメータはロックされ、承認リクエスト全体にわたって一貫した評価ルールが確保されます。

 

このセクションでは次のトピックについて説明します:

 

 

4.1 ロック対編集可能パラメータ

4.1.1 ロックされたパラメータ

時間設定、レビューステップ、割り当てられたレビュアーチーム、ステップ期間、自動承認トグル、最終承認チーム、およびマップされた最終ドキュメントステータスは、初期提出後に変更することはできません。

 

4.1.2 編集可能パラメータ

ワークフロー名、送信者チームの割り当て、およびリンクされた承認トピックテンプレートのみが提出後に編集可能なままです。

 

4.2 破損した外部依存関係と解決策

既存のワークフローへのいずれかの提出後編集(タイトルの更新など)を保存すると、テンプレート全体にわたって完全な再検証チェックがトリガーされます。

ワークフロー内で使用される要素が初期作成後にプロジェクト設定でアーカイブまたは削除された場合、解決されるまで再検証は失敗します。

 

依存関係の問題(ブロッカー)

影響とシステム動作

解決策

アーカイブされたドキュメントステータス

マップされたステータスフィールドがワークフローセットアップで空に見えます。公開されたドキュメントはアーカイブされたステータスを受け取ります(打ち消し線で表示)。ワークフロー更新がブロックされます。

ドキュメント設定でステータスを復元(アーカイブ解除)
ロックされたステータスは、提出後にワークフロー内で編集または置き換えることはできません。

削除されたプロジェクトチーム

送信者、レビュアー、または最終承認チームがプロジェクトチームページで削除されました。

送信者チーム
ワークフローを直接編集して、新しいアクティブなチームを割り当てます。

レビュアー/最終チーム
ロックされました。ステップにチームが残らず、自動承認がオフの場合、進行中の承認は永遠に停止します。ワークフローをアーカイブし、ドキュメントを破棄して、新しいワークフローを作成します。

アーカイブされた承認トピックテンプレート

ワークフロー結果にリンクされた承認トピックテンプレートがトピックテンプレートページでアーカイブされました。

トピックテンプレートページでテンプレートを復元(アーカイブ解除)
**または** ワークフローを直接編集して、新しいアクティブな置換テンプレートを選択/追加します。

 

4.3 ワークフローのアーカイブと復元

4.3.1 ワークフローのアーカイブ

アクティブなワークフローを作成メニューから非表示にして、プロジェクトメンバーが新しいリクエストのために選択できないようにします。

 

4.3.2 ワークフローの復元

アーカイブされたワークフローを割り当てられた送信者チームの作成メニューで再度有効にします。

 

 

5. 5. 進行中の承認とチームライフサイクルへの影響

プロジェクト設定またはチームメンバーシップが承認リクエストがアクティブに進行中に変更される場合、システムは特定のルールに従ってアクセス、トピック作成、およびワークフロー進行を処理します。

 

このセクションでは次のトピックについて説明します:

 

 

5.1 チームメンバーの追加と削除

プロジェクトメンバーはプロジェクトチームページでワークフロームチームに追加または削除でき、ワークフロームテンプレート自体を編集する必要はありません。

 

5.1.1 送信者チームメンバー

ユーザーを送信者チームに追加すると、そのユーザーは今後新しいリクエストを作成できます。

ただし、送信者チームメンバーシップは、チームメイトによって作成されたリクエストへの共有可視性を付与することはありません。

提出されたリクエストへのアクセスは、個別の作成者に厳密に個人的なままです。

 

5.1.2 レビュアーチームメンバー

ユーザーをレビュアーチームに追加すると、その時点でそのレビューステップにある現在のアクティブな承認リクエストへのアクセスが直ちに付与されます。

レビュアーチームからすべてのメンバーを削除すると、新しいメンバーが追加されるまでそのステップで進行中のリクエストがフリーズされます。

ただし、そのステップで自動承認が有効になっている場合を除きます。

その場合、ステップの期限が過ぎるとリクエストは自動的に承認され進みます。

 

5.1.3 最終レビュアーチームメンバー

ユーザーを最終レビュアーチームに追加すると、最終承認ステップに達しているアクティブなリクエストに対して最終的な決定をレンダリングするためのアクセスが直ちに付与されます。

最終レビュアーチームからすべてのメンバーを削除すると、ユーザーが追加されるまで最終ステップで進行中のリクエストがフリーズされます(最終レビューステップには自動承認は利用できません)。

 

5.2 5.2 プロジェクト設定からチームを削除

削除されたプロジェクトチームは復元できません。

ワークフローに割り当てられたチームがプロジェクト設定から削除された場合、操作上の影響はワークフロームライフサイクル内のチームの役割に応じて異なります。

 

5.2.1 削除された送信者チーム

送信者チームは提出後も編集可能なままです。

管理者はワークフロー設定を直接編集して、新しいアクティブな送信者チームを割り当てることができます。

 

5.2.2 削除されたレビュアーチーム

レビューステップは提出後にロックされます。

  • 他の割り当てられたチームが残っている場合
    レビューステップは残っているチームに対して機能し続けます。

  • チームが残らず、自動承認がオンの場合
    ステップはステップの期日に達すると自動的に承認され進みます。

  • チームが残らず、自動承認がオフの場合
    進行中の承認リクエストはそのレビューステップで無期限に停止します。

 

5.2.3 削除された最終レビュアーチーム

最終承認チームは提出後にロックされ、自動承認は最終レビューステップでは利用できません

すべての最終レビュアーチームが削除された場合、進行中の承認リクエストは無期限に停止します。

 

5.2.4 停止またはプロセス不可能なワークフロー推奨アクション

レビューステップが残りのチームなしで停止(および自動承認がオフ)または、すべての最終レビュアーチームが削除された場合、推奨は壊れた承認ワークフローをアーカイブし、その特定のワークフロームに従うオープンな承認リクエストから厳密にドキュメントを破棄することです。

オプションで、置換が必要な場合は新しい承認ワークフロームを作成できます。

 

5.3 5.3 承認トピックテンプレートのアーカイブと再設定ルール

承認トピックテンプレートは、決定結果ごとに個別に設定されます(例:承認済みコメント付きで承認済み、または_拒否_)。

システムは承認トピックテンプレートの変更を結果ごとに独立して処理します。

 

5.3.1 結果固有の分離

1つの決定結果の承認トピックテンプレートをアーカイブまたは変更すると、その特定の結果のみに影響します。

完全な承認トピックテンプレートを持つその他すべての結果は、期待通りトピックの作成を続けます。

 

5.3.2 リンクされた承認トピックテンプレートのアーカイブ

結果に割り当てられた承認トピックテンプレートがアーカイブされた場合、そのワークフロームに従う進行中の承認リクエスト(およびリンク解除中に送信された新しいリクエスト)は、その結果が選択される場合、トピックを生成しません

 

5.3.3 アーカイブされた承認トピックテンプレートの復元

元の承認トピックテンプレートを復元(アーカイブ解除)すると、関連するすべての承認リクエスト全体にわたってそのテンプレートに従ったトピック作成が自動的に再度有効になります。

 

5.3.4 異なる承認トピックテンプレートの設定

管理者が提出後にワークフロームを更新して、異なるアクティブな承認トピックテンプレートを割り当てる場合、編集前に開始された進行中の承認リクエストは新しいテンプレートを使用してトピックを生成しません

再設定後に送信された新しい承認リクエストのみが、新しく割り当てられたテンプレートに基づいてトピックを生成します。

こちらの回答で解決しましたか?