従業員オフボーディングプロセスMCPサーバー
Employee Offboarding Process MCPサーバーを使用すると、従業員が組織を離れるときに、LLMが自然な会話を通じてWorkday, Okta, Google Workspace, Slack, Zoom, ServiceNow, Salesforce, and GitHubとやり取りし、システム横断的なアクセス取り消しを行えます。退職する従業員の解決、完全な取り消しプランのプレビュー、明示的な確認後のプラン実行、システムごとの進捗状況の追跡、失敗したステップの再試行、およびまだ進行中の作業のキャンセルを行うツールを提供します。
用途
Employee Offboarding Process MCPサーバーを使用して、次のアクションを実行します:
- 退職する従業員を名前、勤務先メール、またはWorker IDで解決し、保留中のWorkday termination eventを確認します
- 変更をコミットせずに、承認済みのWorkday termination eventに関連付けられた、システム横断的な完全な取り消しプランをプレビューします
- OktaセッションとOAuthトークンを取り消してから、Oktaアカウントを一時停止します
- Directoryを通じて従業員のGoogle Workspaceアカウントを一時停止します
- 従業員のSlackおよびZoomアカウントを非アクティブ化し、デプロイメントで有効にしている場合はSalesforceとGitHubも非アクティブ化します
- デバイス返却、メール転送のフォローアップ、個人アクセストークン監査など、自動化範囲外の作業用のServiceNowチケットを作成します
- 最終給与計算のためにWorkday termination eventにフラグを設定し、退職する従業員のマネージャーに通知します
- 通知期間中の将来のアクセス停止に合わせて取り消しをスケジュールするか、会社都合による解雇の場合は直ちに取り消します
- システムごとの進捗状況を追跡し、失敗した非クリティカルなステップを再試行し、スケジュール済みまたは進行中のオフボーディングをキャンセルします
さらに、サーバーに組み込まれているEmployee Offboarding Process MCPアプリを使用して、確認前にプランを確認し、その後の実行を追跡します。
プロンプト例
次のプロンプト例を使用して、Employee Offboarding Process MCPサーバーツールを呼び出します:
Offboard Dan Chen. The approved Workday termination event is TERM-4821.Look up Ariel Miller's pending termination events.Offboard this employee immediately. The termination is effective today.Show me the revocation plan before anything gets cut.What's the status of offboarding off_a1b2c3?Which systems failed on Jade's offboarding?Retry the Zoom deactivation step.Cancel the scheduled offboarding for Worker 100294.Show me every offboarding in flight.List the offboardings I started in the last two weeks.
Employee Offboarding Process MCPサーバーのツール
Employee Offboarding Process MCPサーバーは次のツールを提供します:
| ツール | 説明 |
|---|---|
| find_employee | 従業員を名前、メール、またはWorker IDから解決し、ID、マネージャー、および保留中のWorkday termination eventを返します。 |
| execute_offboarding | confirmがfalseの場合はplan_idを含む取り消しプランを返し、confirmがtrueの場合はその特定のプランを実行します。 |
| get_offboarding_status | クリティカル度と再試行可否を含む、オフボーディングのシステムごとのステータスを返します。 |
| retry_offboarding_step | 前後のステップを再実行せずに、プレビュー後に失敗した単一のステップを再試行します。 |
| cancel_offboarding | 一時停止済みのアカウントを再アクティブ化せずに、現在の状態に応じてオフボーディングをキャンセルします。 |
| list_offboardings | ステータス、開始者、従業員、または日付範囲別にオフボーディングを一覧表示します。 |
すべてのコミットに個別の承認が必要
execute_offboarding、retry_offboarding_step、およびcancel_offboardingは、それぞれ2段階で実行されます。 LLMは、confirmをfalseに設定してツールを呼び出し、プレビューを返します。その後、そのプレビューを明示的に承認した場合にのみ、confirmをtrueに設定して再度呼び出します。
承認は引き継がれません。 confirm=true呼び出しは、その直前のプレビューからのplan_idに関連付けられ、サーバーは期限切れのプランや基盤となる状態が変化したプランを拒否します。
Employee Offboarding Process MCPサーバーのインストール
構築済みMCPサーバーをプロジェクトにインストールするには、次の手順を完了します:
Workatoアカウントにサインインします。
AI Hub > Enterprise MCPに移動します。
+ Create MCP serverをクリックします。
接続済みアプリを使用して構築済みMCPサーバーを開始するセクションに移動し、使用する構築済みMCPサーバーを選択します。
Use this serverをクリックします。
サーバー名フィールドにMCPサーバーの名前を入力します。
場所ドロップダウンメニューを使用して、MCPサーバーのプロジェクトを選択します。
Connectionsセクションに移動し、アプリアカウントに接続します。
MCPサーバーテンプレートで使用するコネクションタイプを選択します。
- User's connection: MCPサーバーツールは、アプリケーションに接続するユーザーのIDと権限に基づいてアクションを実行します。ユーザーは自分の認証情報で認証し、スキルを実行します。
- Your connection: このオプションでは、レシピビルダーによって確立されたコネクションを使用し、通常のアプリコネクションと同じ原則に従います。
コネクションタイプを選択
検証済みユーザーアクセスの認証要件
OAuth 2.0認可コードグラントを使用するアプリコネクションのみが、ユーザーのコネクションで利用できます。詳細については、検証済みユーザーアクセスを参照してください。
次のセクションで、アプリ固有のコネクション設定手順を完了します。
Employee Offboarding Processのコネクション設定
Employee Offboarding Process MCPサーバーをセットアップするには、次のコネクションを設定します:
- Workday: 必須です。承認済みのtermination eventを提供し、最終給与計算フラグを受け取ります。
- Okta: 必須です。セッションとOAuthトークンを取り消してから、アカウントを一時停止します。
- Google Workspace: 必須です。従業員のDirectoryユーザーを一時停止します。
- Slack: 必須です。セッションをリセットし、ユーザーを非アクティブ化します。
- Zoom: 必須です。ユーザーを非アクティブ化します。
- ServiceNow: 必須です。デバイス返却、メール転送、およびトークン監査のチケットを作成し、マネージャー通知を記録します。
- Salesforce: 必須。
- GitHub: 必須です。
OKTA SSOはデプロイメントの前提条件です
このMCPサーバーをデプロイする前に、使用予定のすべてのSaaSアプリケーションでOkta SSOを適用してください。 MCPサーバーはランタイムでSSO適用状況を確認しません。
Employee Offboarding Processのロール要件
各ツールの利用可否は、接続済みアカウントの権限によって異なります。必要な権限なしでツールを呼び出すと、部分的な結果ではなくpermission_deniedの結果が返されます。
MCPサーバーは、すべての監査レコードで2つのIDを分離します。認証済みの呼び出し元はinitiating_actorとして記録され、HRオフボーディング権限を保持している必要があります。各ダウンストリーム管理操作を実行するデプロイメントごとのサービス資格情報は、execution_identityとして記録されます。 HRビジネスパートナーがサービス資格情報を保持することはありません。
Workday: termination eventを読み取り、
workday.payroll_flag_actionで指定したbusiness processアクションを実行する権限を持つ統合ユーザーが必要です。Okta: セッション管理、トークン管理、およびユーザーライフサイクル管理スコープを持つ管理者APIトークンが必要です。
Google Workspace: ドメイン全体の委任と
admin.directory.userスコープを持つサービスアカウントが必要です。このスコープは、User Management管理者ロールを持つアカウントに付与されている必要があります。サーバーはDirectoryユーザーのみを一時停止するため、Gmail APIアクセスは必要ありません。Slack: SCIM非アクティブ化にはBusiness+またはEnterpriseプランが必要です。個別セッションリセットメソッドにはEnterpriseが必要です。
Zoom: Businessプラン以上が必要です。
ServiceNow: 設定するインシデントテーブルおよびリクエストテーブルに対する書き込みスコープが必要です。
Salesforce: Enterprise Edition以上とManage Users権限が必要です。
GitHub: GitHub Enterprise Cloudが必要です。Enterprise Managed Users(EMU)を通じたSCIMプロビジョニング、またはメンバーアカウントでのSAML SSOのいずれかを使用します。
Workdayコネクション設定手順
Workday RESTコネクション設定手順を表示
Workato Workdayコネクターは、メインのWorkdayコネクター、Workday Web Servicesコネクター、およびWorkday RESTコネクターの3つの異なるタイプに分類されます。各タイプは同様の認証パターンに従いますが、サポート機能および機能性が若干異なります。
WorkdayをWorkatoと統合する前に、統合システムユーザー(ISU)を作成することをお勧めします。 ISUにより、すべての統合操作が通常のワークフロープロセスとは別に、指定されたユーザーの下でログに記録されます。通常のワーカーのセキュリティプロファイルの変更や退職により、そのアカウントに依存する連携が中断される可能性があるため、これは不可欠です。セキュリティを強化するため、各ISUはWorkatoなどの単一の統合システムに限定してください。
Workday REST APIでは、OAuthクライアントの設定による認証が必要です。統合にWorkdayのカスタムオブジェクトが含まれる場合、Workday APIクライアントを登録する必要があります。
WorkdayはアウトバウンドWebhookをサポートしていないため、Workato Workdayコネクターはデフォルトで5~15分間隔のポーリングによってtermination eventを取り込みます。これにより、新しく承認されたイベントがfind_employeeに表示されるまでの速さにしきい値が設定されます。イベントIDを取得した後に開始するオフボーディング自体には影響しません。
統合用APIクライアントはサポートされていません
API clients for IntegrationはEmployee Offboarding Process MCPサーバーではサポートされていません。
WorkdayでIntegration System Userを登録
正常なインテグレーションを作成するには、Integration System User(ISU)に必要な権限を割り当てる必要があります。 ISUの権限が不十分な場合、403エラーが発生することがあります。
ISUに十分な権限がない場合のエラーメッセージ
403エラーは、ISUに必要なドメインレベルの権限がないことを示している場合があります。 ISUに適切な権限が付与されていることを確認するには、セキュリティグループへのドメインアクセスの付与セクションを参照してください。
ISU設定手順を表示
Integration System Userの作成
WorkdayでISUを作成するには、次の手順を実行します:
Workdayの検索バーにインテグレーションシステムユーザーの作成と入力し、結果からタスクを選択します。
Workdayでインテグレーションシステムユーザーの作成タスクを検索
インテグレーションシステムユーザーの作成タスクで、ユーザー名を入力してパスワードを設定します。
ISUユーザー名
WorkdayのISUユーザー名にスペースを含めると、エンコードおよび書式設定の問題が発生する可能性があります。スペースの代わりにアンダースコア(_)またはハイフン(-)を使用することを強くお勧めします。
統合システムユーザーの作成
ISUのタイムアウトを防ぐため、セッションタイムアウト時間を0に設定します。
UIセッションを許可しないチェックボックスが選択されていないことを確認します。
パスワードルールの管理タスクに移動します。
統合システムユーザーをパスワード有効期限から除外されるシステムユーザーフィールドに追加して、そのユーザーをパスワードの有効期限から除外します。
ISUをパスワードの有効期限から除外
新しいAPIクライアントの登録
Workday RESTでAPIクライアントを登録するには、次の手順を実行します。
Workday RESTアカウントにサインインします。
Register API Clientと入力して、Register API Client(APIクライアントの登録)タスクを見つけます。
APIクライアントの名前をClient Name(クライアント名)フィールドに入力します。
Client Grant Type(クライアント許可タイプ)セクションに移動し、Authorization Code Grant(認可コードグラント)を選択します。
Access Token Type(アクセストークンタイプ)セクションに移動し、Bearerを選択します。
Redirection URI(リダイレクトURI)フィールドにhttps:www.workato.com/oauth/callbackを入力します。
Refresh Token Timeout (in days)(リフレッシュトークンのタイムアウト(日数))フィールドに30を入力します。
コネクションのスコープをScope (Functional Areas)(スコープ(機能領域))フィールドに入力します。 Workday End User MCP serverに接続する場合は、Workday End User MCP serverの最小権限を参照してください。
コネクションのスコープをScope (Functional Areas)(スコープ(機能領域))フィールドに入力
Client IDフィールドにクライアントIDを入力します。
REST APIエンドポイントをWorkday REST API Endpoint(Workday REST APIエンドポイント)フィールドに入力します。このエンドポイントは、WorkdayのAPIクライアント詳細ページで確認できます。例: https://wd2-impl-services1.workday.com/xxx/api/v1/example
トークンエンドポイントをToken Endpoint(トークンエンドポイント)フィールドに入力します。このエンドポイントは、WorkdayのAPIクライアント詳細ページで確認できます。例: https://wd2-impl-services1.workday.com/xxx/oauth2/example/token
認可エンドポイントをAuthorization Endpoint(認可エンドポイント)フィールドに入力します。このエンドポイントは、WorkdayのAPIクライアント詳細ページで確認できます。例: https://impl.workday.com/example/authorize
完了をクリックします。
トークンエンドポイントURLの確認
WorkdayでトークンエンドポイントURLを見つけるには、次の手順を実行します:
Workdayの検索フィールドにAPIクライアントを表示と入力します。
検索結果からAPIクライアントを表示レポートにアクセスします。
Token EndpointおよびAuthorization Endpointフィールドに表示されているURLを保存します。これらのURLはOAuth 2.0コネクションに必要です。
トークンエンドポイントと認可エンドポイントのURLを保存
OAuth 2.0認証
OAuth 2.0認証を使用してWorkatoでWorkdayコネクションを設定するには、次の手順を完了します:
OAuth 2.0認証手順を表示
WorkdayでトークンエンドポイントURLを見つけるには、次の手順を実行します:
Workdayの検索フィールドにAPIクライアントを表示と入力します。
検索結果からAPIクライアントを表示レポートにアクセスします。
Token EndpointおよびAuthorization Endpointフィールドに表示されているURLを保存します。これらのURLはOAuth 2.0コネクションに必要です。
トークンエンドポイントと認可エンドポイントのURLを保存
Oktaコネクション設定手順
Oktaコネクション設定手順を表示
このデプロイメントでは、OktaのAPIキー認証メソッド(Okta APIトークン)を使用します。 Okta APIトークンは、Oktaの認可コードグラントおよびクライアント資格情報メソッドのような詳細なOAuthスコープをサポートしていないため、トークンを生成した管理者の権限を継承します。
APIキーの生成
APIキーの権限と制限
APIキーを作成するには、Oktaの管理者権限が必要です。続行する前に、管理者としてログインしていることを確認してください。
Workatoでは、コネクションで使用するユーザーとAPIキーに組織管理者またはスーパー管理者権限があることが必要です。 APIキーは、そのキーを作成した管理者からすべての権限を継承し、特定のリソースまたは操作に制限することはできません。
詳細については、APIトークンを作成を参照してください。
OktaでAPIキーを生成するには、次の手順を完了します:
Oktaにサインインします。
セキュリティ>API>トークンに移動します。
トークンを作成をクリックして、APIキーを生成します。キーは、それを作成した管理者の権限を継承します。
APIキーベースの認証を使用したOktaへの接続
WorkatoでOktaへのAPIキーコネクションを作成するには、次の手順を実行します:
作成 > コネクションをクリックするか、Cを2回押します。
New connectionページで、コネクションとしてOktaを検索して選択します。
コネクション名フィールドに、コネクションの一意の名前を入力します。
Okta APIキーコネクションのセットアップ
Authentication typeドロップダウンメニューを使用してAPI keyを選択します。
Okta domainフィールドにOktaドメイン名を入力します。例: mycompany.okta.comまたはmytest.oktapreview.com。入力するドメイン名に、mycompany-admin.okta.comなどの-adminが含まれていないことを確認してください。このURLはUIからOkta管理コンソールにアクセスするために使用され、OAuthエンドポイントではありません。
Oktaインスタンスで生成したAPIキーを入力します。
接続をクリックします。
Google Workspaceコネクション設定手順
Google Workspaceコネクション設定手順を表示
このデプロイメントにはサービスアカウント認証が必要です。 Google WorkspaceコネクターのOAuth 2.0認証メソッドは、コネクションを1人の従業員自身のGoogle IDに関連付けるため、別の従業員のアカウントを一時停止できません。
コネクション設定を完了するには、GoogleワークスペースAPIを有効にする必要があります。
サービスアカウント認証に必要なスコープ
Directoryユーザーを正常に一時停止するには、admin.directory.userスコープがあることを確認してください。
認証が完了すると、サービスアカウントは、コネクション設定時に指定したメールアドレスに基づいてユーザーになりすまします。
コネクション設定を完了するには、GoogleワークスペースAPIを有効にする必要があります。
サービスアカウント認証に必要なスコープ
サービスアカウントを使用してGoogleワークスペースに正常に接続するには、次の必要な権限があることを確認してください:
admin.directory.useradmin.directory.orgunitadmin.directory.domainadmin.directory.groupadmin.directory.group.memberadmin.datatransferadmin.directory.device.mobile.actionadmin.directory.userschemaadmin.reports.audit.readonlyadmin.reports.usage.readonlyadmin.directory.rolemanagementadmin.directory.user.security
認証が完了すると、サービスアカウントは、コネクション設定時に指定したメールアドレスに基づいてユーザーになりすまします。
サービスアカウント認証を使用してGoogleワークスペースに接続するには、次の手順を完了します:
サービスアカウント認証には、次の前提条件が必要です:
作成 > コネクションをクリックするか、Cを2回押します。
コネクションとしてGoogleワークスペースを検索して選択します。
コネクション名フィールドに、コネクションの一意の名前を入力します。
ロケーションドロップダウンメニューを使用して、コネクションを保存するプロジェクトを選択します。
認証タイプドロップダウンメニューを使用して、サービスアカウントを選択します。
サービスアカウントのメールアドレスをGCPプロジェクトサービスアカウントメールフィールドに入力します。
GCPプロジェクトサービスアカウントメールを取得
秘密鍵とユーザーメールを入力します。ダウンロード可能なJSONから秘密鍵を取得します。 -----BEGIN PRIVATE KEY-----から-----END PRIVATE KEY-----\nまでを含めます。
Googleでサインインをクリックします。
Slackコネクション設定手順
Slackコネクションの設定手順を表示
Slackの非アクティブ化とセッションリセットは、それぞれSlackプランによって異なります:
| Slackプラン | SCIMによる非アクティブ化 | セッションのリセット |
|---|---|---|
| Enterprise Grid | サポート対象 | サポート対象 |
| Business+ | サポート対象 | 利用不可 |
| ProおよびFree | 利用不可 | 利用不可 |
Slackステップは、プランが操作をサポートしていない場合にskipped_plan_unsupportedを返します。
OAuth 2.0標準を使用して、WorkatoがSlack組織にアクセスすることを承認する必要があります。
WorkatoでSlackに接続するには、次の手順を実行します:
作成 > コネクションをクリックするか、Cを2回押します。
Slackを検索し、アプリとして選択します。
コネクション名フィールドにコネクションの名前を入力します。
Slackコネクション
ロケーションドロップダウンメニューを使用して、コネクションを保存するプロジェクトを選択します。
任意です。詳細を展開し、これはClassic Slackアプリですかドロップダウンメニューを使用して、YesまたはNoを選択します。 Slackアプリを詳細な権限スコープに移行していない場合にのみ、Yesを選択します。詳細は、詳細な権限スコープへの移行を参照してください。
任意です。コネクションにリクエストするOAuthユーザースコープを選択するには、OAuthユーザースコープドロップダウンメニューを使用します。このフィールドを空のままにすると、デフォルトスコープがリクエストされます。
任意です。 Custom OAuth profileドロップダウンメニューを使用して、コネクション用のCustom OAuth profileを選択します。詳細については、Slack用Custom OAuth profilesを参照してください。
接続をクリックします。
許可をクリックして、Workatoにアカウントへのアクセス権限を付与します。
Zoomコネクション設定手順
Zoomコネクションの設定手順を表示
ZoomコネクターはOAuth 2.0認証を使用します。
OAuth 2.0認証を使用してWorkatoでZoomに接続するには、次の手順を実行します:
推奨セットアップ
Zoomで専用のAPIユーザーアカウントを設定するか、Custom OAuth profilesを作成してWorkatoを認可することをお勧めします。これにより、APIユーザーを必要な権限のみを持つロールに割り当てることができます。
または、必要な権限を持っている場合は、既存のZoom所有者または管理者アカウントを使用できます。一部の管理者アカウントは、その設定に基づいてアクセスが制限されている場合があります。
APIユーザーを追加
APIユーザーの追加手順を表示
Workato用にプロビジョニングされたAPIユーザーを設定するには、次の手順を実行します:
Zoomアカウントにサインインします。
管理者>ユーザー管理>ユーザーに移動します。
ユーザーを追加
ユーザーを追加をクリックします。
APIユーザーに適切なメールアドレスを入力します。 IT管理者のメールエイリアスをおすすめします。
次のフィールドには、要件に基づいてN/Aを入力するか、値を選択します: 部署、マネージャー、役職、場所、およびユーザーグループ。
Addをクリックします。
管理者>ロールに移動します。
ロールを追加を選択します。
ロール名と説明を入力します。
Addをクリックします。
ロール>ロール設定に移動し、Zoomロールに次の権限を追加します。 WorkatoのZoomコネクターが、他のZoomユーザーの代理でミーティングやウェビナーをスケジュールするなど、アカウントレベルのアクションを実行できるようにするには、ロール権限が必要です。
Users: View and EditRole management: View and EditGroups: View and EditRecording management: View and EditZoom rooms: View and EditMeetings: ViewWebinars: ViewUsage reports: ViewSchedule tracking fields: View and Edit
Save Changesをクリックします。
ユーザー管理>ユーザーに移動し、前の手順で作成したユーザーを見つけます。
編集をクリックし、ユーザーロールドロップダウンメニューを使用して、作成したロールを選択します。
保存をクリックします。
Custom OAuth profilesを作成
Custom OAuth profilesの作成手順を表示
Workato用のカスタムOAuthプロファイルを作成するには、次の手順を完了します:
Workatoでツール > Custom OAuth profilesに移動します。
+ 新規カスタムプロファイルをクリックします。
Zoomを検索し、アプリとして選択します。
NameフィールドにCustom OAuth profileの名前を入力します。
Create new appをクリックします。
Zoom App Marketplaceに移動し、まだサインインしていない場合はZoomアカウントにサインインします。
Develop > Build Appをクリックします。
アプリをビルド
作成するアプリの種類を、次のオプションから選択します: General App、Server to Server OAuth App、またはWebhook Only App。オプションを選択できない場合は、Zoom for developersロールを有効にする必要があります。 Zoom for developersロールを有効にする方法については、Zoomの一般的なアプリ機能の選択ページを参照してください。
Createをクリックします。
アプリの名前を入力し、アプリの管理方法を選択します。詳細については、Zoomのステップ2: 基本情報の管理ページを参照してください。
Client IDとClient Secretをコピーして保存し、Workatoで使用します。
Client IDとClient Secretをコピー
https://www.workato.com/oauth/callbackをOAuth Redirect URLフィールドに入力します。
任意です。 Access、Surface、Embedタブで、必要に応じて設定を構成します。
Scopesに移動し、+ Add Scopesをクリックして必要なスコープを追加します。
コネクションに必要なスコープを検索して選択します。
完了をクリックします。
設定が適切に構成されていることを確認するには、Local Testタブに移動し、Preview your app listing pageを選択します。
WorkatoのNew custom profileページに戻り、Client IDとClient secretをそれぞれのフィールドに貼り付けます。
client IDとclient secretを貼り付け
保存をクリックします。
OAuth 2.0認証を使用してZoomに接続
OAuth 2.0認証でZoomに接続する手順を表示
WorkatoでZoomに接続するには、次の手順を実行します:
作成 > コネクションをクリックします。
Zoomを検索し、アプリとして選択します。
コネクション名フィールドにコネクションの名前を入力します。
コネクションに名前を付ける
任意です。詳細設定セクションを展開し、OAuth 2.0スコープドロップダウンメニューを使用して、コネクションでリクエストするOAuthスコープを指定します。
任意です。 Custom OAuth profileドロップダウンメニューを使用して、コネクションに使用するカスタムOAuthプロファイルを選択します。
接続をクリックします。
Zoomアカウントにサインインします。
ServiceNowコネクション設定手順
ServiceNow ITSMコネクション設定手順を表示
ServiceNowコネクターは、次の認証タイプをサポートしています:
ユーザー名とパスワード
ユーザー名とパスワード認証手順を表示
ログイン認証情報を使用してServiceNowインスタンスに接続するには、Username/Password認証タイプを選択します。
Username/Passwordコネクション
| フィールド | 説明 |
|---|---|
| コネクション名 | 接続先のServiceNowインスタンスを識別する一意の名前を入力します。 |
| 認証タイプ | このServiceNowコネクションの認証タイプを選択します。 ServiceNowコネクターは、Username/Password(Basic)認証、authorization code grantを使用したOAuth 2.0、およびPassword grant認証をサポートしています。 |
| インスタンス名 | インスタンスの名前を指定します。たとえば、ServiceNow URLがhttps://acme.service-now.comの場合、インスタンス名はacmeです。 |
| ユーザー名 | ServiceNowへの接続に使用するユーザー名を指定します。 |
| パスワード | ServiceNowへの接続に使用するパスワードを指定します。 |
| Custom OAuth profile | 任意です。このコネクションのCustom OAuth profileを選択します。 |
OAuth 2.0
OAuth 2.0認証手順を表示
OAuth 2.0クライアントの設定
OAuth 2.0クライアントを設定するには、ServiceNowのadminロールで次の手順を実行します:
OAuth 2.0 (com.snc.platform.security.oauth) プラグインを有効化します。 OAuth 2.0を有効化する方法の詳細については、ServiceNowドキュメントを参照してください。
OAuthプラグインの有効化
クライアントアプリケーションがServiceNowインスタンスへのアクセスを取得するためのエンドポイントを作成します。 Redirect URLとしてhttps://www.workato.com/oauth/callbackを使用します。外部クライアント用のエンドポイントを作成する方法の詳細については、ServiceNowドキュメントを参照してください。
OAuth 2.0クライアント
Client IDとClient secretを使用して、WorkatoでServiceNowコネクションを作成します。これにより、認可を要求する新しいブラウザーウィンドウが開くOAuth authorization code grantフローがトリガーされます。
Workatoでの設定の完了
ログイン認証情報を使用せずにServiceNowインスタンスに接続するには、OAuth 2.0認証タイプを選択します。この認証タイプでは、ログイン認証情報を開示する代わりにトークンを取得することで、Workatoへのアクセスを許可できます。
ServiceNow Istanbul以降のリリースでは、認可コードグラントを使用するOAuth 2.0コネクションがサポートされています。この認証タイプを選択する際は、ご利用のServiceNowバージョンがこれをサポートしていることを確認してください。
OAuth 2.0コネクション
| フィールド | 説明 |
|---|---|
| コネクション名 | 接続先のServiceNowインスタンスを識別する一意の名前を入力します。 |
| 認証タイプ | このServiceNowコネクションの認証タイプを選択します。 ServiceNowコネクターは、Username/Password(Basic)認証、authorization code grantを使用したOAuth 2.0、およびPassword grant認証をサポートしています。 |
| インスタンス名 | インスタンスの名前を指定します。たとえば、ServiceNow URLがhttps://acme.service-now.comの場合、インスタンス名はacmeです。 |
| Client ID | 認可に使用するコネクションのClient IDを指定します。 OAuthクライアントのApplication Registry(アプリケーションレジストリ)をセットアップする方法の詳細については、OAuth 2.0クライアントのセットアップセクションを参照してください。 |
| クライアントシークレット | このOAuthアプリケーションのClient secretを指定します。シークレットを表示するには、Toggle Password Visibility(ロックアイコン)をクリックします。 |
| Custom OAuth profile | 任意です。このコネクションのCustom OAuth profileを選択します。 |
INVALID REFRESH TOKENエラー
ServiceNow OAuth 2.0コネクションの有効期限が切れた後、invalid_requestまたはinvalid refresh tokenエラーが発生する場合があります。この動作は、ServiceNowがリフレッシュトークンの有効期間を制限しているために発生します。トークンの有効期限が切れたら、コネクションを再認証する必要があります。
ServiceNow OAuthクライアント設定でRefresh Token Lifetimeを調整できます。 ServiceNowインスタンスに移動し、System OAuth > Application Registryをクリックして、Workato OAuthクライアントを開き、Refresh Token Lifetimeの値を確認します。デフォルトのリフレッシュトークンの有効期間は100日です。
詳細については、ServiceNow external clientドキュメントを参照してください。
パスワードグラント
Password grant認証手順を表示
ServiceNowインスタンスに接続するには、Password grant認証タイプを選択します。この認証タイプでは、アクセストークンの取得に使用されるログイン認証情報を提供することで、Workatoへのアクセスを許可できます。
Password grantコネクション
| フィールド | 説明 |
|---|---|
| コネクション名 | 接続先のServiceNowインスタンスを識別する一意の名前を入力します。 |
| 認証タイプ | このServiceNowコネクションの認証タイプを選択します。 ServiceNowコネクターは、Username/Password(Basic)認証、authorization code grantを使用したOAuth 2.0、およびPassword grant認証をサポートしています。 |
| インスタンス名 | インスタンスの名前を指定します。たとえば、ServiceNow URLがhttps://acme.service-now.comの場合、インスタンス名はacmeです。 |
| ユーザー名 | ServiceNowへの接続に使用するユーザー名を指定します。 |
| パスワード | ServiceNowへの接続に使用するパスワードを指定します。 |
| Client ID | 認可に使用するコネクションのClient IDを指定します。 OAuthクライアントのApplication Registry(アプリケーションレジストリ)をセットアップする方法の詳細については、OAuth 2.0クライアントのセットアップセクションを参照してください。 |
| クライアントシークレット | このOAuthアプリケーションのClient secretを指定します。シークレットを表示するには、Toggle Password Visibility(ロックアイコン)をクリックします。 |
| Custom OAuth profile | 任意です。このコネクションのCustom OAuth profileを選択します。 |
Salesforceコネクションの設定手順
Salesforceコネクションのセットアップ手順を表示
Workatoは、Salesforce用のOAuth 2.0認証コネクションおよびJWT bearer認証コネクションをサポートしています。
Salesforce OAuth 2.0認証
OAuth 2.0認証手順を表示
OAuth 2.0(認可コードグラント)を使用してSalesforceに接続する
WorkatoでSalesforceへのOAuth 2.0(認可コードグラント)コネクションを設定するには、次の手順を実行します:
OAuthの制限
2025年9月初旬の時点で、SalesforceはインストールされていないSalesforce接続アプリケーションの使用を制限しています。新しいコネクションの作成時にエラーが発生した場合に必要なアクションについては、OAuthの制限を参照してください。 2025年9月17日以降、すべての新しいSalesforceコネクションには、これらの手順が必要です。
作成 > コネクションをクリックするか、Cを2回押します。
Salesforceを検索し、アプリとして選択します。
コネクション名フィールドに名前を入力します。
OAuth2.0 Salesforceコネクション設定
ロケーションドロップダウンメニューを使用して、コネクションを保存するプロジェクトを選択します。
認証タイプドロップダウンメニューでOAuth 2.0 (Authorization Code Grant)を選択します。
サンドボックスドロップダウンメニューを使用して、Salesforceアカウントがサンドボックスアカウントかどうかを指定します。
任意です。詳細設定を展開して、次のオプションを設定します:
詳細設定
- 組織/コミュニティのカスタムドメインURL: SalesforceコミュニティのカスタムドメインのURLを入力します。一意のドメインを持つコミュニティコネクションに必要です。
- 要求する権限: このコネクションで要求する権限を選択します。 Workatoがデフォルトで要求するスコープについては、最小およびデフォルトのスコープを参照してください。
- 検証済みユーザーアクセス設定: 個人用コネクションのカスタム認証を設定します。詳細については、ランタイムユーザーコネクションを参照してください。
リフレッシュトークンスコープが必要です。
いつでもリクエストを実行スコープは、OAuth 2.0コネクションに対するWorkatoの最小スコープの1つですが、Salesforceが実際にこのスコープを付与するかどうかは、Workatoコネクションの設定ではなく、接続アプリケーション独自のOAuthポリシーによって決まります。アクセストークンの有効期限が切れたときにコネクションが後で切断される場合は、Salesforceコネクションが繰り返し切断されるを参照してください。 Refresh Token PolicyまたはIP Relaxationの設定によって、同じ症状が発生する可能性があります。
任意です。 Custom OAuth profileドロップダウンメニューを使用して、コネクション用のCustom OAuth profileを選択します。詳細については、SalesforceのCustom OAuth profileを作成するを参照してください。
接続をクリックします。
任意です。 Salesforce組織またはコミュニティでカスタムドメインを使用している場合は、サインインモーダルで次を実行します:
- カスタムドメインを使用をクリックします。
- カスタムドメインを入力し、続行をクリックします。
Custom domain(カスタムドメイン)を入力します。
Salesforceのユーザー名とパスワードを入力します。
Salesforceアカウントにログインする
ログインをクリックして、設定を完了します。
OAUTH_APPROVAL_ERROR_GENERIC
このエラーが表示される場合、SalesforceはWorkatoアプリがインストールされていないため、そのアプリを制限しています。 Salesforce管理者は、Connected Apps OAuth Usageにアプリをインストールするか、Salesforce権限を割り当てる必要があります。詳細については、OAuthの制限を参照してください。
Salesforce JWT bearer認証
JWTベアラー認証手順を表示
ユーザーに代わって実行するアクション
JWTコネクションは、代理ユーザーメールフィールドを使用して指定したユーザーに代わってアクションを実行できます。この機能を有効にするには、Workatoカスタマーサクセスマネージャーにお問い合わせください。
仕組み
JWTベアラー認証は、JWTリクエストに署名するデジタル証明書を使用して接続します。 WorkatoはSalesforce OAuthトークンエンドポイントにJWTを送信します。SalesforceはJWTを処理し、SalesforceでのWorkatoの事前承認に基づいてアクセストークンを発行します。
JWTベアラーでは対話型サインインがスキップされますが、Salesforceは引き続き、すべてのリクエストをコネクションで指定されたユーザーの権限に照らして評価し、変更をそのユーザーに帰属させます。個人アカウントではなく、専用の連携ユーザーを使用してください。
接続ユーザーに必要なSalesforce権限については、必要なロールと権限を参照してください。
秘密鍵と証明書の生成
JWTベアラー認証には秘密鍵と証明書が必要です。次のコマンドは、OpenSSLを使用してその両方を生成します。 -subjの値を独自の値に置き換えます:
openssl req -x509 -sha256 -nodes -newkey rsa:2048 \
-keyout server.key \
-out server.crt \
-days 365 \
-subj "/CN=Your App Name/O=Your Organization/C=US"これにより、次の2つのファイルが生成されます:
| File | 説明 |
|---|---|
server.key | Workato用の秘密鍵。これは秘密にしておいてください。 |
server.crt | Salesforce用の公開証明書。 |
詳細については、Salesforceのドキュメントを参照してください:
- サーバー間連携用OAuth 2.0 JWTベアラーフロー: Salesforceがこの証明書を使用してJWTに署名し検証する方法の詳細。
- 秘密鍵と自己署名デジタル証明書を作成: 秘密鍵と証明書を生成するその他の方法。
JWTベアラー用の外部クライアントアプリの作成
JWTベアラー認証には、Salesforceに登録された外部クライアントアプリも必要です。 Workatoでコネクションを作成する前に、次の手順を実行します。詳細については、Salesforceの外部クライアントアプリの作成ドキュメントを参照してください。
Salesforceにサインインします。
Setup > Apps > External Client Apps > External Client App Managerに移動します。
New External Client Appをクリックします。
外部クライアントアプリ名フィールドに、Workatoなどの名前を入力します。
次の要件を満たす名前をAPI名フィールドに入力します。
- アンダースコアと英数字のみを含む。
- 一意である。
- 文字で始まる。
- スペースを含まない。
- アンダースコアで終わらない。
- 連続するアンダースコアを含まない。
Contact Emailフィールドにアプリの連絡先メールアドレスを入力します。
Distribution Stateドロップダウンメニューを使用して、LocalまたはPackagedを選択します。
API(OAuth設定を有効化)を展開し、OAuthを有効化チェックボックスを選択します。詳細については、Salesforceの外部クライアントアプリのOAuth設定を構成ドキュメントを参照してください。
コールバックURLフィールドにhttps://www.workato.com/oauth/callbackを入力します。
使用する予定のアクションとトリガーに基づいて、OAuthスコープフィールドでOAuthスコープを選択し、選択項目を選択済みOAuthスコープに移動矢印をクリックして適用します。
外部クライアントアプリのスコープを設定
REFRESH_TOKENスコープが必要です
refresh_token scope is required and the connected app should be installed and preauthorizedエラーが表示された場合は、OAuthスコープにいつでも要求を実行(refresh_token, offline_access)を追加します。その後、無効なセッションエラーが表示された場合は、API経由でユーザーデータを管理(api)も追加します。
フローの有効化セクションでJWTベアラーフローを有効化を選択します。詳細については、SalesforceのJWTベアラーフローを構成ドキュメントを参照してください。
デジタル証明書としてserver.crtをアップロードします。
Createをクリックします。
ポリシータブをクリックし、編集をクリックします。
OAuthポリシーセクションを展開し、許可されているユーザーを管理者が承認したユーザーは事前承認済みに設定します。
USER HASN'T APPROVED THIS CONSUMER
接続時にこのエラーが表示された場合、この手順が実行されていない可能性があります。
アプリポリシーセクションを見つけます。 Workatoが接続時に使用するSalesforceユーザーに割り当てられたプロファイルまたは権限セットのいずれかを、プロファイルを選択または権限セットを選択リストに追加します。詳細については、Salesforceの外部クライアントアプリポリシーを使用したユーザーアプリアクセスの事前承認ドキュメントを参照してください。
USER IS NOT ADMIN APPROVED TO ACCESS THIS APP
接続時にこのエラーが表示された場合、この手順が実行されていない可能性があります。
保存をクリックします。
外部クライアントアプリのSettingsタブをクリックします。
OAuth Settingsセクションを展開します。
Consumer Key and Secretをクリックします。
プロンプトが表示されたら本人確認を行います。
コンシューマーキーをコピーします。 Workatoで接続する際に、これを発行者として入力します。
JWTベアラーを使用したSalesforceへの接続
JWTベアラー認証を使用してSalesforceに接続するには、次の手順を実行します。
作成 > コネクションをクリックするか、Cを2回押します。
Salesforceを検索し、アプリとして選択します。
コネクション名フィールドに名前を入力します。
Salesforce JWTベアラーコネクションを構成
ロケーションドロップダウンメニューを使用して、コネクションを保存するプロジェクトを選択します。
Auth typeドロップダウンメニューを使用してJWT tokenを選択します。
サンドボックスドロップダウンメニューを使用して、Salesforceアカウントがサンドボックスアカウントかどうかを指定します。
-----BEGIN PRIVATE KEY-----行と-----END PRIVATE KEY-----行を含め、server.keyの内容全体を秘密鍵フィールドに貼り付けます。
外部クライアントアプリのコンシューマーキーを発行者フィールドに入力します。
JWTコネクションのSubjectを入力します。これは、Workatoに認証させるSalesforceユーザーのユーザー名です。Experience Cloudサイトに接続する場合は、有効なExperience Cloudユーザー名を指定します。下位互換性のため、subject(sub)の代わりにprincipal(prn)を使用できます。両方を指定した場合、Workatoはprnを使用します。
Salesforce Subdomainを入力します。たとえば、Salesforce URLがyourInstance.salesforce.comの場合、サブドメインはyourInstanceです。
任意です。 Custom OAuth profileドロップダウンメニューを使用して、コネクション用のCustom OAuth profileを選択します。詳細については、SalesforceのCustom OAuth profileを作成するを参照してください。
接続をクリックします。
GitHubコネクション設定手順
GitHubコネクションのセットアップ手順を表示
GitHubのオフボーディングは、アカウントモデルによって異なります。デプロイメント中に組織に適用されるモデルを宣言します。これにより、サーバーは正しいパスを通じてメンバーシップを削除し、監査レコードにモデルを記録します。
| GitHubアカウントモデル | サーバーによるデプロビジョニング方法 |
|---|---|
| Enterprise Managed Users(EMU) | SCIMデプロビジョニング。個人アクセストークンも取り消します |
| SAML SSOを使用する組織またはエンタープライズのメンバーシップ | メンバーシップの削除とSAML資格情報認可の取り消し |
GitHub認証メソッドを表示
次のいずれかの認証方法を使用して、WorkatoでGitHubに接続します:
- OAuth認証。 Workatoレシピがユーザーの代理で動作します。
- GitHub Apps。 Workatoレシピがアプリとして動作します。 GitHub App認証を参照してください。
- personal access token
詳細については、GitHubドキュメントを参照してください。
OAuth認証
OAuth認証手順を表示
OAuth認証を使用してGitHubをWorkatoに接続するには、次の手順を実行します:
Workatoアカウントにサインインし、GitHubコネクションを追加する予定のプロジェクトに移動します。
作成 > コネクションをクリックするか(またはCを2回押す)、GitHubをコネクションとして選択します。
Workatoが接続されているGitHubインスタンスを識別するコネクション名を指定します。
ロケーションドロップダウンメニューを使用して、コネクションを保存するプロジェクトを選択します。
Authentication type(認証タイプ)ドロップダウンメニューを使用し、OAuth Appを選択します。
任意です。 Advanced configurationをクリックして、Host nameフィールドを表示します。
任意です。 Host nameを入力します。これはGitHub Enterprise Serverを使用する場合に適用されます。 GitHubサブドメインを入力します。たとえば、ホストURLがhttps://github.example-organisation.comの場合、サブドメインはgithub.example-organisation.comです。
接続をクリックします。 WorkatoはユーザーをGitHubにリダイレクトします。 OAuth AppがGitHubアカウントへのアクセス許可をリクエストします。
GitHub App認証
まずGitHubアカウントでアプリを登録し、GitHub Appを使用してGitHubに接続するための資格情報を取得する必要があります。
Authentication typeとしてGitHub appを選択し、GitHub Appから詳細を収集します
GitHub Appを登録
GitHub Appを登録する手順を表示
GitHub Appを登録し、Workatoに接続するために必要な認証情報を取得するには、次の手順を実行します:
GitHubドキュメントの手順を完了して、GitHub Appを登録します。
GitHub AppのGeneral設定ページでGitHub App IDを取得します。
このApp IDを保存し、コネクションに入力します
同じページでPrivate keyを生成します。 GitHubはこの.pemファイルをマシンに自動的にダウンロードします。
秘密鍵を生成します
.pemファイルをテキストエディターで開きます。ファイルは次のようになります:
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAyL/wuiSaWoH0pyf366G5E7dbzzmON1qMMrWvls8RtZtgOLjb
FBxj6gO2aUfoGbMCMqOYRV6xCn6tK118sGYMd5U/kCFu3IRPr/2GoEtcrf0TecQG
ON+27ijH0Vpn62o8NzGejdy0AWujrtAl6F8xGZeze0PzrGvW6h/GnAdZO1gJnp8t
wmEqEMXqAsPOQ0hkY+r+pE8RKQVsJCe+PIanBKp7RKWDi9usPFZQdQ==
-----END RSA PRIVATE KEY-----秘密鍵全体をコピーします。-----BEGIN RSA PRIVATE KEY-----と-----END RSA PRIVATE KEY-----を含めてください。 Workatoでコネクションを設定するときに、この秘密鍵を使用します。
Installation IDを、GitHub Appをインストールした組織またはユーザーから取得します:
- ユーザーアカウント: Settings > Applications > Your GitHub App > Configureに移動します。
- 組織: 組織のGitHubホームページに移動します。 Settings > Installed GitHub Apps > Configureをクリックします。
インストールIDはURLに表示されます。たとえば、URLがhttps://github.com/settings/installations/13876669の場合、インストールIDは13876669です。
インストールIDを保存します。 WorkatoでGitHub Appコネクションを作成するときに、このIDを入力します。
GitHub App認証を設定
GitHub Appを認証する手順を表示
Workatoが接続されているGitHubインスタンスを識別するコネクション名を指定します。
ロケーションドロップダウンメニューを使用して、コネクションを保存するプロジェクトを選択します。
認証タイプドロップダウンメニューを使用し、GitHub Appを選択します。
GitHub App IDを入力します。
Github App Private keyを入力します。
Installation IDを入力します。
任意です。 Advanced configurationをクリックして、Host nameフィールドを表示します。
任意です。 GitHub Enterprise Serverを使用している場合は、Host nameを入力します。 GitHubサブドメインを使用します。たとえば、ホストURLがhttps://github.example-organisation.comの場合、サブドメインはgithub.example-organisation.comです。
任意です。 Custom OAuth profileを入力します。この選択により、アプリへのすべてのリクエストで指定したプロファイルが使用されます。
接続をクリックします。
Personal access token認証
personal access tokenを使用してGitHubアカウントをWorkatoに接続するには、GitHubからpersonal access tokenを取得します:
GitHub personal access tokenを取得する手順を表示
Github account > Settings > Developer settings > Personal access tokens > Generate new tokenに移動します。
Generate new token(新しいトークンを生成)をクリックします。
トークンをコピーします。コネクションを認証するには、このトークンをWorkatoに入力します。
Workatoでセットアップを完了する
Workatoでセットアップを完了する手順を表示
パーソナルアクセストークンを使用してGitHubコネクションを設定するには、次の手順を実行します:
Workatoアカウントにサインインし、GitHubコネクションを追加する予定のプロジェクトに移動します。
作成 > コネクションをクリックするか(またはCを2回押す)、GitHubをコネクションとして選択します。
Workatoが接続されているGitHubインスタンスを識別するコネクション名を指定します。
ロケーションドロップダウンメニューを使用して、コネクションを保存するプロジェクトを選択します。
Authentication typeドロップダウンメニューを使用して、Personal Access Tokenを選択します。
任意です。 Advanced configurationをクリックして、Host nameフィールドを表示します。
任意です。 Host nameを入力します。これはGitHub Enterprise Serverを使用する場合に適用されます。 GitHubサブドメインを入力します。たとえば、ホストURLがhttps://github.example-organisation.comの場合、サブドメインはgithub.example-organisation.comです。
Personal Access Tokenを入力します。
任意です。 Custom OAuth profileを入力します。これにより、アプリへのすべてのリクエストで指定したプロファイルが使用されます。
接続をクリックします。
プロジェクトプロパティ設定
Employee Offboarding Process MCPサーバーは、動作とデフォルトを制御するために、次のプロジェクトレベルのプロパティをサポートしています:
| プロジェクトレベルのプロパティ | 説明 |
|---|---|
deployment.enabled_list | このデプロイメントがデプロビジョニングする任意のアプリケーションを選択します。 salesforce、github、またはその両方を選択します。サーバーは、このリストにないアプリケーションを完全にスキップし、そのアプリケーション用のフォローアップチケットを作成しません。 |
workday.payroll_flag_action | 最終給与計算のためにtermination eventにフラグを設定するWorkday business processアクションまたはステップを入力します。 Workdayにはこのための標準操作がないため、値はテナントのtermination business process設定によって異なります。デプロイする前に、Workday管理者に確認してください。サーバーが実行できない値はpayroll_action_misconfiguredを返します。 |
notifications.channel | サーバーがマネージャー通知を送信するために使用するチャネルを選択します。 |
github.account_model | 組織に適用されるGitHubアカウントモデルを宣言し、サーバーが正しいパスを通じてデプロビジョニングできるようにします。 deployment.enabled_listにgithubが含まれている場合にのみ適用されます。 |
escalation.critical_failure_target | クリティカルなステップが失敗したときにStatus Appが表示するIDを入力します。 |
プロジェクトレベルのプロパティ設定手順を表示
プロジェクトレベルのプロパティを設定するには、次の手順を実行します:
Workatoアカウントにサインインし、プロジェクトに移動します。
MCPサーバーを含むプロジェクトに移動します。
Settingsタブをクリックします。
Settingsタブをクリックします。
プロジェクトプロパティを選択します。
更新するプロジェクトプロパティに移動し、Edit(鉛筆)アイコンをクリックします。
Valueフィールドに移動して変更を加えます。たとえば、deployment.enabled_listをsalesforce, githubに設定するか、notifications.channelをHR通知チャネルに設定します。
Employee Offboarding Process MCPサーバーツールの使用方法
使用可能なツールの詳細については、次のセクションを参照してください。
find_employeeツール
find_employeeツールは、従業員を名前、勤務先メール、またはWorker IDから解決し、ID、マネージャー、および保留中のWorkday termination eventを返します。 LLMは、オフボーディングする従業員を指定したとき、または誰かのtermination eventについて質問したときに、このツールを使用します。
質問例:
Look up Ariel Miller.Find the employee with Worker ID 100294.Does Dan Chen have an approved termination event?Show me dan.chen@example.com, including terminated employees.
execute_offboardingツール
execute_offboardingツールは、プレビューで呼び出すと取り消しプランを返し、確認するとそのプランを実行します。 LLMは、従業員のオフボーディングを依頼したときにこのツールを使用します。
質問例:
Offboard Dan Chen. The approved Workday termination event is TERM-4821.Offboard this employee immediately, effective now.Show me the plan for Worker 100294's offboarding before anything is cut.Resume the offboarding that needs attention for Ariel Okafor.
get_offboarding_statusツール
get_offboarding_statusツールは、オフボーディングのシステムごとのステータスを返します。 LLMは、オフボーディングの進捗状況を質問したとき、およびプランを確認した直後に初期進捗を報告するときに、このツールを使用します。
質問例:
What's the status of offboarding off_a1b2c3?How far along is Dan Chen's offboarding?Which systems failed on Jade's offboarding?Show me the audit records for this offboarding.
retry_offboarding_stepツール
retry_offboarding_stepツールは、失敗した単一のステップを再試行します。 LLMは、失敗したステップの再試行を依頼したときにこのツールを使用し、実行前に再試行をプレビューします。
質問例:
Retry the Zoom deactivation step.The Slack step failed. Can you try it again?Show me what retrying step 4 would do.Retry the failed ServiceNow ticket for this offboarding.
cancel_offboardingツール
cancel_offboardingツールは、現在の状態に応じてオフボーディングをキャンセルします。 LLMは、キャンセルを依頼したときにこのツールを使用し、最初にキャンセルをプレビューするため、元に戻せる内容と戻せない内容を確認できます。
質問例:
Cancel the scheduled offboarding for Worker 100294.Stop the offboarding for Dan Chen.What would canceling off_a1b2c3 actually undo?Cancel the remaining steps. The termination was rescinded.
list_offboardingsツール
list_offboardingsツールは、ステータス、開始者、従業員、または日付範囲別にオフボーディングを一覧表示します。 LLMは、進行中の内容について質問したとき、最近のオフボーディングについて質問したとき、またはオフボーディングIDを検索する必要があるときに、このツールを使用します。
質問例:
Show me every offboarding in progress.List the offboardings I started in the last two weeks.Which offboardings completed with failures this month?Find the offboarding for Worker 100294.
Employee Offboarding Process MCPアプリ
Employee Offboarding Process MCPサーバーには、構造化ビューによってエラーが減少する2つの時点で開く2つのMCPアプリが含まれています。どちらのアプリも、確認ステップを追加したり、プレビューをスキップしたりしません。詳細については、MCPアプリを参照してください。
Plan Review App
Plan Review Appは、execute_offboardingがプレビューを返した後に開きます。従業員のIDを、オフボーディングの根拠となるWorkdayイベントとともに表示します。これには、イベントID、タイプ、承認タイムスタンプ、承認者、termination reasonカテゴリ、およびポジションのタイムゾーンが含まれるため、誤ったイベントに基づいて作成されたプランを検出できます。
アプリは、アクセス取り消し、SaaS非アクティブ化、ServiceNowチケット、給与計算と通知など、計画されたアクションをクリティカル度別にグループ化します。各アプリケーションは、サーバーが実行する正確なアクションとともに表示されます。 MCPサーバーが範囲外作業用に作成するチケットが明示的に表示されます。
カウントダウンに、プランが有効な残り時間が表示されます。アプリ内で確認すると、確認情報とプランのIDを使用してexecute_offboardingが呼び出されます。
Status App
Status Appは、プランを確認した後に開きます。各システムがタイムラインの行として表示され、アクション、クリティカル度バッジ、ステータスピル、およびタイムスタンプが表示されます。アプリがget_offboarding_statusをポーリングすると行が更新され、完了した各ステップには監査レコードIDと、サーバーが作成したServiceNowチケットへのリンクが表示されます。
クリティカルなステップで障害が発生すると、設定済みのエスカレーションターゲットの名前を示すバナーが表示され、そのステップに依存するステップが一時停止されます。失敗した非クリティカルな行では、まずインラインプレビューパネルを開く再試行が提示され、残りのステップをキャンセルする場合も同様にキャンセルプレビューパネルが開きます。
はじめに
MCP serverのツールは、Overviewページのツールセクションで表示および管理できます。ツール管理では、次の機能を利用できます:
ツールを開始する必要があります
LLMは、MCP server connector内のアクティブなツールにのみアクセスできます。
最終更新日: