独自の Power Pages プロジェクトを計画する

この記事は、プロジェクトに取り組むエンタープライズ チームのガイダンスとして役立ちますが、特定のビジネス ニーズに合わせてサイトを作成する作成者の範囲を超える場合があります。 プロジェクトの規模に関係なく、結果と見込みを明確にした計画を作成することはいつでも良い習慣です。

注意

Power Pages は Power Apps ポータルの基盤の上に構築されています。 Power Pages の構成で使用するツールと方法の多くは、Power Apps ポータルの機能を利用します。 詳細については、概要: Power Apps プロジェクトの計画 を参照してください。

最初の Power Pages プロジェクトの計画を始めるときは、次の質問を検討してください。

  • 誰が私のサイトを使用しますか?
  • ユーザーは何をしますか?
  • サイトにはどのようなテキストとコンテンツが含まれますか?
  • 公開されるものと保護されるものは何ですか?
  • ユーザーは何を使用してサインインまたは登録しますか?
  • ユーザーがサインインした後、データはどのようにセグメント化されますか?
  • ユーザーはどのようにして私のサイトを見つけますか?

これらの質問に答えることは、プロジェクトに着手する際の議論をガイドするのに役立ちます。

対象者

デフォルトのテンプレートには、開始に役立つように構成された基本的な Web ページが含まれています。 これらのテンプレート ページはセキュリティで保護されておらず、インスピレーションのみを目的としたサンプル テキストと画像が含まれています。 コンテンツやデータ エクスペリエンスを開発する際に、特定のページにアクセスするために認証を必要とする場合があります。 組織独自のニーズに合わせて Power Pages サイトをカスタマイズしてください。

匿名ユーザー

サインインを必要としないページは、匿名または認証されていないページと呼ばれます。

認証されたユーザー

認証されたページを使用すると、顧客が表示または変更する正確なデータを指定できます。 サイトを認証済みのみにするには、ホーム ページのプロパティでページのアクセス許可を設定します。 この設定では、サイトのページのコンテンツを表示する前に、ユーザーが登録してサインインする必要があります。 詳細については、ページのアクセス許可 を参照してください。

サイトで認証されたすべてのユーザーは、Dataverse の連絡先レコードに関連付けられています。 サイト認証はあなたの承認を指示するものではないことを覚えておいてください. 認証は、特定のページへのアクセスを許可する単なるデジタル識別子です。

アクセス

今日の多くのサイトにはサインインまたは登録のエクスペリエンスが用意されており、ユーザーはそこで新しいサインイン プロファイルを作成するか、既存のサインインを使用してサイト ページにアクセスします。 これらのサインイン資格情報は、ソーシャル アカウントまたは企業の資格情報に関連付けることができます。 これらの資格情報は、ID プロバイダー (IdP) の例です。 Power Pages は、多くの業界標準 ID プロバイダーと連携します。

詳細: Power Pages における認証の概要)

内部ユーザー

組織内のユーザーは、Microsoft Entra を使用する必要があります。 Microsoft Entra ID を使用すると、アクティブ セッションを通じたシームレスなサインイン エクスペリエンスが提供されます。 Microsoft Entra ID の使用は、サイトのセキュリティにも役立ちます。 ユーザーが組織を辞めると、その Microsoft Entra アカウントが無効にされ、サイトの保護されたページにアクセスできなくなります。 利便性を考慮し、すべての Power Pages サイトで Microsoft Entra ID があらかじめ構成済みです。

チップ

ログイン ボタンの名前を、"Contoso 従業員" や "Contoso 職場アカウント" など、よりわかりやすい名前に変更してください。 "Authentication/OpenIdConnect/AzureAD/Caption" という名前のサイト設定を作成し、表示する値を指定します。 ポータル管理アプリ を使用して、サイト設定を作成および変更します。

外部ユーザー

外部ユーザーは、外部 ID プロバイダーを使用する必要があります。 単一の外部 ID プロバイダーを使用すると、複数のサイトまたはアプリでユーザーを一貫してオンボードすることができます。 ユーザーは、便宜上、単一の認証情報セットを使用してこれらにアクセスできます。 Power Pages には複数のオプションがあります。

Azure Active Directory B2C (Azure AD B2C) は、ID プロバイダーとして検討できるオプションの 1 つです。 カスタムまたは企業 ID システムを統合します。 メール アドレスに基づいてサインイン プロファイルを許可するように設定したオプションなど、Microsoft アカウント、LinkedIn、Google のような既存のソーシャル アカウントの使用を有効にすることができます。

ニーズに合わせてルック アンド フィールをカスタマイズすることもできます。詳細については、Azure AD B2C ユーザー インターフェイスをカスタマイズする を参照してください。

注意

ローカル サインイン プロバイダーを無効にすることをお勧めします。 詳細については、認証の構成を開始する を参照してください。

セキュリティ

Power Pages を使用すると、安全なサイトを作成できます。

サイト上の任意のページとデータを保護できます。 詳細については、Power Pages セキュリティ を参照してください。

テーブルのアクセス許可を設定し、認証済みおよび未認証の対象ユーザーの Web ロールを構成できます。 詳細については、テーブルのアクセス許可を割り当てる構成 を参照してください。

Note

テーブル アクセス許可にグローバル スコープを使用する前に、他のスコープ タイプを検討してください。

オープン登録を許可するか、ID プロバイダーを使用してメール アドレスを検証することができます。 詳細については 外部対象ユーザーにアクセスを提供する を参照してください。

データ モデリング

データ ワークスペース を使用すると、テーブル、ビュー、フォームを作成できます。これらは、Microsoft Dataverse に格納されたデータをユーザーが直接操作できるようなリストおよびフォーム コンポーネントを含むページを作成するために使用します。 ユーザーがデータを操作できるように、適切なテーブルのアクセス許可を構成する必要があります。

匿名ユーザーのデータ設計

読み取りアクセスを許可するために、データ設計で特定の操作を行う必要はありません。 匿名 Web ロールにグローバル テーブル アクセス許可を割り当てると、ページにアクセスしたときにすべてのデータがリストまたはフォームに表示されます。

コンテキスト認証ユーザー データ設計

サイトで認証されたユーザーは、サインインすると、対応する連絡先レコードによって表されます。 アカウント テーブルと各連絡先レコードの間には、ネイティブのリレーションシップ機能が組み込まれています。 必要に応じて、この関連付けを変更できます。 コンテキスト データ セキュリティについての詳細は、Power Pages のセキュリティ を参照してください。

最初のプロジェクトの推奨事項

開発と運用環境の分離

Power Pages では、各環境に複数のサイトをインストールできますが、新しい機能を作成してテストするために、運用環境とは別の環境を作成することをお勧めします。 詳細: ライブ移行チェックリスト

ユーザー テストの実施

内部関係者と初期の外部テスター向けに、安定したテスト サイトを作成することを強くお勧めします。 テスト サイトを使用すると、開発作業を微調整できます。

カスタム ドメインの保護

本番用にカスタム ドメインを作成することをお勧めします。 社内チームに連絡して、ライブ移行日の前に保護してください。

カスタム ドメインを設定するには、SSL 証明書が必要です。 詳細については、カスタム ドメイン を参照してください。

ライブ移行チェックリストの使用

サイトのライブ立ち上げを成功させるためのガイダンスとして、ライブ移行チェックリスト を作成しました。

参照

はじめに: Power Apps プロジェクトの計画