実践 カスタマイズ (2) フォームカスタマイズ

フォームに関して記述する。

フォームとは原則データの作成や変更を行う画面である。

フォームの種類は以下の画面のように4種類存在する。

それぞれ複数作成することができ、ユーザーが保有するセキュリティロールごとに表示すること可能である。

20140825_001

■ メイン

ビュー上のボタンの[新規]をクリック時に起動するメインの画面

■モバイル

iphoneなどモバイルアクセス時の画面

■簡易作成

一部のレコード作成時に利用可能な画面。表示項目を限定し、

簡易に一時保存できるようにすることを目的としていると思われる画面。2013から登場。

■簡易表示フォーム

1意に確定する関連するエンティティ上での表示画面。

取引先企業フォーム上に取引先担当者エンティティの取引先責任者というフィールドが関連して存在する。

通常、取引先企業フォーム上には取引先企業エンティティのフィールドしか配置できないが、

この機能を利用することで、取引先担当者の電子メールフィールドなどを表示することが可能となる。

 

ここでは、[メイン]のフォームのみに関して記載する。

このフォームのカスタマイズをすることが大半であるためである。

フォームのカスタマイズの大半はフィールドレイアウトである。

タブとセクションで区切りをつくり、その中にフィールドを配置するようなイメージであることは

自習書などで理解していると思う。機能としてはこれ以上のものは特にない。

そこで、ここではレイアウト配置のコツに関して記載したいと思う。

 

■全体配置

きれいに見せたい。2011までのフォームであれば、2列もしくは3列表示と適度なタブ区切りによって

ある程度きれいに見えるような配置が可能であった。しかしながら2013のフォームで

単純に上記のようなレイアウトを行うと縦長かつ空間が多くなり、かなり間延びしたようなものになる。

20140825_002

※画像は2011からアップグレードした場合の画面そのものである。空白が多く、

スクロールバーを見るとかなり縦長となっていることが分かる。

いくつかの案件やデモ環境作成を通じ、私は以下をルールとした。

・標準画面と同じく1タブ3セクション配置

左列はエンティティのフィールド、中央はフロー的関連情報(投稿、活動)、右列はストック的関連情報

このように配置するとそれなりにきれいに見える。

20140825_003

・スクロールをしないレイアウト

1画面に収まる程度であれば問題ないが、エンティティのフィールドが多い場合は1画面に収まらない。

この場合はタブで区切る。遷移方法は最初のタブをクリックして閉じることで移動する。

下図の[概要]がタブ箇所。[概要]をクリックするとタブが閉じられ、[詳細]が現れたように見える。

このようにレイアウトを配置するとスクロールをしなくて済む。

20140825_004

ただし注意すべきは解像度である。

上記のレイアウトでも解像度が異なれば、下記のように1画面に収まらないことがある。

必ずどの解像度をベースとするかを決定しておくべきである。

20140825_005

■エンティティのフィールドで主要なものは、デフォルト表示画面に表示できる数を上限にする。

上記例では[取引先企業番号]から[説明]までである。10フィールド程度となり、かなり少なく感じるが、

よく検討すると概要として閲覧すべき情報はこの程度に収まることが多い。

また、これ以外に必要なのものは例のとおり、タブを区切って配置する。

失格[詳細]はセクションを3列に区切り、利用単位(部署など)もしくは業務プロセス単位(受注前、受注後など)にする

フィールドが多い場合は情報単位で集めておくときれいに見えると共に、利用者としても情報にたどりつきやすい。

■[レイアウトの幅][フィールドラベル幅]の調整する

2013のフォームは2011で存在していた左側の関連ナビゲーションが削除された分、

横にスペースを確保することができる。これを考慮せず、3列配置をすると

ラベル幅とフィールド幅のバランスが悪くなることがある。

このような場合はタブの[レイアウトの幅]とセクションの[フィールドラベル幅]の調整を行う。

・タブの[レイアウトの幅]

%指定でタブ内のセクションの幅の割合を決定する

20140825_006

・セクションの[フィールドラベルの幅]

セクション単位でフィールドにおける表示ラベル部分の幅をピクセルで設定する。

現在の値より小さくするとラベル幅が狭まり、入力フィールドが広がる。

20140825_007

 

■過剰にセクションを設けない

思った以上にきれいなレイアウトは困難であるため。矛盾を覚悟に記載するが、

解像度を定義したところでユーザーのディスプレイは様々である。

当然、変更を依頼されることもある。

