---
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) 所要時間：1分

データ分離は、ワークフローコンテキストを、ワークフローの同じドメイン内にあるか、または親ドメインのメンバであるユーザに制限します。  
図 : 1. ワークフローとデータの分離

Workflow Contexts \[wf_contexts\]テーブル内のワークフローレコードは、データと見なされます。データ分離は、ワークフローコンテキストを、ワークフローの同じドメイン内にあるか、または親ドメインのメンバであるユーザに制限します。親ドメインのユーザーは、子ドメインの実行中のワークフローを見ることができますが、子ドメインのユーザーは親ドメインの実行中のワークフローを見ることができません。必要に応じて、アドミニストレーターは可視化を使用するか、ドメインを含むことで、ドメイン固有のデータを見ることができるユーザーを拡大することができます。

たとえば、ACMEユーザーがサービスカタログから何かを要求すると、ACMEドメインにサービスカタログ要求ワークフローコンテキストが作成されます。同様に、Initechユーザーからのサービスカタログ要求は、Initechドメインにワークフローコンテキストを作成します。TOPドメイン内のMSPユーザーは、ACMEドメインとInitechドメインの両方の親ドメインであるため、両方のワークフローコンテキストを表示できます。ただし、ACMEまたはInitechのユーザーがログインすると、データの分離により、互いのサービスカタログ要求が表示されなくなります。各ワークフローコンテキストには、要求されたアイテムや要求の承認履歴など、そのドメインに固有のデータが含まれているため、これは正常な動作です。