実践 Dynamics 365 サービス概略(5) PowerAppsサンプルアプリ

今回はPowerAppsのサンプルアプリを作ってみたいと思います。

前段で触れたとおり、承認のモバイルアプリを作ってみたいと思います。

まずは、想定する業務をまとめておきます。
利用者は営業部とします。
営業担当者が顧客訪問をして認識した案件を登録・管理していくシーンとします。
販売するものはDynamics365導入サービスのようなサービスを想定します。
導入サービスの販売は物販と比較して以下の特徴があると考えます。
・案件規模が大きく、検討が長期化しやすい。
・提案活動に営業以外の部門が関わるケースが多く、提案コストが肥大化しやすい。
このようなことが想定されるため、提案活動の初期段階では案件を評価するというフェーズを設けることが多くなります。

今回は営業担当者が案件を評価し、その内容を営業マネージャが承認するという業務を想定したいと思います。

まずはDynamics 365(CRM)の画面を説明します。
capture20170110134048471

営業案件の画面を少しカスタマイズしました。
左の列は案件の全般情報であり、真ん中の列が今回承認してもらう内容です。右の列はその承認情報です。

業務の流れは、営業担当者は承認者を選択して保存すると承認者にメールが送信され、
その内容を営業マネージャが承認するというものとしました。
メール送信や承認履歴の情報はワークフロー(プロセス)を利用しています。
この点のカスタマイズやExchange Online連携の設定方法は割愛します。

さて、具体的なPowerAppsアプリの作成をしてみたいと思います。
PowerApps管理機能はDynamics365の試用環境をオープンすると同時にランチャーに表示されます。
capture20170110140909224

PowerAppsをクリックするとPowerApps管理画面に遷移します。
capture20170110141039110

この画面から中央の「作業の開始」をクリックします。
capture20170110141221645

PowerAppsの開発環境を選択します。右のWeb(ブラウザ)バージョンにしてみます。
数分で以下の画面が起動します。起動しない場合はIEなどのブラウザに変更してみてください。
capture20170110141632717

Dynamics 365の「電話番号レイアウト」をクリックし、「接続」をクリックします。
capture20170110143535790

接続するデータセットの設定画面が表示されます。
Dynamics 365を選択し、組織名(ここではmasa201701)をクリックします。
capture20170110143630812

テーブルの選択画面が表示されます。
Dynamics 365(CRM)のどのエンティティを処理するのかを選択します。
ここでは、承認履歴を選択します。
※承認履歴エンティティは営業案件と1:Nの関連をもつエンティティとしています。
capture20170110143947349

PowerApps Studioでアプリのビルドが始まります。
capture20170110144035293

ビルド直後画面が以下です。
左のペインには3つのフォームが表示されています。
上から、ビュー上の表示、フォーム上(読み取り専用)の表示、フォーム上(編集用)のフォームのようです。
capture20170110144359453

まずは「ビュー上の表示」をカスタマイズしてみたいと思います。
右のペインのオプションから別のレイアウト選択してみました。フォームの表示内容が変更されます。
capture20170110144618766

右のペインの「”テキスト”」プルダウンをクリックすると、フィールドの一覧が表示されます。
これを選択していきます。ワークフロー(プロセス)の設定方法に似ています。
capture20170110144808575

既定の4フィールドに対し、フィールドをマッピングします。
マッピング時の注意は以下です。調べれば回避策はあるかもしれませんが、初見ではわかりませんでした。
・修正日は選択できないようです。
・選択したエンティティ以外の項目はエンティティ同士が関連していても選択できません。
・lLookup項目はGUIDが表示されます。値を参照することはできません。
※Lookup項目の値参照はこちらにヒントがありました。

事前に何かデータを作成しておくと、サンプルデータが表示されます。
capture20170110155635480

次に「フォーム上(読み取り専用)の表示」をカスタマイズしてみたいと思います。
左のペインの真ん中を選択します。
capture20170110161001575

フィールドを変更したいと思います。
目のアイコンで表示/非表示が切り替えられます。表示の上下はドラッグアンドドロップで変更できます。
ボタンアクションですが、削除のボタンをなくしました。
※本来はボタンワンクリックで処理をするようにしようとしましたが、初見ではうまくいきませんでした。
capture20170110172310072

最後に「フォーム上(編集用)のフォーム」をカスタマイズしてみたいと思います。
「フォーム上(読み取り専用)の表示」と同じように変更が可能です。
処理項目は「承認」のみですので、「承認」フィールドのみを表示させます。
capture20170110172641330

カスタマイズは以上です。色々テストしながら進めて、3時間程度で完成しました。

できたアプリケーションは保存が必要です。ファイルタブをクリックし、「名前をつけて保存」します。
capture20170110173302062

このアプリの共有(公開)範囲を設定します。
アプリから共有を選択します。
capture20170110173456874

利用させたいユーザーを追加します。
capture20170110173602540

では動作を確認してみたいと思います。
モバイルのアプリをダウンロードし、アプリケーションを起動し、認証情報を入力します。
image1image3

 

 

 

 

 

 

 

アプリケーションが表示されるのでタップします。
image2

 

 

 

 

 

 

 

承認一覧画面が表示されます。以降はイメージだけ添付します。
img_0019image5image6

 

 

 

 

 

 

 

結果として、Dynamics 365(CRM)上では以下のようなイメージにすることができそうです。
capture20170111124347976

以上、PowerAppsでサンプルアプリを作成してみました。
あくまでサンプルということで色々省略しているところはありますが、それなりのスピード感でアプリが作成できることが分かりました。
次回はFlowでデータをつなげてみたいと思います。

実践 Dynamics 365 サービス概略(4) PowerApps/Flowサービス概要

今回はPowerAppsとFlowの製品概要に触れてみたいと思います。

