リクエストを作成する

リクエストを管理するためのAccess Requestsのセットアップ方法に応じて、要求者はさまざまな方法でリクエストを送信できます。送信したリクエストに対してチームメンバーまたは承認者が何もアクションを起こさないときは、要求者はAccess RequestsWebアプリを使ってそのリクエストをキャンセルできます。要求者には、自分でセットアップした通知設定に基づいて、リクエストのキャンセルに関する通知が送信されます。

送信したリクエストに対してチームメンバーまたは承認者が何もアクションを起こさないときは、要求者はOkta Access Requests Webアプリを使ってそのリクエストをキャンセルできます。要求者には、自分でセットアップした通知設定に基づいて、リクエストのキャンセルに関する通知が送信されます。

また、ユーザーはアクセスリクエストWebアプリを使って別のユーザーに代わってリクエストを送信することもできます（両方のユーザーがリクエストタイプのオーディエンスである場合）。別のユーザーのリクエストを送信する際に使用できるのはOkta Access Requests WebアプリまたはEnd-User Dashboardのみですが、リクエスト作成者と要求者は通知設定に基づいて、リクエストに関する通知をMicrosoft TeamsとSlackで受信できます。リクエストを作成したユーザーはシステムログに記録されます。

たとえば、マネージャーは新入社員に代わってアプリへのアクセスを要求して、新入社員が最初の日に利用できるようにすることができます。新入社員はチームに参加した後にアプリへのアクセスをリクエストする必要はありません。

デフォルトでは、すべてのユーザーがリクエストを表示できます。送信されたリクエストをプライベートとしてマークできます。または、チーム設定を更新して、チームのすべての受信リクエストをプライベートとしてマークできます。「Access Requestsのチームを作成する」を参照してください。

アクセスリクエスト条件によって管理されるリクエスト

アプリまたはリソースコレクションのアクセスリクエスト条件を設定する場合、これらの条件を満たすユーザーはダッシュボードのリソースカタログから直接アプリまたはコレクションへのアクセスをリクエストできます。条件に要求者が指定したアクセス期間が含まれる場合、ユーザーはアクセスに必要な期間（設定する制限期間まで）を示します。

アプリに職務の分離（SoD）ルールを定義し、アプリまたはリソースコレクションにアクセスリクエスト設定を構成した場合は、アクセスリクエスト設定応じて、要求者のエクスペリエンスが異なる可能性があります。設定を構成する（Configure settings）を参照してください。

デフォルトでは、すべてのリクエストはプライベートとしてマークされるため、これを表示できるのは、要求者、リクエスト割り当て先、リクエスト内のステップが割り当てられているユーザーのみです。

Access Requestsを初めて使用するときは、最初に条件（conditions）を使ってアクセスリクエストを管理します。

リクエストタイプによって管理されるリクエスト

アクティブなリクエストタイプが1つ以上ある場合、要求者はOkta Access RequestsWebアプリ、Slack、またはMicrosoft Teamsを使ってリソース向けのリクエストを送信できます。

Okta Access RequestsWebアプリからアクセスを要求する場合、要求者は、必要なアクセスを得るためにどのリクエストタイプを選択するかを決定します。

SlackまたはMicrosoft Teamsを通じてアクセスを要求する場合、Access Requestsは機械学習を使って自然言語リクエストからの情報を解析し、それを過去のリクエストと比較します。要求者がI need a Grammarly accountやI need to access Jiraというメッセージを送信すると、システムはリクエストに最適なリクエストタイプを特定しようとします。システムがリクエストの分類を誤った場合、要求者はリクエストを手動で調整できます。

統一された要求者のエクスペリエンス

早期アクセスリリース。セルフサービス機能を有効にするを参照してください。

統一された要求者のエクスペリエンス（Unified requester experience）機能を有効にすると、リソースアクセスの管理方法（条件によるかリクエストタイプによるか）にかかわらず、リソースへのアクセスをリクエストするプロセスは同じになります。管理者は、要件に基づいていずれかまたは両方の方法を柔軟に組み合わせて使用し、要求者のエクスペリエンスを変更することなくリソースアクセスを管理できます。

要求者は、ダッシュボード、Slack、Microsoft Teamsから直接リソースへのリクエストを開始できます。

End-User Dashboardのエクスペリエンス

ユーザーがダッシュボードからアクセスを要求すると、リクエストタイプがアプリやコレクションの横にタイルとして表示されます。リクエストタイプのオーディエンスの設定は、引き続きどのユーザーがダッシュボードとリクエストアクセスでリクエストタイプを表示できるかを管理します。

Slackのエクスペリエンス

Slackとの統合後、ユーザーがSlackで実行できるアクションをSettings（設定）ページから制御できます。リクエストを送信（Submit requests）トグルをオンにしている場合、ユーザーはEnd-User Dashboardにリダイレクトされることなく、Slackから直接アクセスリクエストを送信できます。変更は、リクエストタイプによる管理と条件による管理の両方のアクセスリクエストに適用されます。

リクエストの承認と拒否（Approve and deny requests）トグルはデフォルトでオンです。また、ユーザーはSlackから管理者ロールバンドルアクセスリクエストを承認することもできます。

Okta Access Requests Webアプリのエクスペリエンス

管理者またはリクエストタイプを所有するチームメンバーでない場合、Access Request Webアプリではリクエストタイプを利用できません。要求者は、Okta Access Requests Webアプリのリソースカタログ（Resource catalog）（旧称 Access Requests ）をクリックして、アクセスをリクエストできます。

リクエストの送信方法

承認者のエクスペリエンスは、承認者がOkta Access RequestsWebアプリ、Slack、Microsoft Teamsのどこでアクションを実行するかによって異なります。OktaAccess RequestsWebアプリでの承認手順については、タスクを管理するを参照してください。