PowerAppsとSharePointを連携するとき、ユーザー型の列に入力する方法でつまずくことがよくあります。特に「テキストとしてメールアドレスだけをPatchしたらエラーが出た」などの経験をお持ちの方も多いのではないでしょうか。実はSharePointの「ユーザー」列は、単なる文字列ではなくレコード（オブジェクト）として扱わなければならないため、少しコツが必要になります。今回の記事では、実際に発生したエラーとその解決方法をベースに、Patch関数でSharePointのユーザー列を正しく更新するためのコード例を紹介します。コード内にコメントを入れながら分かりやすく解説しているので、後任者にも伝わりやすいはずです。PowerAppsとSharePointの連携をスムーズに進めたい方や、ユーザー列の設定で悩んでいる方は、ぜひ参考にしてみてください。
エラーが発生した背景とポイント
PowerApps側からSharePointリストへデータを登録しようとした際、SharePointのユーザー型列に文字列だけを渡すとエラーが出やすいです。たとえば「USER1」や「USER2」といったユーザー型の列へ、Selected.Mailだけを代入しようとすると、SharePointは「ユーザー情報が足りない」と判断してエラーを返すことがあります。
ユーザー列を扱うときには、SharePointが求めるレコード構造を持たせた上でPatchしてあげる必要があります。Patch関数で以下のようなレコード（@odata.typeやClaimsなど）を正しくセットするのがポイントです。
SharePointのユーザー列に必要なレコード構造とは
SharePointのユーザー列（People or Group列）にデータを渡す場合は、下記のようなフィールドを含むレコードをセットする必要があります。
{
'@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
Claims: "i:0#.f|membership|<メールアドレス>",
Department: "",
DisplayName: <表示名>,
Email: <メールアドレス>,
JobTitle: "",
Picture: ""
}
主なフィールドの解説
- @odata.type
SharePointに対して、ユーザー情報を表すレコードであることを示すためのキーです。定型的に「#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser」と入力します。 - Claims
SharePointがユーザーを特定する際に使う文字列です。形式は"i:0#.f|membership|"の後ろにメールアドレスをつなげるイメージになります。 - DisplayName
ユーザーの表示名。Office 365ユーザーコネクタで取得したDisplayNameなどをセットします。 - Email
メールアドレス。Selected.Mailなどの値を使います。 - Department / JobTitle / Picture
部署名や役職、プロフィール画像URLなどに相当します。必要があれば該当する値を設定しますが、なければ空文字（””）でも問題ありません。
Patch関数でエラーを解決するコード例
実際に、PowerAppsでSharePointリストのユーザー列へ新規レコードを追加する際に使用したコード例を示します。今回のサンプルでは、ComboBoxコントロールで選択したユーザーを取得し、エラーなく登録できるように修正したコードを紹介します。
下記のコードは、SharePointリストの「AAAAA」というテーブルに対し、title（TITLENAME）やユーザー列（USER1、USER2）をPatchするものです。それぞれのユーザー列に適切なレコード構造を設定している点がポイントです。
OKButton:
Control: Classic/Button@2.2.0
Properties:
// ボタンの色・デザイン設定は省略していますが、必須プロパティのみ残します
OnSelect: |-
// Patch()関数でSharePointの「AAAAA」リストに新規登録する処理
Patch(
AAAAA,
Defaults(AAAAA), // 新しいレコードを作成
{
// TITLENAMEはTextInputの内容をそのまま文字列で代入
title: TITLENAMETextInput.Text,
// USER1列（ユーザー型）にはレコード構造をセット
USER1: {
'@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
// Claimsには「i:0#.f|membership|<メールアドレス>」の形式を指定
Claims: "i:0#.f|membership|" & USER1ComboBox.Selected.Mail,
Department: "",
// ComboBoxで選択したユーザーの表示名をDisplayNameにセット
DisplayName: USER1ComboBox.Selected.DisplayName,
// 同じくメールアドレス
Email: USER1ComboBox.Selected.Mail,
JobTitle: "",
Picture: ""
},
// USER2列（ユーザー型）にも同様のレコードをセット
USER2: {
'@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
Claims: "i:0#.f|membership|" & BBBBBComboBox.Selected.Mail,
Department: "",
DisplayName: BBBBBComboBox.Selected.DisplayName,
Email: BBBBBComboBox.Selected.Mail,
JobTitle: "",
Picture: ""
}
}
);
コメントのポイント解説
- // Patch()関数で～
後任者がどの処理を見ているかをひと目で把握できるように、コードブロック冒頭に概要コメントを入れています。 - // USER1列（ユーザー型）には～
SharePoint側でユーザーを認識させるために必要なレコード構造をまとめて書いています。ClaimsやDisplayName、Emailに何を入れているか明確になるよう心がけます。 - // USER2列（ユーザー型）にも～
もう1つのユーザー列にも同じ形式でレコードをセットしていることを伝えるコメントです。後任者が「なぜ同じ形式なのか」を理解できるよう、簡潔にまとめています。
コード修正で気をつけたいポイント
ここまでの修正を行えば、ユーザー列でエラーが起きることはほぼ解消されます。ただし、以下のような点にも注意してください。
ComboBoxが返す値の確認
ComboBox.Selectedが想定するフィールドを持っているかを再度チェックする必要があります。- 「Mail」や「DisplayName」は、Office 365ユーザーコネクタ（Office365Users）を使って検索した場合に返される代表的なフィールドです。もし別のデータソースを使用している場合は、取得できるフィールド名が異なる可能性があります。
Blank()やNull対策
- ComboBoxでユーザーを選択していない状態だと、
SelectedがBlank()になることがあります。 - そのため、実運用上は「必須入力」にするか、もしくは
Selected?などを使って安全にアクセスする方法を検討するのもおすすめです。
SharePoint側の列設定
- ユーザー列は、SharePointのリスト設定で「複数のユーザーを許可する」設定にしている場合や、グループ型として管理している場合は別途検証が必要です。
- 単一ユーザーのみを許可しているなら、今回のようなコード構造でスムーズに登録できます。
まとめ
PowerAppsとSharePointを連携するとき、ユーザー型の列に対して文字列だけをPatchしてしまうとエラーが発生しやすいです。エラーを解消するには、SharePointが期待するレコード形式を明示的に指定してあげる必要があります。今回紹介したコード例のように、@odata.typeやClaimsなどのフィールドを正しくセットすることで、問題なく登録できるようになります。後任者が見ても分かりやすいようにコード内にコメントアウトで説明を入れるのも大切なポイントです。ぜひ実装や保守の参考にしてみてください。
コメント