Salesforce: Lightning ページレイアウトの設定

Lightningでのページレイアウトは、今まで通りのページレイアウトの指定と、Lightningレコードページで指定します。

今まで通りのページレイアウトの指定では次のような画面表示となります。

[詳細タブ]

[関連タブ]

① コンパクトレイアウトで指定した項目の表示
② 「モバイルおよび Lightning Experience のアクション」で指定した詳細ボタンとアクション
③ ページレイアウトでクイックアクションで投稿を指定した場合の表示
④ ページレイアウトの詳細項目
⑤ ページレイアウトのカスタムリンク
⑥ ページレイアウトの関連リストとリストボタン

①ですが、レイアウトの設定後にコンパクトを変更しても反映されませんでした。（反映が遅いだけですかね）再度、ページレイアウトを保存すると反映されました。

②は、LightningではJavaScriptボタンが使えません。カスタムボタンが使えないと勘違いしてました。

③は投稿のクイックアクションを指定しないと、フィード追跡が表示されるだけになります。

④は今まで通りです。

⑤はカスタムリンクもJavaScriptのリンクは使えません。

⑥の関連リストボタンもJavaScriptボタンが使えません。

最後に

JavaScriptボタンとJavaScriptリンクが使えないという点がインパクトがあると思いました。（Googleで検索すると、いくつか回避策がヒットしました）

基本的には、Visualforceボタンにすれば今まで通りに近いアプリケーションが作れると思いました。

ですが、１つのトランザクションではガバナ制限を超えてしまうため、JavaScriptボタンからカスタムWebServiceを何度かコールするという作りをする場合、JavaScriptボタンではなく、Lightningコンポーネントを使うのかなと勝手に考えています。

もうちょっと理解を進める必要がありそうです。Lightningコンポーネントは今までのVisualforceとは大分違うので道のりは長そうです。

Salesforce: Lightning オブジェクトの設定

Lightningではオブジェクトマネージャで、標準オブジェクトでも、カスタムオブジェクトもまとめて一覧表示する仕組みが追加されています。

LightningでもClassicでも、オブジェクトの作成と項目の追加に変更はありませんでした。
が、Lightningレコードページは、オブジェクトマネージャからでないと設定できませんでした。

後、検索レイアウトの、「タブ」「ルックアップダイアログ」「ルックアップ電話ダイアログ」の設定はLightningで使用する箇所はなく、「検索結果」のみ使用していました。

最後に

Lightningの設定ページや、オブジェクトマネージャは慣れるまで時間がかかりそうです。各設定で、ページ内の検索機能があるのは便利だなーと思いました。

ただ、オブジェクトマネージャの一覧表示で、添付ファイル(Attachment)や、ファイル(ContentVersion)などの内部のオブジェクトは表示されておらず、内部のオブジェクトにトリガを作成する場合は開発者コンソールやForce.com IDEから作成するのは今まで通りのようです。

Salesforce: Lightning experience を勉強したいと思いました

SalesforceのLightning Experienceに対して、見た目がかっこいいとか、カスタムボタンが使えないとかそれぐらいのイメージしか持っていませんでした。

（後、基本的にいやなのが、動作が遅かったり、Lightningの設定画面だけでは全ての設定ができないという点です。これでLightningに変える気になれていませんでした）

ですが、今後はClassicの機能追加が終了して、Classicの開発知識は陳腐化していくんだろうなーと思います。

そこで、Lightningを勉強しようと思います。

次のようないつものSalesforce開発をLightningで行えるようになりたいと思っています。

• オブジェクトを作成
• レイアウトを作成
• ビューを作成　
• 標準画面に詳細カスタムボタンを追加
• 標準画面の関連リストにリストボタンを追加
• ビューにボタン追加
• アプリケーションを作成

できればボタンの上書きとかVisualforce、Lightningコンポーネントも触って行きたいと思いますが目標は低めが好きなので、まず上記でやってみます。

trailbrazerやhelp & training 、色々なブログ情報などから情報を集めるところからスタートしようと思います。

Salesforce: プロファイルのリリースで気をつけたいこと

Salesforceで、モジュールのリリースはとても大変な作業です。

リリースの中で特にプロファイルのリリースは気を使います。

プロファイルをリリースする際の注意点をメモしておこうと思います。

変更セットでリリースする際は、プロファイル別にアクセス権が付与できるコンポーネントと一緒に変更セットを作成する

アプリケーション、オブジェクト、タグ、レコードタイプ、Apexクラス、Visualforceページ、項目レベルセキュリティといったプロファイルで制御できるコンポーネントとプロファイルを１つの変更セットにまとめることで、プロファイルのアクセス権とともにリリースできます。

ただし、変更セットでは標準オブジェクトとそのタブ、標準項目が選べません。ですので変更セットではリリースできず標準オブジェクトとそのタブ、標準項目は手動での設定となります。

サイトプロファイルのリリース

各環境でサイトの設定をした後サイトの公開アクセス設定からサイトのプロファイル画面に行き、プロファイルの名前を揃えます。

