microsoftのログイン判断がちょっとややこしいので、開発環境を開くとき、現在と違うユーザやシークレットモードに入った方がいい
勉強材料Microsoft Dynamics 365 (CRM) &Power Platform Training (2023)
- 資格範囲MB200、コア部分は「dynamic365」と「microsoft power platform」、一般的に「functional certification」は基礎知識と画面操作メイン、つまり使用者向け；「technical certification」は開発者向け、コーディングやデータベスの知識も必要

目次：

はじめに
Dataverse
relationships
views
- Introduction to Views
side map
field types
form types
Business Rules
Security
reporting
- Charts
- Dashboards
powerBI
processes
power automate(microsoft flow)
data management
- import data wizard
- duplicate decation
- auditing
search capabilities
- Search Capabilities and Categorized Search
localization
- language
- field translation
Solution
- Solution
portal
- Provisioning a Portal
- PowerApps Portal Studio

Dynamics 365 and PowerApps紹介

Dynamics 365 appsはmicrosoftが作った、デフォルトの機能アプリ（sales、customer service、ERPなど）、PowerAppsは使用者自身が作るカスタムAPP（common data service＝CDS）
Dynamics 365 appの無料試しの申請URL、アカウント作成後
環境が準備されたら、環境名クリックし、入った後URLをクリック、サービス一覧画面に入る。「Dynamics 365 — custom」には他すべてのサービスが入っているもの

power platform紹介

