User関数のEmailはUPN メールアドレスと異なるケースがあるのでOffice365 ユーザーコネクタを使用がベター

はじめに

Power FxのUser関数で取得できるEmailは正確にはUPN(User Principal Name)です。
テナントによりUPNとEmailは異なる場合があります。以前から記事内でちょこちょこ書いたりもしていましたが、今更感がありますが今回の記事ではその点に絞ってご紹介します。

User関数

Power Fxで使用できるUser関数についての公式記事は以下です。
User 関数 – Power Platform | Microsoft Learn

User関数ではログインユーザーの以下の情報が取れます。(2024/8時点)

  • Email      →UPN(メールアドレスと異なるケースあり※テナントの設定による)
  • EntraObjectId  →ユーザーオブジェクトID。Dataverseのユーザー列のAzureActiveDirectoryObjectIdと一致
  • FullName    →氏名(テナントの設定により性、名が反転するケースもある、DisplayNameとは異なる)
  • Image       →ユーザーの画像。M365で登録しているプロフィール画像

公式より抜粋
以下にもUser().Emailで取れるのはメールアドレスではなく、UPNと明記されています。

編集画面で選択できる項目は上記の通り

User関数はログインユーザーの情報を取得できるのでよくサンプルアプリの実装などでも出てきますね。
ただ、テナントの設定によってはメールアドレスとUPNが異なる場合や表示される名前が性、名が反転しているケースなどがあります。

User().EmailはUPN(User Principal Name)

公式にも書いてありますが、User().Emailで取得できるのはUPN(User Principal Name)です。

UPNとは「Active Directoryなどのディレクトリサービスでユーザーを一意に識別するための名前です」
ユーザーを一意に特定するためにはこのUPNが使用できます。

テナントの設定によってはメールアドレスと異なる場合があります。
※基本のドメインとしてUPNがあり、異なるドメインでメールアドレスが設定されているなど

SharePointのユーザー列のEmailはメールアドレス

SharePointをデータソースとした場合、ユーザー列をよく使用しますが、ユーザー列から取得できる情報は以下です。
このうち、
・EmailアドレスはUPNではなくメールアドレスの方です。
・Claimsというのは認証用に利用されるものでこの中にはUPNが含まれた文字列となっています。

・DisplayNameもテナントの設定によってはUser関数のFullNameと異なる場合もあります。
※FullNameは性、名をテナントの設定の順で並べて表示したもの(英語環境だったりすると逆になっていたりする)、DisplayNameは姓名とは異なるものを指定しているケースもあります(日本語名+ローマ字にしていたり)

SharePointのユーザー列で取れる情報
・Claims
・DisplayName
・Email
・Department
・jobTitle
・Picture 

SharePointのユーザー列から取得した情報

SPOのClaimsについて

Claimsは以下のような構成となっています。
ユーザーの場合は、「i:0#.f|membership|<UPN>」です。

アプリでユーザー列に登録する情報を作成する場合などにも使いますね。
→この場合はUPN=User().EmailなのでUser関数で取れる値を使うで問題ありません。

SPOの場合に影響するケース

影響するケースとして、ユーザー列のEmailを使ってログインユーザーを特定する処理などです。
ユーザーのメールアドレスを文字列で保持している列を使う場合もそうですね。

前途したとおり、テナントの設定によってはメールアドレスとUPNは一致しません。
そのため、ユーザー列のEmailやそれを文字列で登録されている場合に、User().Emailで取れるUPNと異なり正しい判定が出来ないケースがあります。

TIPSメールアドレスとUPNが一致しているテナントの場合であれば一致するので気にしなくてもOKです。
ただ将来的に変更される可能性を考慮すると以降に記載するOffice365ユーザーの情報を使うのが安全です。

Office365 ユーザー コネクタを使用

Office365 ユーザー コネクタであれば、UPNもメールアドレスもそれぞれ取得出来ます。

Office 365 Users – Connectors | Microsoft Learn

このコネクターを使用して取れる値の詳細は上記公式をご参考ください。
UPNとメールアドレスについては以下となります。displayNameもあります。

NOTE取れるプロパティ(属性値)はすべて小文字始まりです。DisplayNameではなくdisplayName、
Emailではなくmailとなっています。UPNはuserPrincipalNameとなっています。

自分のテナント(個人用)ではメールアドレスとUPNはおんなじです。なのでUser().Emailを使った実装でも問題はありません。