プロファイルの名前を揃えておけば、プロファイル設定をリリースできるようになります。

変更セットのプロファイルリリース時に、ログイン IP アドレスの制限もリリースされる

SandBoxと本番でIPアドレスの制限を変えて運用していることは多いと思いますが、変更セットでリリースするとIPアドレスの制限も一緒にリリースしてしまいます。

本番環境だけセキュリティを厳しくしている場合はこれは本当に困ります。

プロファイルはリリースせずに手動でプロファイル設定を行うことで対応できますが、リリースするコンポーネントでプロファイル制御する数（カスタム項目など）が多い場合、手動だと厳しい場合があります。

そういう時はプロファイルをデプロイ（IDEや、移行ツール）するのも１つの手かなと思います。手動で設定して間違えるくらいならプロファイルのメタデータxmlで不要な箇所を除いて（ログインIPアドレスの制限箇所をコメントアウトにする）デプロイの方が正確にリリースできます。

最後に

権限セットでアクセス権を付与することにすれば、項目権限(FieldPermissions)、オブジェクト権限(ObjectPermissions)はデータローダで設定できるようになります。

あまりに項目権限の設定が煩雑な場合は権限セットを使ってしまう手もあります。でも、プロファイルで正しく定義しておく方がオススメです。

Salesforce: 本番運用後に発覚しがちな制限

SandBoxで開発している時は気づかないけど、本番運用後にエラーになってはじめて気付く制限があります。

SandBoxではデータのサイズ制限があるので、開発時には気付くことはできないという

事情はあります。

でも、事情は関係なしにエラーがでれば不具合扱いなので避けたいところです。

以下に今後気をつけたい制限のメモを３つ程メモしておこうと思います。

ApexClassで、100,000件以上のオブジェクトをインデックス指定無しで検索する

ほぼ開発時には気付きません。データが溜まって初めて気付く制限の典型です。

日付や電話番号は外部IDでインデックス作成ができないのですが、顧客の特定で生年月日や電話番号で検索しがちなので気をつけたいところです。

※日付や電話番号の項目のインデックスは、カスタムインデックスの作成をSalesforce社へ依頼することになります

Visualforceで、<apex:repeat>の繰り返しの上限が1000

SOQLの取得件数は1000以上ですが、Visualforceの画面表示の上限が1000までです。StandardSetControllerや、カスタムでページング処理を使って対処します。

Visualforceのビューステートの制限

このエラーが出た場合、対処は困難を極めます（そもそもある程度大きい件数で多くの項目を入力したいという要件でこのエラーがでます）

表示項目にはtransientを指定したり、入力項目を減らしたり、入力項目の桁数を減らしたり涙ぐましい努力が必要になります。

最初からJavaScriptベースでVisualforceの開発をすることで回避できる可能性がありますが、そこまで戻れないのが実状だと思います。

最後に

バージョンアップで制限も変更となっていくのですが、今時点(Winter18)では以上が気をつけたいなーと感じていることです。

もちろんToo Many SOQLの対処などもありますが、これは発生頻度が高く開発時で気をつけるのが習慣となりつつあります。

昔は、SOQLで、子リレーションの副問合せで取得した子オブジェクトのレコード数の200件まで 制限があった気がしますが、今はなくなってるようです。（気のせいかもしれません）

あと、ガバナ制限ではないですが、ファイルが格納されている、コンテンツバージョン(ContentVersion)オブジェクトは、システム管理者でも全てのレコードを取得できないようになっています。後からAPIで取得したくでもできなくなります。（画面からはすべて参照できます）

なので、コンテンツドキュメントリンク(ContentDocumentLink)にトリガでデータを作成しておくようにしておくと良いと思います。

例えば、トリガで特定のchatterグループに全てのファイルをひもづけておけば、そのchatterグループに管理者をメンバーとすることで管理者は全てのファイルをコンテンツバージョン(ContentVersion)オブジェクトから取得できます。

後で、ContentVersionをAPIで操作する要件が見えているなら、トリガをあらかじめ用意しておくのがいいかなーと思います。

Salesforce: メールの文字コードについて

Salesforceからメールを送信する時の文字コードではまったのでメモです。

（はまったのはユーザ情報でメールの文字コードを「Shift_JIS」にしていたのに、送信されたメールで丸数字"①"などが化けていたという事象です。原因はメールテンプレートの文字コードが「JIS」でした。。）

Salesforceでは次の2箇所でメールの文字コードを指定することができます。

・メールテンプレートでの指定

・ユーザ情報での指定

上記で指定した文字コードがどのメール送信時に使用されるかは次のようになります。

