Atlassian Cloud で、ドメイン認証 → ID プロバイダー 統合する際のステップは以下の通りです。

１．ドメイン認証

ユーザへの影響は一切ありません。

２．アカウント申請

アカウント申請を実行することにより、ドメイン認証済みのメールアドレスに紐づくアカウントが組織の「管理対象アカウント」となります。
例えば、「example.com」でドメイン認証した場合、@example.com のメールアドレスを持つ全てのユーザが「管理対象アカウント」となります。これにより、以下の影響があります。

• 管理対象アカウント
  各ユーザは、ユーザプロファイル設定画面から、自身のメールアドレスを変更したりアカウントを削除したりできなくなります。
  ※2段階認証（任意）は設定できます。

• 組織管理者
  管理対象アカウントのプロファイル変更やアカウントの有効・無効・削除などのコントロールができるようになります。

３．Atlassian Guard サブスクライブ

Atlassian Guard のサブスクライブのみであれば、ユーザーには影響はありません。

４．ID プロバイダー統合（シングルサインオン）

シングルサインオンの設定をしても、デフォルトの認証ポリシー（Basic 認証）を変更していなければ、既存ユーザーに影響はありません。

５．認証ポリシーの設定

認証ポリシー設定で、デフォルトポリシーを変更した場合、管理対象アカウントに対して、指定したログイン認証方式が強制されます。
例えば、認証ポリシーの設定で、シングル・サインオンを ON にした場合、ユーザが Atlassian Cloud のログイン画面からアカウント情報を入力すると ID プロバイダーの認証画面にリダイレクトされ、シングルサインオンによるログインを強制されます。

６．ID プロバイダー統合（ユーザプロビジョニング）

ユーザプロビジョニングでは、ID プロバイダーに登録されたグループとグループ内のユーザーを、Atlassian Cloud の組織のユーザディレクトリに同期できます。（Jira や Confluence のグループ所属ユーザーが ID プロバイダーの設定に上書きされます）
プロビジョニングで同期されたアカウントは、ID プロバイダー側でしかアカウントのプロファイルの変更や有効・無効・削除が実行できなくなります。

また、Jira、Confluence は、グループに対してライセンスや権限を紐付けるようになっているため、既存のグループに対してプロビジョニングを実行すると、グループに所属しているユーザーが ID プロバイダーの設定で上書きされ、以下のような影響が出る可能性があります。

1. 意図しないライセンスの付与・剥奪

2. 意図しない権限設定の変更（スペースやプロジェクトの閲覧や編集権限など）