• ドメインフィールドがデータテーブルに存在している可能性がありますが、データを管理するビジネスロジックはありません。
• このレベルでは、ドメイン分割は考慮されません。

• アプリケョンサービスプロバイダーのユースケースに合わせてデータが適切なドメインに送られるようにするビジネスロジックが存在します。
• アプリケーションでは、ユーザーインターフェイス、キャッシュキー、レポート、ロールアップ、集計など、すべてにおいて、実行時にドメインのプロパティが考慮されます。
• インスタンスの所有者は、複数のテナント間で正常に機能するようにアプリケーションを設定できる必要があります。

ユースケース：サービスプロバイダーがチャットを使用して顧客のメッセージに応答する際に、クライアントが応答を確認できるようにする必要があります。

• ベーシックレベルを含みます。
• ビジネスロジック：サービスプロバイダーによって顧客ごとにプロセスを作成または変更できます。ユースケースには、単一のインスタンスで複数のサービスプロバイダー顧客がアプリケーションをどのように使用するかが反映されます。
• インスタンスのオーナーは、特定のアプリケーションに、顧客ごとに MVP (minimum viable product) ビジネスロジックとデータパラメーターを設定できる必要があります。

ユースケース：管理者は、レコードを 1 人の顧客に対してはクローズしないが、別の顧客に対してクローズする場合、コメントを必須にすることができる必要があります。

• ベーシックレベルと標準レベルを含みます。
• サービスプロバイダーの顧客は定義されたユースケースに基づくビジネスロジックを変更できます。これらの構成は UI ベースでフェイルセーフであるため、1 人の顧客による構成が別の顧客に影響を与えることはありません。
• インスタンスの顧客は、自身で MVP ビジネスロジックとデータパラメーターを設定できる必要があります。

ユースケース：共有環境の顧客は、ドメイン内で影響度、緊急性、または優先度に基づいて変更できる必要があります。

ドメインフレームワークが使用されていなくても、プラットフォーム機能またはアプリケーションがサービスプロバイダーのユースケースをサポートできる場合があります。ユースケースには Domain Separation のサポートが詳述されている必要があります。サポートレベルの後のアスタリスク (*) は、この種類の構成を示します。

ユースケース：New York リリースより前は、サービスカタログ はドメインをサポートしていませんでしたが、インスタンスオーナーはユーザー基準を使用して、ドメイン分離されたインスタンス内の各テナントに個別のカタログとアイテムを設定できました。その結果、各テナントは標準レベルで Service Catalog を使用することができました。