メールを送る方法	使用される文字コード
ワークフローでのメールアラート	メールアラートで指定したメールテンプレートの文字コード
活動履歴関連リストのメール送信	テンプレートを選択した場合： 選択したメールテンプレートの文字コード テンプレートを選択しない場合： ユーザ情報のメールの文字コード
ケースの関連リストのメール（メールメッセージ）	テンプレートを選択した場合： 選択したメールテンプレートの文字コード テンプレートを選択しない場合： ユーザ情報のメールの文字コード
Apex Class Messaging.sendEmailでMessaging.SingleEmailMessageを送信する	setCharsetで文字コード指定した場合： 指定した文字コード setCharsetで文字コードを指定しない場合： ユーザ情報のメールの文字コード
SOAP API sendEmailでSingleEmailMessageを送信する	setCharsetで文字コード指定した場合： 指定した文字コード setCharsetで文字コードを指定しない場合： ユーザ情報のメールの文字コード

※Apex ClassとSOAP APIのsendEmailで、MassEmailMessageを送信した時の文字コードは未調査です。。

最後に

基本的に、メールテンプレートを使う場合はメールテンプレートの文字コードが優先されます。

日本語環境でSalesforceの設定を行うと、ユーザ情報やメールテンプレートの文字コードはデフォルトで「日本語(JIS)」が選択されています。

そのまま保存してしまうと、JISのためメール送信時に丸数字などが文字化けとなってしまいます。

特に、メールテンプレートを利用者が作成する運用を取る場合に気をつけないといけないなーと思いました。

でも、未だにメールのデフォルトがJISって1990年代の話のような気がして感慨深いものがあります。今ならUTF-8でもいいのではないかなーと思いました。

Salesforce: データの共有に関する設定箇所

Salesforceでは、あるレコードを参照できる人・できない人のセキュリティ制御が可能です。

標準機能のグローバル検索やビュー・レポートの結果も参照できるレコードのみで表示されるし、URLを直接変更されて参照できないレコードのIDを指定されてもアクセスできないようになっています。

そのレコードを参照できる人・できない人の設定は次があります。

共有設定

セキュリティ制御の代表です。「セキュリティのコントロール＞共有設定」で、

• 公開・非公開
• 階層を使用したアクセス許可
• 非公開にした場合の共有ルール（所有者ベース・条件ベース）

が可能です。

階層を使用したアクセス許可をすると、ロール階層で、より上位の人はアクセスできるようになります。

取引先や、商談、ケースなどは階層を使用したアクセス許可のチェックが外せないので、そのレコードを参照できる人の上位ロールの人にはレコードが参照できるようになっています。

どうしても、取引先や、商談、ケースなどで上位のロールの人にアクセスさせたくない場合、

1. 公開グループ（グループAとする）を用意する。
2. グループAの「階層を使用したアクセス許可」のチェックを外す
3. レコードの参照・編集権をグループAに付与する
4. あるユーザ（ユーザ甲とする）には参照させたいけど、ユーザ甲の上位ロールのユーザには見せたくない場合、ユーザ甲をグループAのメンバーにする。

という制御が可能です。（これは、取引先や、商談、ケースだけでなく、階層を使用したアクセス許可にしつつ、階層を使用したくない時があるオブジェクトで有効です）

ロール

商談やケースを非公開にすると、ロール作成時に共有設定とは別のアクセス権の設定が可能です。

最初は商談やケースを公開にした状態で開発を進めていき、途中から非公開に変更した場合に、この設定を忘れやすいので注意です。

取引先チーム・商談チーム・ケースチーム

標準オブジェクトには便利なアクセス制御の仕組みが用意されています。

公開ボタン（手動設定）

ユーザへ委ねる仕組みです。所有者の上位ロールの人にもボタンは表示されます。

ルール化できないようなアクセス制御はこれを使う事になります。

キュー

レコードの所有者にキューを指定すると、そのキューのメンバーはアクセス権が付与されます。（引き受けるの機能はキューとワンセットの機能です）

取引先や商談など、キューが使えないようになっているものもあります。

Apex開発（バッチやトリガ）

共有オブジェクト（末尾にShareがつく）に直接レコードを操作することで複雑なアクセス権の制御ができます。

上のApex共有の理由とワンセットで実装するもので、作成したApex 共有の理由は、共有オブジェクトの、テリトリー割り当て方法(RowCause)の選択リスト値として使うことができます。

番外編　共有セット

今までのアクセス権の設定とは別に、コミュニティ向けのデータ共有の仕組みで共有セットが用意されています。(以前は大規模コミュニティは共有セットでしたが、最近はコミュニティのバリエーションの中で共有セットを使うものがあるようです)

共有セットの仕組みは、所有者のプロファイルがそのコミュニティのプロファイルの場合に、指定した内部ユーザへアクセス権を付与する仕組みです。所有者のプロファイルがコミュニティユーザのプロファイルのままでは、内部ユーザ間の共有ルールのアクセス制御は有効にならないので注意が必要です。

最後に

プロファイルのすべてのデータの参照や編集などは割愛していますが、Salesforceのアクセス制御はとても充実してるなーと感じています。その代わり設定するのは大変ですが。。

さらにVisualforceなどの開発した画面では、apex class での without sharing で、レコードのアクセス権関係無しにデータを取得することもできます。

用意されてる仕組みを利用すれば複雑な仕様も実現できます。が、誰にでもわかりやすいシンプルなルールにしておくのが一番かなーと思っています。