power apps ＆ dynamic３６５（common data service）：アプリ開発用
- power apps画面 : make.powerapps.com)
power automate（microsoft flow）：ワークフロー作成或いは機能一体化
power BI：レポート作成とデータ分析
power view agents：BOT(ボット）などの自動化処理（客対応チャットなど）の開発
追記：
- もしpower appsにログインの時、以下のようなエラーが発生し（エラー内容：dynamic365サービスを申し込んだアカウントは現在の組織に存在しない）、ログインできない場合。新しいブラウザを開き、或は「シークレットブラウジング」モードでpower appsにログイン
- power app設定画面の言語を選択

power platform admin center

Components of Dataverse

dynamic365のデータ名詞と従来のデータベースの名詞の比較：
・entity == table
・attribute == column
・record == row
・relationship == relationship
「solution」は各設定（データベースの設定、組織設定、コード、ダッシュボード、セキュリティロール、など）を一つのパッケージに入れ、他環境へ反映できる、salesforceの「変更セット」用途と似ている。
- make.powerapps.compower apps画面でテーブルに入る

Creating Solution and Publisher

開発の時、直接「defult solution」を弄るのは避け、プロジェクト開始前、「customize solution」一個作成し、開発段階では、defult solutionから内容をcustomize solutionに追加し、そしてカスタマイズ。

publisher
solutionの所有者を表示、普通は会社名を使用。一個のsolutionには一個のpublisher必要。publisherはprefixを提供、awsの「tag」と似ている。以下は新規publisher作成画面

Solution新規作成の時、デフォルトの設定上「パッケージの種類」は「unmanaged」
作成後、solutionは空白状態、「既存を追加」機能でdefult solutionから内容を追加できる、環境既存の資材を編集の場合、ここで追加し、さらにカスタマイズ
- 例として、既存の取引先と取引先責任者を追加、混乱を避けるため、「全て」（項目、他オブジェクトの関係、格式、など）を選択
- オブジェクトを新規（データベスに新しいテーブルとデフォルトのcolumnを追加）の場合「新規」をクリック

Creating a Model Driven app

Customizing an Existing Table

データ種類

テーブルに列（field）を追加

レコードの表示画面をカスタマイズ

フォームをカスタマイズ時の注意点
- ブラウザの画面が狭い場合、プロパティを二列を設置しても、画面上表示できない場合がある。正しく表示する為、ブラウザを広くにする

creating a relationship

ブラウザの開発者モードで、参照関係にマウスを乗ると、参照先recordのdivが表示される

例として、「Expense Request」と「Expense Item」の１：Nの関係をを作成

「Expense Request」のrelationship設置画面で「一対多」を選ぶ、或は「Expense Item」画面で「多対一」を選ぶ

保存すると、「Expense Item」テーブル上、「Expense Request」recordを参照するattributeが作成される

「Expense Request」のフォーム上、「コンポーネント」の「サブグリッド」で関連先を追加

「Expense Item」のフォーム上、テーブル列を直接画面に追加

作成済みのrelationshipを公開するには、relationship画面の「テーブルを公開」をクリック、この場合、フォーム上の変更も一緒に公開される

relationship behaviour

relationship種類によって、提供する「action」も違う

referential（参照）、この種類はrecord間の所属関係がない（No cascading）
parental（親子）、この種類はrecord間の所属関係がある（cascading）、親record変更されるとき、子recordにも影響がある。
例えば親recordが削除されると子recordも削除される、親recordが別ユーザにアサインされると子recordもアサインされる
custom
- cascade active（active状態の子recordのみ影響を受ける）
- cascade all
- cascade none
- remove link（親recordが削除されると、子recordとの関係をたつ）
- restrict（子record持つかぎり、親recordを削除できない）
- cascade user owned（現在のユーザが所有している子recordのみ影響される）

設定画面

例として、「Expense Request」record中に「Expense Item」recordを持つ時、「Expense Request」recordが削除できない様にする。削除以外の動作には影響を受けない

Relationship Mapping

mappingがあるrecord間では、内容もある程度共有できる。
例えば取引先record画面で、取引先担当者新規の時、住所が自動入力される

mappingを設置するには、classicUIに切り替え、

例として、「Expense Request」record画面で「Expense Item」を新規の時、「Title」項目が自動入力するの設置


特定のテーブルを公開する

Hierarchy Relationship

テーブルはsalf relationshipを持つことができる、例えば取引先には親会社と子会社の関係を表示


テーブル「Location」を作成、salf relationshipを設置


設定後、階層を表示するとエラー出た、これは階層表示用のフォームが設定されていないため、classicUIに入り、階層表示用フォームを作成


「保存」と「公開」を忘れずに

N to N relationship

例として学生とコースの関係はN：N、この場合両方のテーブルを参照用の結合テーブル追加する必要がある（この結合テーブルは直接アクセスしない）。

Connections and Connection Roles

「Connection」を使って、テーブル間でrelationship作成せず、関係性を持たせる。主に既存relationshipの上に、更に関係性を表示する為使う

１：N relationship
テーブル間で関係性が存在するのを表示だけ、具体的どんな関係なのかを説明しない、例えば同じ会社（１）下の各社員（N）のそれぞれの関係を表示出来ない。
Connection（つながり）ではテーブル種類に縛られず、より柔軟的関係性を表示

connection（つながり）の種類を追加したい場合、「接続ロール」で追加

Introduction to Views

viewsの種類

personal（ユーザ自身で設置する）
system（「Solution」の中で設置できる）
- public
- Non-public

例として、「Expense Request」の二つ公開viewをカスタマイズ


viewをデフォルト表示にする

検索欄では特定の項目しか検索できない。
同時に、”*”でwildcard検索できる

検索できる項目を追加するには、「簡易検索ビュー」で設置、だが項目多いほどシステムが遅くなる、特に「discription」項目を設定しないように

一般ユーザもフォルダーでrecordを整理し、自分用のviewとして保存。

関連された別のテーブルrecordの項目も検索出来る

side map

アプリの左側で表示される内容を追加の場合、solutionの中「サイドマップ」を設定、画面表示範囲はエリア（赤）⇨グループ（緑）⇨サブエリア（青）になる

field types

standard（default）
calculated field（values、dates、text）
- 例とし計算出来る「Due Date」項目を追加
  
  
  「Due Date」の値を”作成日＋5日”に設定
roll up field（関連されるrecordの総計値を計算する：sum、min、max、count）
- 例として、「Expense Request」の「Total Amount」に関連された「Expense Item」の「Item Amount」の合計にする
- 設置完了後、「Expense Request」recordに合計値が計算されるまで時間が掛かる、手動で計算する場合「再計算」をクリック。
- もし反応がない場合、それは「通貨」種類が決めていないため、「通貨」項目をフォームに追加、正しい通貨種類を選ぶ（組織言語設定により、通貨の表示名が変わる）。保存後もう一回「再計算」を押す
  
  
  個人持つrecord全体的に通貨を設定する場合、「個人設定」に入り、通貨種類を設定。注意必要のは、設定修正前作成されたrecordでは「通貨」が空白のまま
- 自動計算などの詳細を見たい場合、「詳細設定」画面に入り、「設定」のプールダウンで「system jobs」をクリック
  
  
  定期実行のリストで計算jobをクリック、現在定期実行のスケジュール変更の機能が除去されたかも、或は開発者バージョンだけ変更できないかも

form types

main form
- record新規の時表示される、表示されたい内容によって、複数のmain formを作成できる（salesfroceのレコードタイプとページレイアウトとの関係に似ている）
- 例として、「Expense Request」に社員とマネージャ向けの二つformを用意する。「main」フォームをベースに修正後、コピーを保存。フォームが誰に表示すべきかを設定。そして「テーブルを公開」を忘れず
quick create form
- 文字通り早めにrecord作成時のフォーム、最小限の必要項目を入力だけ
- 先ず該当テーブルの簡易作成フォーム機能を有効化
quick view form
- 現在表示されているrecordに関連するrecordの内容を表示用フォーム
- 例えばrecord所有者の名前だけ表示される
  
  先ず「Solution」にユーザテーブルを追加、ユーザのメールと上司の簡易表示フォームを作成。Expense Requestのフォームに入れる
card form

Business Rules

コードなしで業務ロジックを設計出来る（salesfroceのフローと似ている）。

例として、もし取引先担当者の「婚姻区分」項目が”単身”の場合、その人の「記念日」項目を無効化にする。

左上の条件欄をクリック、「ルール」に条件入力、「適用」クリックと、右下には条件が表示され

「コンポーネント」欄から「ロック」をTRUEの結果へドロップ。「記念日」項目をロック、FALSEの結果に「ロック解除」動作を入れる



名前を入れる、検証、保存し、有効化する
上記ルールの上、もし「記念日」には既存の値がある場合、「婚姻状況」が”単身”のなる場合、その値を削除し、同時に無効化にする。
先ずはルールを無効化、そして「記念日」無効化動作の前に、「フィールド値の設定」動作を追加、「記念日」の値を削除
例として、取引先担当者作成の時「携帯番号」と「メールアドレス」少なくとも一つが必須。
- 「必須項目の設定」を追加、「メールアドレス」が空欄ではない場合、「携帯番号」は必須ではない、そしてこの「必須項目の設定」コピーペーし、作業量を減らす。
- 保存し、「携帯番号」ベースのルールをもう一個作成
ビジネスルールの作用範囲
- all forms OR single form（フォームによって、範囲を決める、client side only）
- entity scope（client sideとserver side両方作用される）
- recordはブラウザ画面操作以外（APIなど）も作成出来るので、「entity scope」の方が一番穏便

adding user

基本各ユーザに権限を持つ「role」を振り分けてで、アクセス出来るデータの範囲をコントロール。
ユーザのマネージメントはoffice 356(microsoft 365)レベルで発生し、Azure active directoryが処理を行う。

admin centerに入る
- このadmin.microsoft.comで自分が持つすべてのサービスを管理出来る
ユーザを新規

使用したいサービスのライセンスを上げる

注意必要なのは、ここのroleはMicrosoft365のroleで、dynamic365のroleではない。一般ユーザにはadmin権限を付与しない様に。
- もしMicrosoft365の管理者を作成したい場合、「global administrator」の権限は一番rootユーザに近い。ほかの権限はほぼサービス毎分けている
  
  dynamic365のadminユーザも作成できる
確認し完了
- Microsoft 365 admin centerでユーザ作成後、且つPower Appのライセンスがあるのを確認
  
  powerAppの環境に該当ユーザを追加、これでユーザがdynamic365のアプリをアクセス出来る
  
  
  
  新規できたユーザ名を入れる

Users and Ownership

ユーザroleの設置、roleが無いユーザは有効化出来ない、ログインもできない
テーブル作成の時、record所有権について設置出来る、「組織」の場合、recordはそれぞれのユーザではなく、組織に所有される

Business Units

business unitは会社の部門と似ている、会社の機能やロケーションをベースに、いくつのbusiness unitを分ける。ユーザがそれぞれ自分のunit（部門）に所属べき

設置方法
- admin.powerplatform.comに入り、目標環境の「設定」に入る
- 「business unit」を選択、デフォルト状態は組織のroot unit（orgnization）のみ
- root unitをクリックし、新しいunitを作成
- root unitの下に二つunitを作成
ユーザをunitに追加
- 該当環境の設定画面に入り、ユーザ設置画面へ移動
  
  ユーザの所属unitを変更

Introduction to Security Roles

Security Rolesはいくつの権限を含め、ユーザがSecurity Roleをもらった後で、Security Role内すべとの権限がユーザに付与される（salesfroceの権限セットと似ている）。
Security Rolesは二種のprivilegesがあり、record-level privileges（recordのcreate、update、shareなど）、task-based privileges（メース送信、組織設定の変更など）

設置方法
- dynamic365の設置画面に入り、セキュリティ設置画面に入り、Security Rolesをクリック
  
  一般的、roleを新規の時、既存のroleコピーし、それをベースに修正

Deep Dive into Security Roles

level of access（組織内、特定テーブルのrecordについて、該当権限がどのレベルで制限されているか）
- user level
  - 例として、各ユーザが、自分が所有している取引先recordを見れる
    
    ユーザは取引先record新規できる、そして自分が所有しているrecordを見れる、でも削除出来ない
- business unit level
  - 例として、同じ部署（Business Units）に所属の他ユーザ所有しているrecordを見れる
- parent-child business unit level
  - 同じ部署と該当部署の子部署のrecordも全て見れる（salesforceの上下ロール関係の効果と似ている）
- organization level
- none-no privileges given
  - 例として、現在組織内の全てユーザが、取引先recordを作成する権限が無い

teams

チームもroleを持っている

recordの所有者もチームに設置出来る

owner team
Azure Active Directory Group team
access team
- 該当recordは誰に共有しているのかを分かりやすく表示する為、access team templateを使用
- 黙認設定上、テーブルはaccess teamを許可していないので、先ずこの機能をONにする
- 目標テーブルフォーム画面に追加

Field Security

特定のfieldをアクセス出来るかどうかをコントロール。

特定のfieldのfield securityをONにする
Solutionの画面に入り、「field security profile」を作成
作用対象のユーザやチームを入れる。
profileで管理しているfieldを確認、このprofileにあてたユーザやチームはfieldの内容が見れない

Hierarchy Security Manager

HierarchyはSecurity roleやField Securityの補充機能として使う、機能上二種類があり

Manager Hierarchy
例として、階層は「director → マネージャー → 社員」になり、マネージャーが自分下の社員所有するrecordを閲覧編集削除出来る、directorが自分下のマネージャー所有するrecordを閲覧編集削除出来る、だがdirectorが社員所有するrecordを閲覧でき、編集削除出来ない、みたいな機能が欲しい場合


有効化後、ユーザrecordの管理タブに「上司」項目を設定できる
position Hierarchy
効果としてManager Hierarchyと似ているが、position Hierarchyはユーザ毎上司を設置するではなく、いくつのpositionを用意し、ユーザにこのpositionに充てて、そしてposition間の関係で、誰か誰のrecordを見れるのかを管理する
- 先ずposition HierarchyをONにする
- positionを作成、関係を指定

Charts

chartはdynamic365とpowerBI両方から作成できる。
viewと同じ、system用とpersonal用両方がある。

例として、system chartを作成
月毎のTotal Amountを見るための図を作成（「Total Amount(基本)」の意味は”基準通貨を使用”、ユーザの設置による通貨単位の違いを避けるため）。
もっと複雑の図を作成の場合、powerBIを使用

Dashboards

二種類があり

global dashboard(at the solution level)
- 複数テーブルに属するchartを表示できる
- chartと関連のviewを追加（chartはviewのデータを見せるためのもの）
- webページを追加出来る
- アプリに追加、実際の画面に表示されるため、Solution全体をpublish
entity dashboard(interactive dashboard)
- 該当テーブルに属するchartを表示のみ
- 例として、「customer service hub」のダッシュボードを見る（tableau CRMと似ている、chartを動的にfilterを追加出来る）
- 例として、取引先テーブルにdashboardを作成
  
  
  streamを追加し、常日新しいrecordを表示
- テーブル毎dashboard作成の場合、一個だけのstreamは作成出来ない
- テーブル毎のdashboardはテーブルの画面内しか表示出来ない

powerBI

powerBIはビジネス分析サービス、dashboardやreportなどを提供
free版の試し教材

Introduction to Processes

type of processes

action
busniess process flow
workflow

workflows

workflowを新規

既存のworkflowから作成の場合、「テンプレート」を選ぶ
- scopeはこのworkflowの動作範囲を決める、例えば「ユーザ」を選択の場合、このworkflowは作成者のみ起動出来る。
  一般的にはシステム管理者のみworkflowを作成出来るので、「組織全体」を選択
例として、取引先recordが作成された時、ownerにそれを確認のtaskを投げる
- 先ずtaskのrecordを作成
  
  作成されたrecordのプロパティを設定
- 保存し、有効化
- 取引先新規後、taskが作成される
workflowの動作の「同期（realtime）」や「非同期（background）」を変換できる
workflowのlogを見る場合

Email using Workflow

例として、employeeがExpense Request作成の時、managerに通知メールを送信

受信先を該当recordの所有者の上司に設定

メール内容を設定

アプリの中で、「活動」のテーブルでworkflowなどの記録が見える
例として、Expense Requestの「status」変更された時、「approval date」を更新
- triggerになる項目を選択
- 条件確認
- 注意必要のは。先ずこのラインをクリック、そしてステップを追加する。そうしない場合上層操作の追加になる

power automate

part of power platform
online workflow & intergration service(can take data from one APP to another App) to automate tasks
power app内の場所
アプリ
connector、他アプリとの接続
flowを作成


一つのflowの中、複数のtriggerとactionを含め出来る。
例として、手動でflowを起動し、dynamicの中でrecordを作成
dynamic365の機能は放棄されたため、使えない。代りに「dataverse」を使用

import data wizard

supported files (zip maximum 32M, others maximum 8M)
- .csv
- .txt
- .xml
- .zip
- .xlsx
dynamic365アプリ内データインポート
Power Platform内データインポート

duplicate decation

重複チェック、例えば営業員が取引先新規の時、もし新規内容の名前と住所が既存のrecordとの重複がある場合、作成を制限する。

重複チェック機能有効化と無効化設定
ルールを追加や変更
重複チェックのjob、jobを使って、既存のデータの重複をチェック出来る

auditing

組織内データの変更を追跡、logに保存。

how to enable auditing
- enable at orgnization or instance level
- enable at entity(table) level
  - automatically enable attributes of the entity

Search Capabilities and Categorized Search

types of search in CDS

quick find
現在いるview内のrecordで検索
advanced search
multi-entity quick find(categorized)

検索entityの追加
relevance search（20230817時点提供されない）
デフォルトは無効、先ず有効化必要。relevance searchはAzure Search Serviceにベースした

language

「基本言語」と「基本通貨」は組織(instance)作成の時選び、そして変更できない。変更できるのはユーザ個人interfaceの言語のみ

使用可能な言語を設定（用意するまで30分くらいかかる）
ユーザ個人の言語設定

field translation

APP levelの翻訳をダウンロード

テーブル（entity）の翻訳

Solution

solution is a group of configurations / customizations of CDS components.

default solution
- すべてのCDS（common data Service）のコンポーネントを持つ
- 直接default solutionの変更は推奨しない、custom solutionを作成そして変更
- 資材が多すぎ、変更内容の追跡が困難
managed solution
- 開発完了のsolution、分配とインストール用
- rollbackできる
- 目標環境に導入後、変更不可にするのは出来る（managed properties）
- 削除される場合、中身の資材も環境から削除される、つまりrollback
unmanaged solution
- custom solution作成の時、デフォルトはunmanaged
- このsolutionをexportし、別の環境に移行可能。移行後、目標環境内もこのsolutionが変更可能
- 一般的、development環境間でunmanaged solutionを使用、test、UAT、predation環境へmergeの時、managed solutionを使用
- rollback出来ない

小さな追加やbug修正を他環境へ反映したい場合、solution patchを使用

portal

websiteみたいなもの、外部ユーザはcontactとして保存される

powerAPP portal = dynamic365 portal
dynamic365やPowerAppへアクセスする為に、ライセンスが必要
外部ユーザへデータ共有や入力の時、portalを使用、ライセンス不要

二種類のportal

dataverse starter portal
portals within environment with customer engagement apps

Provisioning a Portal

dataverse starter portalを作成

作成出来るまで20分ほどかかる


作成できたwebsiteを管理

PowerApps Portal Studio

websiteを編集にはPortal Studioを使用