まずは製品サイトに触れておきたいと思います。
多くの情報はありませんが、こちらにラーニングコンテンツがあります。
実際にアプリを作成する際はこちらを参考にするのがよいと思います。
次回以降で作成するサンプルアプリに関してもこちらを参考にしました。

続いて資料ベースでサービス概要を説明をします。
capture20170110105759353
※Microsoft Tech Summit 「PRD011 | ノンコーディングで業務アプリを作る PowerApps + Microsoft Flow 解説」 link

これまでの投稿で触れたとおり、様々なデータに対してUIを作成できます。

capture20170110111707447
capture20170110112007311
※Microsoft Tech Summit 「PRD007 | CRM + ERP = Dynamics 365 が遂に登場!
PowerApps と連携した迅速な業務アプリ構築手法」 link

①PowerApps Studioという開発プラットフォームで開発を行います。
Webブラウザ版とアプリ版が提供されます。
②PowerApps Cloudというクラウド環境にアプリケーションは保存されます。
③PowerApps Web/Mobileという環境で実際の操作を行います。

capture20170110112648763
capture20170110112832009
※Microsoft Tech Summit 「PRD007 | CRM + ERP = Dynamics 365 が遂に登場!
PowerApps と連携した迅速な業務アプリ構築手法」 link

実際の作成画面のイメージは上記のような画面で行います。
操作の多くが選択式となっており、コンセプト通りに簡易機能をスムースに作成できそうです。

capture20170110113527560
link

アプリケーションは上記からダウンロードできます。
一番右のデータゲートウェイは、オンプレミスにあるシステムとのデータ連携時に利用するアプリケーションです。

以上、サービス概要に触れてみました。
次回はPowerAppsでサンプルアプリを作ってみたいと思います。

実践 Dynamics 365 サービス概略(3) PowerApps/Flowの位置づけ

今回はDynamics 365リリースに伴い、新たに提供された「補助サービス」から
PowerAppsとFlowについて記載してみたいと思います。

なぜこれらのサービスが提供されたを類推しつつ、位置づけにふれてみたいと思います。

これらのサービスが登場する背景には2つの変化への対応があったと考えます。

1点目は「Salesforce1の登場」です。
※Salesforceの記述は記憶に頼っているところが多くあります。記述は必ずしも正確ではありません。
これはPowerAppsの登場に影響を与えたものであると思います。

PowerAppsはノンコーディングでUIを作成するプラットフォームです。
同様にSalesforce1も開発プラットフォームです。Dynamics 365の競合製品であるSalesforce.comのモバイル開発プラットフォームです。
2013年頃にリリースされ、モバイルのユーザービリティの向上に貢献していると思います。
特に、スマートフォンでの利用シナリオでかなり限定的シーンでの活用を推奨しています。

例えば、スマートフォンでの承認機能です。

ボタンクリックでの処理が簡易に実装できるようになりました。
また、承認すべきデータも様々な機能を持たせるのではなく、シンプルな表示を推奨しているようです。
自分の承認すべき一覧だけを表示させ、スマートフォンでのユーザービリティを向上させています。
ユーザーは迷うことなくシンプルに直感的に処理がスマートフォンで業務を行える環境を手に入れることができるようになりました。

PowerAppsはSalesforce1に対抗すべく位置づけられたサービスであると思われます。
故に実装すべきUIは複雑性があるものではなく、スマートフォンで操作可能な範囲の業務をシンプルで直感的な形で、
コーディングが不要な範囲でマクロが使えるようなITパワーユーザーの範疇において迅速に実現すべきものであると捉えています。
複雑な処理に関しては従来通り、ブラウザや高度なアプリケーションベースのリッチ画面機能を利用していくべきだと捉えています。

2点目は「クラウドサービスの浸透」です。
従来型のソフトウェアとクラウドサービスの大きな違いは、提供されるサービスの成長だと考えます。
従来のソフトウェアは買い切りの形式をとり、メーカーは販売を中心に考えます。
一方クラウドサービスは課金の形式をとり、メーカーは利用継続を中心に考えます。
長期的な利用の継続を推進するには、サービスそのものの魅力向上が不可欠です。
故にクラウドサービスにおいてはサービスの成長がより促進されます。

しかしながら、サービスの成長は容易ではありません。
1つの機能の拡張は、他の機能との不整合を引き起こす可能性を孕んでいます。
機能を追加する場合、十分なテストが必要となります。

従って、クラウドサービスの1モジュールはシンプルで小さいものになる傾向があります。
多機能を搭載する際には、より開発スピードと不具合リスクの低減するため、サービスを独立させます。

このようなサービスを業務で利用するには「使いやすいように使う」「つながるようにする」ということが求められます。

メーカーを超えてよりシンプルな機能のサービスが乱立した状況では、それぞれのメーカーが考える標準UIと
それぞれのメーカーが考えるUI拡張機能が提供されます。
「使いやすいように使う」には「共通的な操作で使う」ことと「使いやすいUIで使う」ことが必要となります。
PowerAppsはこれに対応するUI開発プラットフォームです。

メーカーを超えてよりシンプルな機能のサービスが乱立した状況では、そもそもサービス間のつながりがありません。
少なくとも自社で抱える従来型のソフトウェアやスクラッチのシステムとは、つながりが考慮されてません。
業務が高度化する一方でシンプルな機能の成長だけを期待してサービスを利用し続けるのは
変化への対応が遅れてく一方です。そこで、サービス間をつなぐ必要がより求められています。
従って、「つながるようにする」ことが必要となります。
Flowはこれに対応するデータ連携及び自動化のサービスです。

以上、サービスの位置づけについて触れてみました。
次回はPowerAppsとFlowの製品概要に触れてみたいと思います。