解像度の定義は相手の要求を100%受け入れなくてもよいようにする程度のものであり、

一定のものは受け入れる必要が発生するのが一般的である。

この際に、融通が利かないほど複雑な設定をしているとどうにもならなくなってしまう。

また、セクションはレイアウトバランスを崩す原因となりがちである。

例えば、[■全体配置]で添付している画像の[住所]箇所は2列、3列、2列という定義がなされている。

2011ではセクション間は通常のフィールドどおしと同じくらい詰めて表示されていたが、

2013ではセクション間に(もう少し詰めてもらいたいような)微妙な空間が設けられた。

結果、間延びしたレイアウトとなっている。

■情報の単位は縦にまとめる。

セクション内のタブ遷移(Tabキークリック時の遷移)の仕様が縦であるためである。

横への遷移させたい場合は1行毎にセクションを区切ればよいが、

・手間である

・2013からはセクション間に微妙な空間が存在する

というような理由から推奨しない。顧客と議論をし始めると受け入れざるを得ない状況にも

なる可能性があるため、そもそも議論が発生しないように導くのがよいであろう。

マスタデータのようなフィールドが少なくなりがちなエンティティのフォームでは、

従来は上から詰めて3行で配置するようなことが一般的であると思われるが、

2013では左列だけ利用するようなものであるとトランザクションデータのエンティティとの

統一感が取れてよいかもしれない。

 

以上、ベストプラクティス的な内容を記載した。

特別技術的というものではないが、これらを念頭においてフォームデザインをすると

きれいに素早くレイアウトを完成させることができるのではないと思う。

次回はビューに関して記載する。

実践 カスタマイズ (1) 前提知識の整理

新しいテーマである。

ここからはカスタマイズに関して記載する。

カスタマイズに関してすべてを記載することはむずかしいため、

以下のように記載をしていきたいと思う。

 

まず、一通りの操作を知っているという前提にしたいと思う。

これに関しては以前紹介した、以下の自習書の内容を実施してもらいたい。

http://technet.microsoft.com/ja-jp/cloud/crm_learning

[カスタマイズ編]参照

この程度のレベルの知識がある前提で、「私はいつもこうしている」という視点の内容を記載する。

フォーム、ビュー、エンティティ、フィールドのカスタマイズを本テーマとして扱ってみる。

 

Dynamics CRMの1つの「エンティティ」は大きく2つの画面で構成されている。

・データを検索するための読み取り専用の一覧画面である「ビュー」

・データを操作するための作成/編集画面である「フォーム」

また、1つのエンティティにはそのエンティティの情報を構成する情報項目として「フィールド」が存在する。

Dynamics CRMのカスタマイズはデフォルトで存在するエンティティであるシステムエンティティ及び

自由に追加できる新規エンティティであるカスタムエンティティに対して「ビュー」「フォーム」「フィールド」

の作成/(レイアウトの)変更/削除を行うことができる。かなり柔軟なカスタマイズを製品としてサポートしている。

 

ただ、幅広いカスタマイズサポートの一方でその基本機能は限定されることがある。

注意が必要なことは多くあるが、原則としてはまず下記を念頭に置くべきだと考える。

・表示は1意として確定できる関連エンティティを含む2エンティティまで

・作成/更新/削除は該当1エンティティまで

2エンティティ以上同時に何かをする場合には注意が必要というようなイメージでもよい。

詳しくはそれぞれのカスタマイズの中で触れようと思う。

 

上記の制限をクリアするためにはどうするか。

①その他のカスタマイズ可能な機能を検討する(ワークフローや業務ルールなど)

②簡易な開発を行う(JavaScriptによるコーディング)

