---
sourceDocument: Yokohama ビルドのワークフロー
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/build-workflows

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama ビルドのワークフロー

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# ドメインセパレーションと ワークフロー

# ドメインセパレーションと ワークフロー {#ariaid-title1}

* リリースバージョン: Yokohama
* 
* 更新日 2025年01月30日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

ドメインセパレーションは、ワークフロー アプリケーションでサポートされています。 ドメインセパレーションでは、データ、プロセス、および管理タスクをドメインと呼ばれる論理的なグループに分けることができます。どのユーザーがデータを表示できるか、データにアクセスできるかなど、このアプリケーションのいくつかの側面を制御できます。

## サポートレベル：標準\* {#c_WorkflowsAndDomainSeparation__section_skz_c1s_xkb}

* ベーシックレベルを含みます。
* ビジネスロジック：サービスプロバイダーによって顧客ごとにプロセスを作成または変更できます。ユースケースには、単一のインスタンスでの複数のサービスプロバイダー顧客によるアプリケーションの正しい使用が反映されています。
* インスタンスの所有者は、特定のアプリケーションに期待される通りに、テナントごとに MVP ビジネスロジックとデータパラメーターを設定できる必要があります。
{#c_WorkflowsAndDomainSeparation__ul_idg_21s_xkb}ユースケース：アドミニストレーターには、あるテナントではレコードを閉じる際にコメントを残すことを必須にし、別のテナントでは必須にしない機能が必要です。

## 概要 {#c_WorkflowsAndDomainSeparation__section_tjg_rg3_zdb}

ドメインセパレーションが有効な場合、ワークフローおよびワークフローアクティビティは、そのドメインをパブリッシュまたは作成するユーザーのドメインを継承します。

## ワークフロー アプリケーションでのドメインセパレーションの機能の仕組み {#c_WorkflowsAndDomainSeparation__section_yx4_tg3_zdb}

ワークフローは複数のテーブルで管理されますが、ドメインセパレーション機能には次の表のみが使用されます。

* ワークフロー\[wf_workflow\]とワークフローバージョン\[wf_workflow_version\]：[委任管理](https://www.servicenow.com/docs/access?context=c_DelegatedAdministration&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US)やプロセス分離に使用されます。
* ワークフローコンテキスト\[wf_context\]：[ドメインセパレーションの理解](https://www.servicenow.com/docs/access?context=c_DomainSeparation&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US)に使用されます。
{#c_WorkflowsAndDomainSeparation__ul_abv_b2s_2r}  
注:  
ワークフローバージョンテーブル\[wf_workflow_version\]テーブルにドメインフィールドが含まれていません。ワークフローバージョンレコードは、親ワークフローレコードからドメインを継承します。

ワークフローエディタは、ワークフロー名の後のタイトルバーにワークフローのドメインを表示します。  
図 : 1. ワークフローエディタ
**関連情報**   

* [サービスプロバイダーのドメインセパレーション](https://www.servicenow.com/docs/access?context=domain-sep-landing-page&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US)

## ワークフローと委任管理 {#ariaid-title2}

委任された管理により、子ドメインはドメイン階層の上位からのワークフローを継承し、必要に応じてドメイン固有のバージョンで上書きすることができます。  
図 : 2. ワークフローと委任管理

ワークフロー\[wf_workflow\]およびワークフローバージョン\[wf_workflow_version\]テーブルのワークフローレコードはプロセスと見なされます。子ドメイン内のユーザーは、親ドメインからワークフローをチェックアウトできますが、コピーはできません。子ドメインのユーザーが親ドメインからワークフローをチェックアウトすると、そのユーザーのドメインにワークフローのバージョンが作成されます。この新しいバージョンは、ワークフロー\[wf_workflow\]テーブルの一意のレコードです。ユーザーがこの新しいワークフローを公開すると、子ドメインの他のユーザーは新しいワークフローを使用します。これにより、親ドメインのワークフローがオーバーライドされます。親ドメインの元のワークフローは、子ドメインのユーザーには表示されなくなりました。

たとえば、管理対象サービスプロバイダ（MSP）は、ACMEとInitechを含む複数の企業のITSMサービスを1つのインスタンスでホストします。アドミニストレーターとして、MSPは、すべてのドメインに適用される変更要求 - 緊急のワークフローを作成します。これは、ドメイン階層内の最高のドメインであるTOPドメインで作成されたためです。このワークフローは、グローバル変更要求 - 緊急ワークフローをオーバーライドし、緊急変更要求にCAB承認グループの承認が必要であることを指定します。委任された管理のため、階層内のすべてのドメインがこのワークフローを認識して使用します。ここで、ACMEドメインが、緊急変更要求が緊急CAB承認グループの承認を必要とする場合、異なる承認ポリシーが必要であるとします。MSPは、ACMEドメインに別のバージョンの変更要求 - 緊急ワークフローを作成します。このワークフローは、TOPドメインのバージョンを上書きし、ACMEドメインのユーザーにのみ適用されます。

## ワークフローのアクセス許可 {#ariaid-title3}

ユーザーが新しいワークフローを開始すると、そのユーザーのドメインと認証情報でワークフローが実行されます。

ワークフローは、承認または拒否を待つ承認アクティビティなど、アクティビティがワークフローを待機させるまで、ユーザーのドメインと認証情報を保持します。ユーザーが要求を承認するなど、停止したワークフローが再開されると、ワークフローは承認ユーザーの認証情報を使用しますが、元のユーザーのドメイン内で引き続き実行されます。