承認ワークフローの作成

アクセス制御管理者または管理者アプリケーション・ロールを持つOracle Access Governanceユーザーは、Oracle Access Governanceコンソールから承認ワークフローを作成できます。

承認ワークフローに移動

適切なアプリケーション・ロールでOracle Access Governanceコンソールにサインインします。「事前定義済アプリケーション・ロール・リファレンス」を参照してください。
ナビゲーション・アイコンから、「アクセス制御」、「承認ワークフロー」の順に選択します。「承認ワークフロー」ページが開き、既存のワークフローを表示および管理できます。
[+承認ワークフローの作成]ボタンをクリックします。
承認ワークフローを構成するための「新規承認ワークフローの作成」ページが表示されます。

新規承認ワークフローの追加

承認ワークフローは、組込みの承認テンプレートを使用してカスタマイズできます。

「新規承認ワークフローの作成」ページで、プラス・アイコンをクリックします。「新規承認の追加」サイド・ペインが表示されます。
「どのタイプの承認ですか。」ドロップダウン・リストからいずれかの組込みテンプレートを選択します。詳細は、「組込み承認ワークフロー・テンプレート」を参照してください。
選択した承認テンプレートに基づいて、必須フィールドを構成します。承認テンプレートの構成および詳細設定を参照してください。
必要に応じて、ワークフローの設計を続行します。
- パラレル追加: ワークフローを同じレベルで追加し、以前に構成したワークフローと同時に承認要求を受信します。
- 次に追加: 順次実行されるステージを承認ワークフローに追加します。前のステージの承認は、後続のステージが実行される前に完了する必要があります。
- パラレル承認ワークフローでは、次のいずれかを選択します。
  - すべて: ステージ内のすべてのテンプレートが承認されている場合にのみ、ステージは「承認済」としてマークされます。
  - 任意: ステージ内の少なくとも1つのテンプレートが「承認済」の場合、ステージは「承認済」としてマークされます。
「次へ」を選択します。

承認テンプレートの構成

テンプレート・タイプに従って、承認テンプレート・フィールドを構成します。

次のフィールドを構成します。


フィールド名称	説明
所有者
自己承認を許可しますか。	自己承認を許可するには、[はい]を選択します。ユーザーは、外部承認者の介入なしに自身のアクセス権(アクセスリクエストまたはアクセスレビュー)を承認できます。
カスタム・ユーザー
どのユーザーですか。	カスタムユーザーテンプレートタイプが選択されている場合に、承認タスクを送信するユーザーを選択します。
自己承認を許可しますか。	自己承認を許可するには、[はい]を選択します。この場合、ユーザーは外部承認者の介入なしに自身のアクセス権を持ちます。
管理チェーン
管理チェーンの上限?	承認要求を送信しない階層の上限。次の項目から選択します。上げるレベルの数最上位からのレベル数アイデンティティ・コレクション
レベルをいくつ上げますか。	受益者の管理者から開始して、承認リクエストが処理されるレベル数を入力します。承認リクエストは、定義されたレベル数を超えて送信されません。
最上位からレベルをいくつ下げますか。	組織の最上位のロールから開始して、承認リクエストを停止する必要がある最上位のレベルの数を入力します。
上限のアイデンティティ・コレクション	メンバーが管理チェーンの終了を表すアイデンティティ・コレクション。承認は、このアイデンティティ・コレクションのメンバーまたはマネージャ以上のいずれにも割り当てられません。
承認結果が却下の場合でもワークフローを継続しますか。	「はい」または「いいえ」を選択して、否認の受信後にワークフローを続行するかどうかを構成します。たとえば、定義された承認順序に従って、受益者のマネージャがリクエストを却下した場合、ワークフローが引き続き管理チェーンからの承認の収集に進む必要があります。
アイデンティティ・コレクション
承認のアイデンティティ・コレクション	承認リクエストを受信するアイデンティティ・コレクションを選択します。
すべてのメンバーの承認が必要ですか。	リクエストを承認するために全てのメンバーが承認を必要とする場合にオンにします。「はい」を選択してすべてのメンバーから承認を取得し、「いいえ」を選択してさらに構成します。
何人のメンバーの承認が必要ですか。	承認済としてマークする前にリクエストを承認するために必要な最小メンバー数を選択します。
承認者に拒否権を付与しますか。	「はい」を選択すると、単一のメンバーが承認要求を拒否した場合に承認要求を否認できます。1人のメンバーの拒否は拒否として機能し、承認ワークフローを停止して拒否としてマークします。
どのアイデンティティ・コレクションにリクエストをエスカレーションしますか。	メンバーがエスカレーションを受信するアイデンティティ・コレクションを選択します。
自己承認を許可しますか。	自己承認を許可するには、[はい]を選択します。ユーザーは、外部承認者の介入なしに自身のアクセス権(アクセスリクエストまたはアクセスレビュー)を承認できます。

