通知を追加してアプリをコラボレーション可能にする

Microsoft Teams のアプリは、組織内の人々のコラボレーションを実現する目的で設計されています。 A グループが何かを行い、B グループがそれを処理するといった情報の受け渡しがあるアプリを例にすると、すべてがアプリ内で行われると、ユーザーが重要なアップデートを見逃したり、プロセスが滞ったりする可能性があります。

Teams のアプリで重要なイベントに通知を使用すると、注意が必要なことや実行する必要のあることをユーザーに積極的に通知できるため、コラボレーションを促進します。

チームや Power Platform では、たくさんの通知方法を用意しています。

  • 電子メール通知
  • SMS/text 通知
  • Teams のメッセージ
  • アダプティブ カード
  • チャネルの投稿

このビデオでは、通知を追加してアプリを連携させる方法について説明します。

適切な通知タイプを選択する

通知の種類はどのように決めればいいのでしょうか? 多くの人がメール通知を既定にしていますが、一方で「メールが多すぎる」という不満を持つ人も少なくありません。 電子メールは通知としては一般的ですが、慎重に使用する必要があります。 特に緊急の通知の場合、メールだとすぐに確認されない場合があります。

ここでは、適切な通知の種類を定義する際の質問についてご紹介します:

  1. 通知は緊急性を伴うものですか?

    安全上の問題を追跡するアプリを作成していて、すぐに対応が必要な緊急の問題がある場合、SMS テキスト、プッシュ通知、優先度の高い Teams メッセージなどの通知を使用して、通知をすぐに確認してもらう必要があります。 しかし、緊急性のない通知にこのタイプの通知を使いすぎると、ユーザーを苛立たせる危険性もあります。

  2. 通知は情報通知の目的なのか、それとも行動を促すものなのか。通知を作成する場合、通知を受け取った人にその通知を使って何をしてもらいたいのか?

    情報通知はユーザーに通知するものですが、あくまでも情報提供を目的としています。 例えば、Teams 用のサンプル アプリ テンプレート 「従業員のアイデア」 では、新しいアイデアが作成された時に、そのことを知らせるメッセージが Teams のチャンネルに投稿されます。

    実用的な通知により、受信者による 1 つ以上のフォローアップ活動が可能になります。 Employee Ideas を拡張する記事では、通知をアダプティブカードに変更し、ユーザーが提出されたアイデアを開いて投票できるようにする方法を紹介しています。

    通知によって、記録を開いたり、応答したりなど、ユーザーが何かできることが必要な場合は、インタラクティブ—カードなどの実用的なな通知を使用するか、アプリへのディープリンクにハイパーリンクを追加する必要があります。

    また、Teams—のチャンネルにメッセージを投稿すると、ユーザーはチャンネル内でそのメッセージに返信することができ、複数の人がその通知について話し合うことができるようになります。

  3. 通知は個人的なものですか、それともグループ向けですか?

    通知すべき特定の人はいますか? あるいは、その通知について知っておく必要があるグループがありますか? 個人的な通知については、メッセージ、電子メール、またはテキスト メッセージの送信を検討し、他のユーザーへの通知の過負荷を減らすことを心がけてください。 メッセージをグループ内の複数の人に通知する必要がある場合は、Teams チャンネルへの投稿が適しています。グループ内のユーザー全員がメッセージを見て、共同作業ができます。

  4. 通知の頻度はどうなっていますか?

    Teams の調査サンプル アプリ テンプレートは、既定では検査が完了すると Teams チャンネルにメッセージが投稿されます。 ただし、検査の頻度が高い場合は、たくさんのメッセージがチャネルに投稿されます。 また、1 つのチャンネルに多くの通知が投稿されると、個々の通知が消えてしまう場合があります。 携帯の通知センターを思い浮かべてみてください。—少数のアプリによる通知であれば便利ですが、たくさんのアプリが更新情報を通知してくると、通知はノイズになってしまいます。 このような場合、通知の内容を見直し、緊急の検査または問題についてのみ通知するように通知を変更する必要があります。

  5. ユーザーへの影響度はどの程度ですか?

    あなたの同僚は忙しそうで、—特に通知量が多い場合は、それぞれの通知がストレスになります。 通知は、重要な情報を便利に入手するためのものです。 ただし、頻度が高すぎたり不要だったりすると、悪影響を与える可能性もあります。 また、ユーザーがコントロールできない気まぐれな通知がたくさん届くようになると、—ユーザーのコントロール感を低下させます。 そして、苛立たしい思いを募らせる可能性があります。 ユーザーがアプリ内で通知をコントロールできる選択肢を検討してください。—通知を受け入れるかどうかを設定するトグルスイッチや、受信する通知の種類を選択する基本設定などが考えられます。 公報,の拡張例。

通知: Power Apps または Power Automate

通知の作成には、次の 2 つの選択肢があります:

  • アプリで通知を直接作成する。
  • あるいは、Power Apps フローをトリガーして通知を投稿する方法です。

どちらの方法を採用するかは、どのタイプの通知を使用しているか、どのように通知をトリガーするかによって決まります。 —アダプティブカードなどの通知タイプでは、Power Automate が必要となります。 メール、テキスト メッセージ、Teams チャネル メッセージの送信などのメッセージは、Power Automate の式、または Power Automate のフローから送信できます。 この質問には、正解も間違いもありませんが、考慮すべきいくつかのルールがあります:

  • フローのないアプリから直接送信される通知は、ユーザーがアプリで変更を行ったときのコンテキストで行われます。 つまり、ユーザーはメッセージを送信するサービスにアクセスする必要があり、メールなどのメッセージの種類によっては、個人のアカウントから送信される場合もあります。 サービス アカウントや一般的な通知メールボックスからメッセージを送信する場合は、Power Automate フローを別のユーザー アカウントで所有し、データの条件 (レコードの作成など) をトリガーとしてメッセージを送信できます。

  • フローが通知を送信し、アプリによって直接トリガーされた場合、フローをトリガーしたユーザーとフローを共有または割り当てる必要があります。 フローが通知を送信し、データ条件 (レコードの作成や更新など) によってトリガーされる場合、トリガーするユーザーがフローを共有、または所有する必要はありません。

  • 通知の送信に Power Automate を使用することで、アプリを再発行することなく通知を更新することができます。 通知内容が頻繁に変更される場合や、アプリの作成者以外のユーザーが通知内容を修正する必要がある場合は、通知を Power Automate で送信することで作業を細分化し、アプリの作業をしている間に他のユーザーが通知の作業をすることができます。

  • 通知を直接送信する Power Apps は、通知ロジックを定義するために数式を使用しますが、Power Automate のフローは、よりグラフィカルなインターフェースを使用して通知プロパティを設定します。 たとえば、Power Apps アプリから、次のような計算式で Outlook コネクタを使ってメールを送信できます:

Microsoft365Outlook.SendEmail("mailbox@contoso.com", Summary, Description)

Power Automate では、電子メールの送信アクションがグラフィカルに表示され、ユーザーは Outlook で電子メールを送信するのと同様の方法でフィールドに入力することができます。

Power Automate 通知

Power Apps から直接メールを送ることは、経験豊富な作成者にとってはてっとり早いですが、—添付ファイルやフォーマットされたテキストなど、より詳細な情報が必要になります。 経験の浅い作成者であれば、Power Automate フローの方が簡単かもしれません。

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。