ただ、通常の企業のテナントだと異なるケースがままあります。
なのでいずれにしても自分がアプリを作成する場合は必ずOffice365ユーザーコネクタを使用して構成します。そのほうが今は良くても将来変わったときに影響が出ることがないからです。

Office365 ユーザーコネクタ OnStartで自分の情報をキャッシュする

Office365 ユーザーコネクタでユーザーの情報を取得するのは良いのですが、自分の情報を使用する場合に
実装の利用箇所で都度利用するのはお勧めしません。
その都度コネクタへのアクセスが発生してコール数がかさむ点とパフォーマンス低下があるためです。

ユーザーの情報というのは頻繁に変更はされません。そのため、アプリの起動時にアプリに保持(キャッシュ)して利用するのがベターです。この点は公式のパフォーマンス観点の記事にも推奨として記載されています。
ヒントとベスト プラクティスを使用して、キャンバス アプリのパフォーマンスを向上させる – Power Apps | Microsoft Learn

NOTE※自分の情報を利用する場合です。他のユーザー情報を取得する際は都度利用するでOKです。

以下にコネクタの追加およびOnStartで変数に保持するサンプルを記載します。

コネクタの追加

データの追加>データソースの選択で「Office」とまで打てば、「Office 365 ユーザー」コネクタが表示されるので選択します。
次に接続を指定します。既存があればそれを選択、なければ接続の追加から追加します。
データの一覧に追加され利用できるようになります。

OnStartで変数に保持する

最近はApp.Foumulasというのがありますが、こっちはアプリへ保持(キャッシュ)するのではなく、最新を参照するため、データソースへつなぐ場合は都度アクセスが走ります。(正確に検証はしていませんが)Office365ユーザーコネクタの場合も同様と思われるので、キャッシュする目的としてはOnStartで定義するのが良いです。

App.OnStartに以下のように実装(変数名は任意)

CodeSet(o365User,Office365ユーザー.MyProfileV2());

OnStartを実行して確認

編集画面でOnStartを動作させるため、Appの…メニューからOnStartを実行しますをクリックします。

変数にマウスを当てると下に内容を表示できます。また、変数のビューレコードからも確認出来ます。

変数>ビューレコードをクリックして一覧での確認

使用例:自分のレコードのみをフィルター

上記の実際の使用例としてはUser.Email(UPN)を使っている部分を変数.mailに差し替えるとなります。
また、FullNameを変数.displayNameに差し替えもOKです。

SPOの登録者が自分のレコードのみを取得するフィルターを書く場合は以下のようになります。

CodeFilter(ナレッジ共有リスト,登録者.Email = o365User.mail )
※User().Emailから変数.mailに変更した例

Dataverseのユーザー列特定の場合

Dataverseのユーザー列に対して自分を特定する場合はUser関数のEntraObjectIdが使用できます。
この値はユーザー列が保持しているAzureActiveDirectoryObjectIdと一致します。
メールアドレスは電子メールアドレスという列で保持していますが、IDは確実に一意なのでこちらを使うのがベターです。
SPOの場合はこのIDに相当する列は取得できないのでこの値は活用できません。

おわりに

ということで今更ながらUser関数とOffice365 ユーザーコネクタの違いや実装について記事にしました。
シンプルなサンプルアプリの実装例ではUser関数を使用しているケースも多いですが、実際の企業テナントの場合ではUPNとメールアドレスが異なるケースはそこそこありますし、将来的に変更がある可能性もあります。
そのため基本的にはOffice365 ユーザーコネクタを使用してUPNとメールアドレスは別のものとして使用するのがベターだと思います。また利用する場合はOnStartでキャッシュする方法がパフォーマンスの観点でもよいですね。
モダンのヘッダーでも初期値ではUser().FullNameやUser().Emailが設定されていますが、Office365ユーザーのdisplayNameやmail、その他にも部署などに変更することも出来ます。
それぞれの違いを知ってケースバイケースで使いましょうー。それでは!

この記事は役に立ちましたか?

もし参考になりましたら、下記のボタンで教えてください。

ヨウセイ

ヨウセイ

一般職からSharePoint、C#、.NET系技術者へ、そこからPower App、Power Automate技術者へと転身。 ワンランク上のおっさんはPower Appsでシステム開発が出来る〜! qiitaや自社HPでも技術ブログを書いていました。

関連記事

コメント

この記事へのコメントはありません。

CONTENTS