承認テンプレートの拡張設定

また、承認ワークフローの構成時に、デフォルトの詳細設定を構成または更新できます。

次の拡張設定を構成します。


フィールド名称	説明
通知の間隔は何日にしますか。	電子メールでリマインダを送信するまでの期間(日数)。
承認リクエストをエスカレーションするまでに何日待機しますか。	設定された日数内にアクションが実行されない場合、リクエストは転送され、次の承認者にエスカレートされます。Escalation Handlingを参照してください。
どのアイデンティティ・コレクションで、エスカレーションを受信しないようにしますか。	遅延後でも、エスカレートされた承認要求を受信しないアイデンティティ・コレクションを選択します。たとえば、キャンペーン承認タスクのBoard of Membersアイデンティティ・コレクションです。
承認リクエストに有効期限を設けますか。	「はい」または「いいえ」を選択します。
承認リクエストの期限が切れた後の承認待ちの処理方法	承認リクエストに有効期限がある場合は、次のいずれかを選択して保留中のタスクをクローズします。すべて承認すべて拒否
承認リクエストは何日で失効させますか。	承認要求が失効するまでにアクティブのままになる日数を構成します。
承認結果が却下の場合でもワークフローを継続しますか。	「はい」または「いいえ」を選択して、否認の受信後にワークフローを続行するかどうかを構成します。たとえば、定義された承認順序に従って、受益者のマネージャがリクエストを却下した場合、ワークフローが引き続き管理チェーンからの承認の収集に進む必要があります。

詳細の追加

「詳細の追加」ステップでは、承認ワークフローに名前を追加し、ワークフローの簡単な説明を指定できます。

詳細を追加するには:

「この承認ワークフローを何と呼びますか。」フィールドにワークフローの名前を入力します。
「この承認ワークフローをどのように記述しますか。」フィールドに、ワークフローの簡単な説明を入力します。
詳細を入力したら、「次へ」をクリックしてレビューおよび送信ステップに進みます。
オプションで、次のことが可能です。
- ドラフトの保存: 変更を保存し、後で戻ってワークフローまたは詳細を編集します
- 取消: 現在のプロセスを取り消します。
- 戻る: 前のステップに戻ります。

所有者の追加

プライマリ所有者と追加の所有者を編成済システムに追加して、リソースを管理できるようにします。

リソース所有権を関連付けるには、プライマリ所有者と追加所有者を追加します。これにより、これらの所有者は所有するリソースを管理(読取り、更新または削除)できるため、セルフサービスが促進されます。デフォルトでは、リソース作成者はリソース所有者として指定されます。1人のプライマリ所有者と最大20人の追加所有者をリソースに割り当てることができます。

ノート

サービス・インスタンスに対して最初のオーケストレート済システムを設定する場合、「アイデンティティの管理」セクションからアイデンティティを有効にした後にのみ所有者を割り当てることができます。

所有者を追加するには:

「プライマリ所有者は誰ですか。」フィールドで、Oracle Access Governanceのアクティブ・ユーザーをプライマリ所有者として選択します。
「他の所有者は誰ですか。」リストで1つ以上の追加所有者を選択します。リソースに最大20人の追加所有者を追加できます。

リストの「プライマリ所有者」を表示できます。すべての所有者は、所有するリソースを表示および管理できます。

レビューおよび送信

「確認および送信」ステップには、前のステップで追加した情報が表示されます。この画面では、次をクリックできます。

公開: ワークフローを公開します。
ドラフトの保存: 変更を保存し、後で戻ってワークフローまたは詳細を編集します
取消: 現在のプロセスを取り消します
戻る: 前のステップに戻ります

Oracle Cloud Infrastructureドキュメント

承認 ワークフローの作成