③より複雑な開発を行う(C#やVBによってコーディングされたプログラム機能をPlugin機能で差し込む)

④全く別なロジックとしてスクラッチアプリを作成し、データを操作する

このようなことが考えられる。

①から順に標準的機能から遠ざかるとと共に複雑性が増すと一般的に捉えられている。

したがって、原則①から順に実現性を検討すべきである。

 

なお、言葉の定義であるが、以下をルールとしている。

カスタマイズ:Dynamics CRM画面上でノンコーディングで行える変更や機能追加

開発:JavaScriptやC#などによるコーディングを伴う機能追加。

以上。

【Tips】評価環境の製品化

バックアップ、リストア、新環境構築というテーマがひと段落した。Tipsを投稿したいと思う。

 

インフラ構築のカテゴリーでは、SQL Server、Dynamics CRMのインストールを行った。

ここでは製品のライセンスキーを利用するものではなく、試用版を利用した。

しかしながら、実際の案件では当然のことながら製品版を利用するため、

ライセンスキーを入手するまでの一時的な対応という位置づけである。

そもそも、前者で180日、後者で90日の試用期間が存在するため、永久利用はできない。

 

試用版のプログラムと製品版のプログラムは何が違うか。

Microsoft関連のサイトを確認したが明確な記述は見当たらなかった。

私としては、以下のように理解している。

・製品版ライセンスキー適用前は、利用期限が存在し製品版と同じかそれ以上の機能を搭載

・製品版ライセンスキー適用後は、そのライセンスキーのエディションの製品版と同じ機能が提供される

 

まずSQL Serverに関して記述する。

SQL Server 2012の評価版は「evaluation」という1つエディションとして提供される。

Standard用、Enterprise用というものは存在しない。

つまり、evaluationで大半(*)の機能が評価できるというものである。

*厳密にはDatacenterエディション、Enterpriseエディション程度。含まれていない部分の記述なし。

http://msdn.microsoft.com/ja-jp/library/cc645993.aspx

「SQL Server Evaluation・・・」から始まる[注意]参照

Dynamics CRMはSQL Server Standardエディションをサポートしているため、

evaluationでDynamics CRMまで構築し、後にSQL Server Standardエディションのライセンスキー

を適用するというのがよくあるパターンである。

当然、Enterpriseエディションもサポートされるため、こちらを利用してもよい。

例えば、可用性を高めるため、Always Onを構築する場合はEnterpriseエディションを利用する。

実際の手順はリンクだけとしたい。以下のサイトを参考にさせて頂いた。

http://msdn.microsoft.com/ja-jp/library/ms144267.aspx

http://engineermemo.wordpress.com/2012/08/25/sql-server-%E3%81%AE%E8%A9%95%E4%BE%A1%E7%89%88%E3%81%8B%E3%82%89%E8%A3%BD%E5%93%81%E7%89%88%E3%81%B8%E3%81%AE%E7%A7%BB%E8%A1%8C/

 

次にDynamics CRMである。

こちらはそれぞれのエディション用の評価版キーが存在する。

プログラムは1つであり、それぞれのキーを利用することで評価段階から

そのエディションの範囲での機能評価が行えるものである。

以下、製品化の手順を記載するが、その前に簡単にエディション差異に関して触れておく。

Dynamics CRMオンプレのエディションはWorkgroupとServerが存在する。

Workgroupの機能概要は以下のとおりである。

・5ユーザーまで

・シングルテナントのみ

・CRM機能を分散インストールすることができない

他にも存在するかもしれないが、この要件でほぼエディションが確定する。

5ユーザーまでという点が厳しいため、過去1件のみがWorkgoupエディションであり、

その他はServerエディションである。

Serverエディションは上記の逆であり、制限がないと考えてまず問題ない。

 

以下、製品化手順である。

Dynamics CRMがインストールされているサーバにcrmdom\crmadminでログインし、

[展開マネージャ]を起動し、右ペインの[プロダクトキーの変更]をクリック

20140822_001

プロダクトキーを入力し、[適用]をクリック。OKや完了などなく、画面が閉じられる。

20140822_002

実際に製品版のキーが適用されているかを確認する画面が見当たらない。

一応、下記で確認できるので参考にされるとよいと思う。

SQL Server Management Studioを起動し、[MSCRM_CONFIG]の[ConfigSettingsProperties]を右クリック

[上位1000行の選択]をクリック

3行目の[NVarCharColumn]を確認する。

試用版プロダクトキー利用時は下記。試用版プロダクトキーが表示されている。

20140822_003

製品化した場合は下記。同箇所に製品版のキーが表示されている。

20140822_004

以上。

実践 Dynamics CRM環境運用 (8) アップグレードを伴う組織のインポート

今回は少しおまけ的な内容である。

「アップグレードを伴う組織のインポート」と記載したが、

要するに2011バージョンから2013バージョンへのアップグレード手順である。

運用上、1つの顧客で頻出するテーマではないため、利用することはあまりないと思われるが、

組織のインポートでできることというトピックスに関連するものとして記載をしておく。

実際に実行する場合は当然のことながら十分なテストを計画すべきである。

アップグレードに伴い、様々な機能の改廃が行われており、すべてが正常にアップグレードされる

保証はどこにもない。プラットフォームは移行できたが一部の機能が利用できない

というようなことが発生し得るということを計画に組み込むべきである。

 

環境は下記のとおり。

移行元環境

OS:Windows Server 2008 R2

SQL:SQL Server 2008 R2

CRM:Dynamics CRM 2011 UR16(2011というエンティティを作っておく)

ドメイン:移行先環境とは別

※アップグレードは1つ前のバージョンからのみ実施可能。

※2013へのアップグレードは2011UR16移行がサポートされる(2014年8月時点の日本語版最新の実装ガイド)。

イメージは下記

20140820_001

手順は以下のとおり。

・移行元環境でDBのバックアップ(同じ手順であるため省略。「CRM2011_MSCRM.bak」で取得)

・移行先環境でDBの復元

・組織のインポートの実行

 

・移行先環境でDBの復元

SQL Serverのバージョンが異なるため、正常に復元されるか気になるところであるが、

私の環境では前回投稿の手順で問題が発生しなかった。同じ手順で問題が発生する場合は

CRMというよりSQL上の問題である可能性が高いため、SQLの問題としてトラブルシュートを

実施するとよいかもしれない。

手順は若干割愛しながら記載する。

「CRM2013_MSCRM」として作成するため、2011箇所を2013へ

20140820_002

20140820_003

正常に成功。復元時間も私の環境では1分以内。

20140820_004

・組織のインポートの実行

[展開マネージャ]から[組織のインポート…]をクリック

20140820_005

インポート可能なDBが存在する場合、デフォルトで情報がセットされるのは、前回のケースと同様

20140820_006

表示名を変更

20140820_007

20140820_008

20140820_009

ドメインが異なる場合は失敗する。ユーザー情報が異なるので当然のこと。

[OK]をクリックするとマッピング画面へ遷移

20140820_010

[新しいユーザー]箇所を選択し、[参照]をクリック

20140820_011

管理者アカウントを入力し、[OK]をクリック

20140820_012

警告に関してはとりあえず無視。[次へ]をクリック

20140820_013

[インポート]をクリックするとインポート処理が実際に開始されるのも同じ

20140820_014

20140820_015

私の環境だと処理時間は30分程度。

20140820_016

実際の画面は以下のとおり。

20140820_017

以上。

実践 Dynamics CRM環境運用 (7) 【新機能】SDKツールを利用したデータ移行

このテーマを記載している途中にリリースされてしまい、投稿間の整合性がとれなくなってしまった。

SP1環境(以降。おそらく)で利用可能なSDK でデータ移行ツールが提供された。

ソリューションファイルの移行ではなく、データが移行できるツールである。

Dynamics CRMにおいてデータを移行するツールは、標準機能として、「インポート」がある。

データ移行ツールは「インポート」の上位ツールのようなイメージであり、

複数エンティティのデータを一度にインポートできる。

この点のメリットが大きいのだが、2014年8月時点のツールでは少々バグが含まれている可能性がある(後述)。

また、インポート機能でもそうであるが、Lookup設定がされているプライマリフィールド値は

ユニークである必要がある。名前の解決ができないという点は同じである。

以下で手順と注意点を確認していく。

なお、詳細は中村さんのブログを参照させて頂いた。

http://blogs.msdn.com/b/crmjapan/archive/2014/08/13/dynamics-crm-2014-sp1-sdk-3-configuration-migration-tool-2.aspx

 

■ダウンロードサイト

http://www.microsoft.com/ja-jp/download/details.aspx?id=40321

■ツールのパス

SDK\Tools\ConfigurationMigration\DataMigrationUtility.exe

■環境

Dynamics CRM Online上に以下の2つの環境を作成

・masamt1:移行元

・masamt2:移行先

同じソリューションファイルを適用しておく。

■データイメージ

取引先企業

・プライマリフィールドに同値データを設ける

・取引先担当者とLookupするデータとする

・所有者を複数とする

20140820_101

取引先担当者

・アドベンチャー・ワークスと関連を持つ同値氏名のデータを作成(清岡)

20140820_102

■手順

[DataMigrationUtility.exe]を実行

20140820_001

[スキーマの作成]にチェックをいれ、[続行]

20140820_002

スキーマの作成:移行元のデータをエクスポートする手順に進む

データのエクスポート:[スキーマの作成]からの流れでエクスポートまで実行可能。実質不要。

データのインポート:[スキーマの作成]で作成したファイルを元にインポートする手順に進む

移行元の接続情報を入力し、[ログイン]をクリック

20140820_003

以下がデフォルト画面。すべてのデータをエクスポートする場合は[すべて追加]をクリック

20140820_004

エンティティが追加される。[保存してエクスポート]をクリック

20140820_005

ファイル名をつけて保存画面で保存すると(私は[solution.xml]で保存)下記画面が表示。[はい]クリック

20140820_006

[データファイルに保存]の[…]をクリック

20140820_007

[data.zip]などの名前を選択し、[データのエクスポート]をクリック

20140820_008

エクスポートが実行され、下記のように終了する。所要時間は1分29秒(最下部)。[終了]をクリック

※電子メールのエラーは不明

20140820_009

最初の画面にもどるので、インポートをする。[データのインポート]をクリック

20140820_010

移行先に接続情報を入力

20140820_011

[zipファイル]の[…]をクリック

20140820_012

[データのインポート]をクリック

20140820_013

データにユーザーが含まれる場合の警告。crmuser1を勝手に作成してくれるわけではない。

事前にユーザーを作成し、マッピングファイルでマップしておけば、移行できるはず(今回割愛)。

20140820_014

また、フィールドなどが異なる場合は下記のように失敗する。

20140820_015

正常に進むと以下のようなイメージ

20140820_016

20140820_017

20140820_018

[終了]をクリックし、実際のデータを確認。

取引先企業

・件数は正常に移行

・売上高(money型データ)は欠落

・エーデータコーポレーションの取引先責任者である金がなぜか移行されない。

※ただし、記載していないが、[重複データの検出]をオフにしている。この機能はインポート時にも実行される。

この機能がオンの場合1行目のアドベンチャー・ワークスはインポートされなかった。

20140820_019

取引先担当者

・清岡の1つが移行されない。Lookupが解決されなかったと思われる。

・金が移行されない

20140820_020

移行されないデータの理由は現時点不明である。

不具合のようなものかもしれないし、私の手順が悪いのかもしれない。

いずれにせよ、関連情報を維持しつつ簡易に移行ができるツールが(今後修正されながら?)

提供されるということは歓迎すべきことである。

この程度のものでも、Onlineのデモ用データ移行には使えるので私にはありがたい。

以上。

実践 Dynamics CRM環境運用 (6) 組織のインポート

今回は組織のインポートに関して記載する。

(3)で記載した2つ目の方法である。

 

まず、組織のインポートを説明する。

組織のインポートでできることは以下の2である。

・復元された現行バージョンのDBを元にテナントを作成する

・復元された2011バージョンのDBを元にアップグレードしつつテナントを作成する

機能から想像がつくとおり、この場合はDB情報をそのまま利用して新環境を作成する機能である。

ソリューション移行とは異なり、取引先企業レコードなどを移行することができる。

今回は前者に関して記載する。

また、バックアップ環境と復元環境のURが同じであることが前提として要求されることが多い

という点に注意が必要である。実行できない場合はインポート実行前のチェックでエラーとなるため、

事前に気づくことは可能である。

 

組織のインポートを実施するため、事前の準備として、下記を実施する。

移行元環境:[CRM]。取引先企業とユーザーエンティティにレコードを追加しておく。

※ユーザーエンティティの[氏名]はAD上の値と別に変更しておく。

20140818_001

20140818_002

 

手順は以下のとおりである。

・SQL Management Studioで[CRM_MSCRM]のバックアップを取得する(画面ショット省略)

・SQL Management Studioで[CRM3_MSCRM]としてDBを復元する

・展開マネージャで組織のインポートをする。

 

・SQL Management Studioで[CRM3_MSCRM]としてDBを復元する

[データベースの復元]をクリックし、以下の画面を起動する

20140818_003

[デバイス]にチェックをいれ、…をクリックし、バックアップファイルを参照すると下記画面のようになる

20140818_004

[移転先]>[データベース]を以下のように「CRM3_MSCRM」に変更する。

20140818_005

左ペインの[ページの選択]>[ファイル]をクリック

20140818_006

データベース関連ファイル名を以下のように「CRM3_MSCRM」に変更する。

20140818_007

[OK]をクリックし、実行する。成功を得る。

20140818_008

以上

・展開マネージャで組織のインポートをする。

[展開マネージャ]を起動し、左のペインから[組織]をクリックし、右のペインの[組織のインポート…]をクリック

20140818_009

 

インポート可能なDBが存在する場合は以下のように自動的に情報がセットされる

20140818_010

デフォルトではバックアップファイルの組織名(この場合「CRM」)となる。

新しい組織名に変更する(この場合「CRM3」)

20140818_011

20140818_012

組織のインポートならではの設定。ユーザー情報の移行方法に関して。

ここでは、最も簡易な方法である[ユーザーを自動的にマップする]を選択

20140818_013

自動的に下記のようにマッピングされる

20140818_014

20140818_015

以下の[インポート]クリックからインポート処理が開始。

20140818_016

20140818_017

私の環境では1分以内に完了。

20140818_018

画面の確認。まずは取引先企業。きちんとデータが存在する。

20140818_019

次にユーザー。データは存在しているが、crmuser1の表示名がAD情報になっている。

20140818_020

組織のインポート中、ユーザー情報に関しては、改めてADの情報を取得して反映しているものと思われる。

上記のように一般ユーザー名の場合も気をつけるべきであるが、キューを管理するユーザーであったり、

ダミーの所有者として作成したユーザーに関しては氏名を変更しているケースはかなり多い。

組織のインポート実施後にチェックと修正を忘れないようにしたい。

また、連携的な機能に関しては移行不十分となる可能性があることに注意したい。

レポートエンティティのデータを追加している場合、CRM環境が異なると

 

 

以上。

次回はアップグレードを伴う組織のインポートに関して記載する。

実践 Dynamics CRM環境運用 (5) ソリューション移行の注意

前回はソリューション移行に関して記載をした。

今回はソリューション移行時の注意に関して記載する。

当然これがすべてではない。まず注意するべき点と捉えて頂きたい。

 

・削除的な処理は行われない

・ビューの非アクティブは移行されない(反映されない)

 

以下の環境を準備し、[CRM]テナントから[CRM2]テナントへソリューション移行を行う。

移行元の[CRM]テナント:

・前回作成した取引先企業エンティティの[テスト]フィールドを削除する。

20140815_001

・[アクティブな取引先企業]ビューを非アクティブにする。

20140815_002

20140815_003

※非アクティブとはいわゆる論理削除。テーブル上は残るが、画面上からは非表示になるような設定。

 

この状態から前回投稿と同じ手順でソリューションファイルをエクスポートする(画面ショット省略)。

前回投稿と同じ手順で[CRM]にソリューションファイルをインポートする(画面ショット省略)。

少々分かり難いが結果は以下である。

まず、[テスト]フィールドであるが、下記画面上では非表示となっている。

[テスト]フィールドを削除した結果、ソリューションファイルの画面構成を決定する箇所において、

[テスト]フィールドが削除された状態でUpdateされたためと思われる。

20140815_004

しかしながら、フィールドは(物理)削除されていない。単純にフォームからはずされただけである。

例えば下記のようなフォームカスタマイズ画面を起動すると右下の利用していないフィールドに

[テスト]が表示され、存在していることが確認できる。

20140815_005

ソリューションのインポートは、ディレクトリ内に対するファイルの上書き的な機能である。

フォルダごと上書きコピーをするようなもの(削除を伴う置き換え)ではない。

これは、フィールドだけではなく、ビューやエンティティそのものでも同様のことが言える。

また、フォーム画面上からは削除されているため、一見すると物理削除されているように勘違いしがちである点も

注意が必要となるポイントである。

 

次に、非アクティブ化したビューであるが、これはバグと考えてもよいものである。

実際の画面は以下のとおりであり、非アクティブ化した[アクティブな取引先企業]ビューが表示されている。

20140815_006

実践的にはどのようなことが言えるであろうか。

一般的に標準のビューには運用上不要となるビューが存在する。

キャンペーン機能を利用しなければ、キャンペーンという文字列が含まれるビューは不要であり、

ユーザーには非表示となるようにしたいと考えるものである。

一方で、デフォルトとして存在しているものを物理削除するとパッケージとしての機能に何らかの

悪い影響を与えかねないと推測することはおかしいことではない。

つまり、デフォルト機能を物理削除をせずに論理削除をしたいという要望はよくあるケースである。

これに伴い、開発環境において、ビューの非アクティブ化をしたとして、リリース時にソリューションの移行を行う。

すると上記の現象が発生し、再度作業をする必要が発生する。

ソリューションの移行ではこの作業の回避はできない(少なくとも私は回避策をしらない)ため、

作業が発生することを認識し、スケジュールに組み込んでおく必要がある。

以上。

次回は組織のインポートに関して記載する。