Salesforce組織内でApexによるメール送信処理が存在している場合の注意点です。Sandbox組織を有効化した時点では組織からメール送信が実行できないようになっています。このままにしておくとApexのメール送信処理実行時に下記のようなエラーが発生します。
SendEmail failed. First exception on row 0; first error: NO_MASS_MAIL_PERMISSION, Single email is not enabled for your organization or profile.: []
設定で有効化できるので忘れずに有効化しておくと上記エラーは回避できます。
テストクラスでも影響があったと思うので本番ではアレ・・本番では平気だったのにとなったときはこちらの設定を確認すると良いと思います。
MavensMateのサポートが終了した後も意外とそのまま使えていたので利用していたのですが、先日の最後のアップデートでご利用ありがとうございましたメッセージが表示されるようになりました。
ということでやろうと思いつつできていなかったVS Codeをつかった開発環境構築を試してみました。次の専用サイトが用意されているみたいです。
リンク先からVisual Studio CodeとSalesforce Extensionsをインストールできます。
Get Startedのページに環境構築に必要な情報が記載されています。下記を用意すれば良いみたいです。
Java Platform, Standard Edition Development KitについてはJava Setupページに詳細が記載されていました。
Javaの環境構築はいくつか種類があるみたいですが、データローダでも必要になったZuluを利用すればいいのかなと思います。
データローダでインストールしたときの記事はこちら。
インストール後のバージョン確認は『java --version』でできます。
Javaの準備ができたので続いてSalesforce CLIの準備です。専用のダウンロードサイトが用意されています。
専用のインストーラからインストールできますが、npmコマンドでインストールすることも可能です。
npmでやる場合はNode.jsのサイトからインストールできます。
インストーラからインストールするとnodeとnpmの環境が用意できます。
Node.jsのバージョン指定やバージョンアップなどはnodebrewを使うと良いと思います。
nodebrewからnode.jsをインストールすることもできます。コマンドはこちら。
$ nodebrew install-binary v10.16.0
Node経由でSalesforce CLIをインストールするとこんな感じ。salesforce-almというプラグインがインストールできなかったとWARNINGがでました。自分で追加でインストールできましたが、これが必要なのかはちょっと不明。
実際の検討のときは下記の手順で試していました。
Salesforce CLIのインストールはこんな感じ。下記のコマンドでインストールができているか確認できます。
$ sfdx --version
同じくプラグインのインストールも確認します。
$ sfdx plugins --core
詳細は開発者ガイドに記載されています。
これでSalesforce CLIのインストールができました。環境構築で必要なものは用意できたと思います。次は実際にプロジェクト作成です。
Force.com IDEやMavensMateと同じように開発する方法は「Org Development Model with VS Code」のページに記載されているようです。VSCodeで下記のコマンドを実行してプロジェクトを作成すればいいようです。(コマンド実行のボックスはCmd+Shift+Pで表示できます。)
> SFDX: Create Project with Manifest
実際に実行してみると・・・コマンドが見つかりませんでした。。何かしらの設定手順が漏れているみたいです。
Salesforce CLIが適用されていない気がする。
検索してみたところ下記の情報がみつかりました。VS Codeのバージョンや拡張機能の問題の可能性がありました。。
salesforcedx - SFDX: create project using manifest not available - Salesforce Stack Exchange
①VS Codeの初期化
VS Codeの再インストールを行いました。インストールした拡張機能も下記のコマンドで削除してみました。
※.vscodeフォルダを削除するコマンド。気軽に実行しないほうがいいやつ $ rm -rf .vscode
ENABLEDにSalesforce Extensions Packの機能だけがインストールされた状態。
VS Codeを一旦終了して再起動。これで確認してみました結果、無事「SFDX: Create Project with Manifest」コマンドが選択できるようになりました。過去にインストールしていた拡張機能の影響で最新版のSalesforce Extensionsが適用されていなかったみたいです。
ひとまずこれで環境構築に成功しました。
環境構築できたところで実際にプロジェクトを作成してみます。VS Codeを起動して下記のコマンドを実行します。
$ SFDX: Create Project with Manifest
コマンドを実行するとプロジェクト名の入力欄が表示されます。
続いてプロジェクトを作成するフォルダが求められます。
フォルダを選択すると以下のように必要なファイルが生成されます。
こんな感じの構成です。
プロジェクトの雛形が作成できたら続いてSalesforce組織と接続します。そのときの手順はこちらが参考になりました。
下記のコマンドを実行します。
$ SFDX: Authorize an Org
接続先のログインURLが聞かれます。(本番かSandboxかカスタムURLか)
組織の別名を登録できます。(空値で進めてよかったかも)
上記作業の後に自動でログインページに移動します。
接続したい組織のアカウントでログインすると認証ページが表示されます。
認証するとブラウザ側はそのままログイン後のページに移動しますが、VS Code側ではコンソールに接続成功のメッセージが表示されます。
manifestフォルダ内にpackage.xmlファイルがあるのですが、そのファイルに対して右クリックするとデータの取得とデプロイのメニューが追加されています。「SFDX: Retrieve Source from Org」を選択するとソースコードが取得できます。
これでclassやトリガなどpackage.xmlで指定したとおりにソースコードがダウンロードされます。今回試したときにファイル数が多かったためか崇徳したはずのclassファイルがVS Code上で表示されない現象が発生しましたがVS Codeを立ち上げ直したら問題なく表示されました。
デプロイというかコードの保存の方法です。VS Codeでクラスやページなどのソースコードを変更した後は対象ファイルを右クリックして「Deploy Source to Org」から実行します。
実行後にSalesforce組織を確認したところ対象クラスが無事に更新されていました。
変更を組織に反映するのに毎回コマンドを実行するのは少し面倒と思ったのですが下記の手順で自動化できるみたいです。
「.vscode/settings.json」に"salesforcedx-vscode-core.push-or-deploy-on-save.enabled": trueと記述。
※デフォルトはfalseで記載されていました。
上記設定を反映後に試してみたところファイル保存時に自動で組織にアップされることを確認できました。
保存時にエラーがある場合はPROBLEMSのタブで原因が表示されました。
今回のディレクトリの構成はこんな感じ。
VS Codeを開き直したときにOpen Folderでフォルダを選択するさいに上記のmyappフォルダを選択したところ、右クリックでSFDXメニューが表示されなくなりました。上記の場合はforce-appフォルダなどの一階層上のファイルを選択する必要がありました。
もしSFDXメニューが表示されなくなったりしたときにはOpenFolderで選択したディレクトリを見直すと解決するかもしれないです。
VS Codeの右側にminimapが表示されますが非表示にしたい場合は「view」→「hide minimap」で非表示にできます。表示する場合は「show」を選択します。
Open FolderでファイルをEXPLOERに表示できますが、非表示にしたい場合は「File」→「Close Folder」で非表示(クローズ)にできます。
(最初エディタを閉じたら次開いたときにクリアされると思っていたので、残り続けて少し困りました。)
Test Focus on Apex Tests Viewでテストモードに切り替えられるみたいです。テストモードに切り替えておくとRun All Testが選択できるようになります。
実行結果はこんな感じで確認できます。
他にも知るべき機能があると思いますがひとまずこれで最低限の利用はできそうです。
Createコマンドで作成できます。
ファイルができた後は一度保存による自動DeployするかDeployコマンドを実行することで組織に反映されます。
以上がSalesforce Extensions for Visual Studio CodeによるSalesforceの開発環境の流れです。MavensMateとはだいぶ感覚がことなりますが、基本的には慣れの問題だと思います。プロジェクトのファイル構成は今後のSalesforceプロジェクトの雛形になっていくと思いますのでSalesforce Extensionsによる開発でやっていくのが良さそうです。
CSVデータをSalesforceに取り込める便利ツールのデータローダですが、バージョン45.0から仕様が少し変わってOpenJDKバージョン11のインストールが必要になりました。
このOpenJDKバージョン11をWindows環境で利用する場合、Zuleのサイトからmsiファイルをダウンロードしてインストールできます。ですがインストーラを利用するには64bitの環境が必要になる仕様となっていて32bit用のインストーラは用意されていないようでした。
最近ではあまり無いケースとかもしれませんが、もし32bitのPCでデータローダを利用する必要がある場合、OpenJDKバージョン11のインストールができないため、最新バージョンでは環境構築がうまく行かないという注意点があります。
そうした場合はGithubで過去のバージョンのデータローダが公開されていますので、そちらからバージョン44.0をインストールするのが良さそうです。
Release DataLoader V44.0.0 · forcedotcom/dataloader · GitHub
Windowsの場合はApexDataLoader.exeリンク、Macの場合はApexDataLoader.dmgリンクをクリックするとインストーラがダウンロードできます。Source codeの方はデータローダ自体のコードになりますので、インストーラによる環境構築が目的の場合は特に気にしなくて良さそうです。
このGithubのリポジトリはforcedotcomが管理しているリポジトリですがSalesforce社の管理するリポジトリのはずですので過去バージョンのダウンロードするのはここからやるのが良いと思います。
基本的にこうしたツールは最新バージョンを利用するのが好ましいですが、実行PCによっては動かないというケースがあることは環境構築や設計時には意識しておくとギリギリになってトラブル発生ということを防止できると思います。
Salesforce Platformでの開発はVSCodeとSalesforce Extensionsを使って行えます。VSCodeで開発中にSalesforce組織にアクセスしたなと思ったら下記のコマンドでブラウザを起動してアクセスできます。
> SFDX: Open Default Org
Macの場合はcmd + Pでコマンドメニューを表示できます。
SFDX: Open Default Orgを選択するとブラウザが立ち上がります。VSCode側でSalesforceと接続しているのでログインはスキップできます。大丈夫と思いますが複数組織で作業しているときに別組織にログインされていないかはアクセス後に確認しておいたほうが良いかもしれません。
VSCodeではTerminalの機能が利用できるようになっています。そのためエディタで作業しながら必要に応じてCommand Lineで処理を実行できます。Salesforce APIを実行できるJSforceというライブラリがありますが、この機能と組み合わせると便利そうだったので少し試してみました。
初期設定の方法とかは公式サイトで紹介されています。
JSforceのインストール。(Nodeはある前提)
$ npm install -g jsforce
ログイン
$ jsforce > .connect username@salesforce.example.org Password: ******* Logged in as : username@salesforce.example.org
クエリ実行
query("SELECT Id, Name FROM Account LIMIT 1")
Apex開発中にデータ取得したり更新したりAPI実行したりといろいろできるはずなのでコマンドラインに慣れている人は作業がしやすくなると思います。
CSVファイルを取り込んでSalesforceに登録したり、SalesforceのデータをCSVファイルの形式で出力したりできるデータローダというツールがあります。このデータローダはバッチモードで実行することができ、これによりデータ連携処理の自動化が実現できます。
昔やり方を覚えたときのメモがこちら。数年前のメモでしたが今でもほぼ変わらない方法で実装できました。
やり方はほぼ変わりませんでしたがいくつかハマったところもありました。データローババッチ開発するときには下記については意識しておくと良さそうです。
レポートからCSV出力するときには特になかったのですが、データローダをバッチモードで起動してエクスポート処理を実行した場合、下記の現象が発生しました。
データ型設定上では小数点以下は0にしていても「1」などの値が「1.0」と出力される。
おそらくこの出力したファイルを再度Salesforceに取り込む場合は「1.0」となっていても問題ないと思いますが、別システムとの連携の際には少し困ります。このトラブルを回避する方法としては「テキスト型の数式項目を用意してそちらを出力する」という方法が良いと思います。テキスト型の数式項目で対応することで、数値型や通貨型で自動で付いてくる区切り文字の「,」(カンマ)を表示しないようにもできます。
データ出力のための項目指定はSOQLクエリで指定しますがそれだけでは出力されません。SDLファイルでマッピング対象として初めて出力されます。またSDLファイルでは出力時の項目名も指定することになりますが、日本語指定はできないのでAPI名やそれ以外の英字で指定する必要があります。
今回自分でハマった箇所ではありませんが、データローダバッチの開発はWindows環境で行う必要があります。Salesforce開発はMac環境で行う場合も増えていますので、普段Macで作業している場合はデータローダバッチ開発の際に別途作業用PCが必要になることを意識しておくと慌てずに済むと思います。
企業によってはネットワークの制限が厳しい場合があると思います。ブラウザからSalesforceにログインできてもデータローダなどのツールからはアクセスできないというケースがありえます。設計段階でデータローダによるアクセスが可能かは確認しておくのが良いと思います。
開発時には特に意識することなくCドライブで作業することが多いと思います。データ連携用の処理として開発するときには必ずしもCドライブとは限らないと思います。データローダバッチ開発ではバッチファイルなどのディレクトリを指定することになるので早めにに実行パスなどは検討しておくのが良いと思います。Cドライブでは動いてもそれ意外のドライブで実行するとエラーとなる可能性もありますのでそのあたりも考慮してスケジュールを決めていくとギリギリになって慌てずに済むと思います。
データローダバッチ開発の際には上記について意識しておくと良いと思います。特に他社システム開発を請け負って作業する場合に実行環境について意識しないと納品直前で実行できないというトラブルに遭遇することになります。
Lightning Design Systemでページタイトルするときはslds-text-titleまたはslds-text-title_capsを利用します。
Ligtning Design Systemのサンプルコードをそのまま使うとおそらく上記のように英字が大文字に変換される形で表示されると思います。これは「slds-text-title_caps」が宣言されているためです。「_caps」を除外して「slds-text-title」の宣言に変更することで自動大文字変換が無効になります。
VSCodeにはTerminalのWindowが用意されているのでここからGitコマンドを実行できます。Terminalのウィンドウを開いてディレクトリ情報を確認するとこんな感じ。
プロジェクトファイルをgit管理したいときは「git init」コマンドをそのまま実行すれば良さそうです。
コマンドの流れとしてはこんな感じ
$ git init $ git add . $ git commit -m "first commit" $ git remote add origin git@*********.git $ git push -u origin master
これでGit Hubにプロジェクトファイルをプッシュできます。
ちなみにREADME.mdファイルはSalesforceプロジェクト作成時に自動で作成され、内容もそれっぽい情報がデフォルトで表示されていました。
Visualforce開発の種類についてです。Visualforceはapexタグという独自タグを使わないと行けないイメージが定着していますが、いろんな方法で開発が可能になっていますので紹介します。(下記の名前部分は説明用に勝手につけたやつ)
apexタグをつかった開発方法です。pageBlockやpageBlockTableでClassicデザインのページ開発が可能になっています。
apexタグをつかった開発方法ですが、『lightningStylesheets="true"』を宣言することでLighitning Experienceに近い見た目に変更できます。
apexタグを使わない開発方法。HTMLタグとJavascriptを中心に進められます。CSSはLightning Design Systemを利用することでLightning Experienceと同じ見た目に揃えることができます。
apexタグを使わない方法の場合はフロント側のほとんどの機能をJavascriptで実装する必要があります。実装難易度は上がりますが、apexタグ使用時の制限の影響を受けずに開発が可能です。
apexタグの場合は画面に表示する情報量が多いとビューステートエラーが発生します。例えば取引先検索ページの場合、8000件の検索結果を表示すると発生しました。
Javascript Remotingの場合は上記ビューステートエラーが発生した件数でも問題なく表示できます。
8月10日に開催されたco-meetingもくもく会に参加しました。
だいたいこんな感じのスケジュールとなってます。
SalesforceのVisualforceページのサンプルコード作成をして過ごしました。家で作業するよりも集中して進められたと思います。作業の詳細は下記の記事にまとめています。
サンプルコードつくった後はGithubへのコードプッシュもやってみました。今まで開発環境はMavensMateでしたが最近VSCodeに切り替えたのと拡張機能のSalesforce Extensionsの利用開始でやり方が変わった部分があったのでちょっと試してみました。
その他、空いた時間と気分転換でササッと書ける内容をブログ投稿したりしました。
打ち上げの時間にもくもく会でやったことの話などなどいろいろ話ができて楽しかったです。
VSCodeとSalesforce Extensionsの新機能 (July 2019)です。
VSCodeによるSalesforce開発環境についてはこちら。
ちょっと前まではDevHub組織で用意したスクラッチ組織が開発対象でしたが、MavensMateと同じようにSandbox組織やDE組織での開発に利用できるようになったとのことです。
"salesforcedx-vscode-core.push-or-deploy-on-save.enabled": trueと宣言すると保存時にSalesforce側に反映されます。falseだと反映されないので、アレっとならないようにtrueにした方が良いと思います。組織に接続したときにはfalseになっているので、環境構築のたびにチェックすると良さそうです。
画面左下のあるVSCode Orgのメニューから接続組織を追加したり、変更したりできるとのことです。
イマイチわかっていない機能ですが、以下のような説明がありました。
まだβ版機能とのことです。設定方法としてはVS Code側の設定で有効化する必要があります。
有効化するとsettings.jsonファイルに設定情報が追加されました。
7月31日の記事時点から来週または二週間後ぐらいにリリースされるみたいです。便利そう。
Lightning Webコンポーネントの開発もサポートされるようになったそうです。
Lightning Webコンポーネント開発時にHTMLコード補完されるようになったそうです。
Lightning Webコンポーネント開発でJavascriptファイルのコード補完がされるようになったそうです。
Lightning Webコンポーネント開発でESLintの仕組みが利用可能になったそうです。
なんかいろいろできるようになっています。
特に便利そうだったのはApexリファクタリングで右クリックメニューのRename Symbol機能で変数名を一括置換できます。
今までのテキストエディタの置換機能と違うところは、文字列ではなく変数名を識別してくれるので誤った置換が行われないというメリットがありました。
例) accountという変数名を置換したときにaccountListという変数名やAccountというオブジェクト側への影響はありませんでした。
他のファイル(ページ側)への変換は行われないのでそのファイル内のみでの作業を行うためのサポート機能になります。
VSCodeとSalesforce Extensionsを使った開発は最近始めてまだ慣れない部分もありますが、Terminalからコマンド実行したりプロジェクトファイルの雛形作成してくれたりと便利機能が多いのではやめに切り替えたほうが良さそうです。
※MavensMateは終了しました。またForce.com IDEは2019年10月12日頃に終了するそうです。
Salesforce Surveysによるアンケート機能の実装を検討してみました。検討の結果要件を満たせないという結論になったのですが、Salesforce Surveysで何ができて何ができないのかざっくり確認できたのでまとめておきます。
Salesforce標準機能のひとつでシンプルなエディタでアンケートの仕組みを実装できる機能です。
自分の環境で試したいという方は初期設定方法はこちら。たぶんまだ動く。
ざっくり上記のような感じ。一般的なサービス運営でよくある仕組みです。
Salesforce社としての仕様は下記のとおりです。ヘルプの記載とサポートに相談してもこのように回答頂けると思います。
Salesforce Surveysの対象者はCommunity Cloudユーザです。それ以外の取引先責任者へもアンケートの送付は可能ですが、その場合は回答者の識別ができません。(匿名アンケートになる。)
アンケートの招待のページで匿名のON/OFFの設定がありますが、URLが共通のことからもコミュニティユーザでない場合は回答者の識別ができないというのが正しいと思います。
Salesforce社の回答は上記のとおりですが、裏技的な方法で紐付けが可能です。下記のカスタマイズができます。
サポート外の方法ですが、裏側でガチャガチャ設定することで強引に取引先責任者との紐付けが可能でした。
上記の通り強引な方法で取引先責任者と紐付けることができました。続いてレポートの集計処理です。まずアンケートの情報は下記のオブジェクトで管理されています。
アンケートで枠を管理し、招待で取引先責任者にアンケートを送付。招待に対して回答が紐付くという形です。通常の用途では一つの招待に複数の取引先責任者が紐付く仕様ですが、上記の強引に取引先責任者を紐付ける方法の場合は、一つの招待に対して一つの取引先責任者という形で管理することになります。Salesforceのデータ上はアンケート回答者の特定はできませんが、招待と回答が1対1になることで事実上特定ができたという考え方です。
データ上は用意できますが、問題はレポートによる集計です。アンケートのレポートはカスタムレポートタイプを用意することで作成可能になります。
ここで問題が発生しました。この方法で集計する場合のデータ型の問題です。アンケートの回答でスコアなど数値での回答は平均値などの集計が必要になりますが、この方法での集計の場合、数値という認識はされないため、平均値などの算出ができませんでした。結果としてその顧客が選択した値の認識が実現できるだけでレポートへの集計は実現できないという問題があります。
補足としてSalesforce Surveys本来の使い方としては分析機能で回答を確認するという使い方が用意されています。
プロセスビルダーなどで独自カスタマイズを組み合わせることで一見コミュニティユーザ以外の取引先責任者向けに回答者を識別できるアンケートの仕組みを実現できそうでしたが、結果としてSalesforce Surveysでの分析機能が活用できず、またレポートなどの回答結果の集計が不可であるという結果でした。
もちろん数式項目を組み合わせることで、強引に回答結果を数値変換する方法など実現自体は可能かもしれません。ですが、Salesforce Surveysを利用するメリットとしては複雑なカスタマイズを必要としないアンケートの作成が一番の理由と思いますので、アンケート作成のたびにプロセスビルダーの設定や数式項目作成が必要になるとすればSalesforce Surveysを使用するメリットは無いと思われます。
回答形式で評価の場合は選択肢の下のテキストをカスタマイズできます。
ですがNPSなどの一部の形式ではテキストのカスタマイズができない仕様となっています。
アンケートのデザイン部分のカスタマイズですが、HTMLなどによるレイアウト変更はできないようです。変更可能な部分として背景画像の変更ができます。アンケートにロゴの表示やヘッダー、フッターの設定を行いたい場合はそうした背景画像を用意することになります。ちなみにこの背景画像はSandbox作成時に引き継がれない情報となります。
必須チェックや分岐制御は可能となっています。
レイアウトのカスタマイズに縛りはありますが、モバイルレイアウトが可能になるというメリットがあります。
上記のとおり、コミュニティユーザ以外にアンケートを送付するという要件の場合、Salesforce Surveysを使用するのはあまり適切ではありません。そこで代わりの方法ですが3つの選択肢があります。
アンケートの仕組みを用意するサービスはいくつかあります。こちらを利用することでカスタマイズ性の高いアンケートの仕組みを用意することが可能です。ただし、Salesforceとのデータ連携をどうするかが課題になります。たとえば特定の商談フェーズまで進んでいる取引先責任者に対してメール送付といったことを実現するのが難しくなります。
こちらもいくつか用意されています。Salesforce社もGetFeedbackというサービスを利用しているみたいです。(サポート利用後のアンケートがそうでした。)
GetFeedback: Surveys for Salesforce - GetFeedback - AppExchange
尚、GetFeedbackは海外のサービスのため日本語でのサポートが受けられない可能性があります。日本のパートナー企業がアンケートの仕組みをAppExchnageで提供しているのでそちらも確認してみると良いかもしれません。
自分達の組織に合わせて使いやすいアンケート機能を構築するのであればForce.com Sitesの仕組みで構築するのが良いと思います。独自開発が必要になりますが柔軟なカスタマイズが可能になります。
最後にSalesforce Surveysの費用感です。Salesforce Surveysはアドオン機能で追加ライセンスの購入が必要になります。作成するアンケートが1つの場合は追加ライセンス無しで運用できますが、2つ以上の作成からライセンスが必要になります。数ヶ月前に導入検討で相談したときに費用の有無は不明ですって状態だったのであまり導入してるところは多くなさそうですが、とりあえず導入検討するときにはSalesforce社に問い合わせすると要件の確認等対応してくれると思います。
自宅のPC環境でMacBookと外部ディスプレイを2台接続してマルチディスプレイ環境の構築をやってみました。
購入したディスプレイはPhilipsの23.6インチのディスプレイです。なんとなくPhilipsの商品で探していたときにAmazonでセールをしていたので買ってみました。HDMIケーブルなど通常利用する際に必要なものがセットで付いてきたので良かったです。
Philips 23.6型ワイド液晶ディスプレイ (PLSパネル/フルHD/HDMI1.4/DVI-D/D-Sub15/5年間フル保証) 246E7QDSB/11
追加で買ったのがAppleストアでも販売しているBelkin 4K Mini DisplayPort to HDMI Adapter。2台目のディスプレイとつなぐためのHDMIケーブルをMacBookに接続する際に変換アダプタとして必要になりました。
MacBookとディスプレイを2台接続するときですが1台目は普通にHDMIケーブルを接続するだけで利用できます。
今使っているMacBookが2013年版のMacBook ProだったのですがHDMIの接続端子は1箇所しか無いため、2台目の接続はそのままではできませんでした。この問題で悩んでいたのですが、Belkin 4K Mini DisplayPort to HDMI AdapterでHDMIケーブルをMini DisplayPort端子に変換することでMacBookと接続することで解決できました。
ディスプレイ2台 / HDMIケーブル / Mini DisplayPortを用意することでマルチディスプレイ環境構築ができました。まだあまり使ってませんがブラウザとVSCodeを開いて作業するときに、MacBook内でウィンドウの切り替えをせずに作業できるようになって快適になったと思います。(もう一台はまた別の情報を表示しておく予定)
ディスプレイ購入の際に4Kじゃないと画質が気になるかもと悩んだのですが、4Kでなくても画質は気にならなかったです。またディスプレイのサイズも23.6インチで丁度良かったです。お店で見たときには少し小さく見えたりしましたが部屋に置いてみたら十分なサイズでした。
自分でマルチディスプレイの環境を用意するのは初めてだったのですが、とりあえずHDMIケーブルを2つ接続する必要があるので別途必要になるんだろうなと検索したところ、分配器の商品が表示されました。
絵的にイメージしてた形状だったのでこれで接続できるんだなと買ってみて試したところ、同じ内容が2つのモニタで表示されました。分配器は会議など複数人で見るようなときに同じ内容をディスプレイに表示する用途だったみたいです。(PCのミラーリング設定みたいになんとなく設定で切り替えできるイメージでした。)
お店に行った時に知ったのですが類似の製品で切替器というものあってそちらは一つのモニタに複数のPCを接続して必要に応じて表示を切替できる仕組みでした。(こちらは商品説明で買う前に気づきました。)
この失敗の後にHDMIケーブルをMini Display Portに変換できる製品があることとAppleストアでも取り扱っていることを教えてもらって無事に問題が解決しました。
ユーザ編集権限とinsufficient access rights on cross-reference idエラーについてです。Apexで処理の自動化の仕組みを構築する場合は下記のエラーが発生することがあると思います。
INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY, insufficient access rights on cross-reference id: []
このエラー自体はアクセス権限が不足していることによるエラーです。
非公開オブジェクトや更新権限を付与していないオブジェクトへのデータ更新で発生します。取引先などの標準オブジェクトやカスタムオブジェクトの場合は共有設定の権限見直しですぐに解決できますが、ユーザオブジェクトなど一部のオブジェクトの場合は共有設定では公開/参照のみの権限までしか付与できないため考慮が必要になります。
ユーザオブジェクトに更新権限を付与する必要が発生する場面のイメージとしては、データ更新時に所有者などのユーザのカスタム項目をApexトリガなどでUpdate処理を行うような場合に発生します。ログインユーザ自身のデータ更新なら問題ありませんが、他ユーザのデータ更新を行うには更新権限が必要です。
この問題の対応方法としては共有ルールで更新権限を付与する方法があります。
更新権限を付与することでApex経由でのユーザのカスタム項目更新を実行できるようになります。Apexから処理を実行する場合は項目レベルセキュリティの編集権限の付与は無しの状態でも実行できます。
ただしこの方法を選択する際の注意点があります。
まずユーザオブジェクトは少し特殊で標準項目に対しての項目レベルセキュリティを変更することができません。そのため編集ページにアクセスできれば管理者以外でも任意の内容に変更できるという認識が必要です。
続いてプロファイルページからの編集操作への考慮についてです。ユーザのプロファイルページにはChatterやレコードの所有者リンクからアクセスできます。共有ルール等で更新権限を付与することで、他のユーザの情報に対してもデータの更新が可能な状態となります。
これの対応方法としてはユーザのプロファイルページレイアウトで参照のみ項目にすることで編集ページにアクセスしても参照のみ権限に変更できます。
氏名とメールアドレスは必須項目となるため参照のみ権限への変更はできないのですが、レイアウトから非表示にすることが可能です。数式項目を用意することで編集可能な標準項目は非表示にしつつ参照のみ項目を表示することも可能です。
この対応で編集ページへのアクセスが行われても任意の値に変更できないようになります。(自己紹介項目などログインしたユーザ側で任意の情報に変更する項目がある場合は専用の入力フォームを用意するか利用を中止するかなどの対応が必要になります。)
上記対応でモバイル側からも変更できないように制御されます。
ユーザの編集ページはもう1箇所あります。ユーザの詳細ページです。こちらに関してはプロファイルで設定・定義を参照するの権限を無効にすることでアクセス不可になります。(基本的に設定・定義を参照するの権限は管理者用の権限です。)
権限除外により歯車アイコンが非表示になり、管理者用のユーザの詳細ページへのアクセスが不可になります。
ユーザオブジェクトにカスタム項目を用意してApex経由で一般ユーザが更新するというケースはあまり無い気もしますが、もし必要になる場合は上記のように権限周りについての考慮が必要になります。
個人取引先はB2Cの顧客情報を管理するための仕組みです。Salesforceのサポートに問い合わせを行い有効化してもらうことで利用可能になります。この機能を有効化後は法人取引先か個人取引先かの判別は「IsPersonAccount」項目で判別できます。
これで法人取引先のみ取得対象にする、個人取引先のみ取得対象とするといった判定処理を実行できます。ただし、「IsPersonAccount」項目は個人取引先機能を有効化した組織でのみ利用可能な項目です。有効化していない場合は宣言しても存在しない項目としてエラーとなります。
この問題を解決ですが組織での個人取引先有効化の判別方法を調べて公開してくれている方がいらっしゃいました。
https://wedgecommerce.com/check-person-account-enabled-apex/
Schema処理で項目の存在チェックを行って判別する方法です。
public class CheckPersonAccount {
public boolean getIsPerson(){
return Schema.sObjectType.Account.fields.getMap().containsKey( 'isPersonAccount' );
}
}
実行例です。
Boolean result = Schema.sObjectType.Account.fields.getMap().containsKey('isPersonAccount');
System.debug('個人取引先項目の有無 = ' + result);
通常のカスタマイズの場合はここまで考慮する必要は無いのですが、AppExchangeなど不特定多数での組織での運用を行うアプリケーションの場合は、きちんと判別を行い有効の有無によって制御を行う必要がでてくると思います。
Dreamforce 2019の登録サイトがオープンしました。
開催期間は現地時間で11月19日(火)〜11月22日(金)です。
18日(月)はDreamforceの前日ですが参加を証明するバッチの受付が開始されます。(Registration and Badge Pickup)
時差のことを考慮すると日本から参加する場合はこんな感じのスケジュールになると思います。
- 日本時間：11/18 (月) - 日本の空港出発
- 現地時間 : 11/18 (月) - サンフランシスコ空港到着。市内へ移動して参加者バッチをもらう。ホテルチェックイン。
- 現地時間 : 11/19 (火) - DF19 Day 1 (イベント初日)
- 現地時間 : 11/20 (水) - DF19 Day 2
- 現地時間 : 11/21 (木) - DF19 Day 3
- 現地時間 : 11/22 (金) - DF19 Day 4 (イベント最終日)
- 現地時間 : 11/23 (土) - ホテルチェックアウト。サンフランシスコ空港出発。
- 日本時間 : 11/24 (日) - 帰国
Dreamforceの登録はまだやっていないのですが、8月中か9月前半には済ませておいた方が良いのかなと思います。それよりも優先度の高い対応事項があります。ホテルの予約と飛行機の予約です。
Dreamforceの開催期間中サンフランシスコのホテルの価格が高騰します。滞在期間も5泊となるので多めの予算が必要です。また会場に近いホテルは比較的に早く埋まるため参加を検討する場合でまだ決めていない場合は早めに予約を済ませた方が良いと思います。
ホテルに関しては昨年の2018-09-16頃にDreamforce2019のスケジュールが発表された時点で予約したのがひとまず問題ありませんでした。(ホテルは予約キャンセルが可能になっている場合が多いので一旦予約しておくということが一応可能です。※参加できそうにない場合は早めにキャンセル手続きしないと迷惑をかけてしまいますが)
今回...というか今朝(19日の朝)に気づいてちょっと焦ったのが飛行機の予約の方です。飛行機は予約キャンセルプランにすると料金が上がってしまうので参加できることを確認してから予約する方が良いと思います。6月とか7月とかに予約を済ませておけば良かったのですが8月後半まで後回しにしてしまった結果、飛行機の予約の選択肢がほぼなくなってました。
こっちはまだ大丈夫。選択肢たくさん。
空きが早朝の一つだけ、しかも乗継一回の便。
なお、成田ではなく羽田で検索してもけっこう厳しい。
完全にやってしまった状態だったのでANAを諦めて他の航空会社で検索してみました。
検索の仕方が良くないのか直行便が見つからず。。
往路。
復路。
合計。まだ選択肢が多いし直行便で行けるけど少し予算が。
直行便で18日に出発して23日の便で帰ろうと思ったらユナイテッド航空の選択肢しかなさそうでした。。今回はユナイテッド航空さんにお世話になるか ‐‐‐と考えていたところで一つ選択肢が浮かびました。帰国日ずらす方法 - そもそものスケジュールの変更です。
再検索してみた結果。ぎりぎり選択肢が増えました。
スケジュール調整する場合、もう一つ気にしないと行けないのが宿泊場所です。18日から23日の場合は5泊で済みますが、24日以降に延長する場合はその分の宿泊ホテルを探す必要があります。ただ...ホテル予約でお気に入りのBooking.comとHotels.comで検索してみたところ、宿泊料金は比較的リーズナブルでした。
※24日以降はDreamforceの開催期間ではないため、通常料金に戻っているようです。23日に無理して帰るよりも一泊二泊した方がお釣りが来るぐらいでした。
※今回調べてみたのはサンフランシスコ空港の近くのホテルです。
こんな感じで23日発の飛行機予約はかなり厳しかったですが24日や25日まで滞在を延長して見たほうがやすく帰れそうです。とりあえずDreamforceへの参加を検討される場合はホテルと飛行機の確保を最優先に行動した方が良いと思います。
関連レコードコンポーネントをつかって商談に取引先の項目表示を試してみました。取引先の説明項目は自由入力のための項目で、補足や注意事項などユーザがメモしたい情報が登録されます。
商談のページに取引先の説明項目が表示されると商談のページのみで作業を進められて助かるという要望がありました。
最初に思いついたのは数式をつかった方法です。ですが数式項目はロングテキストエリア型の項目の値を参照することができません。取引先の説明項目はロングテキスト型の項目のため、数式による方法は実現不可でした。
数式対応は不可だったため検索してみたところワークフロールールで値を持ってくる方法が見つかりましたが、更新などのアクションが無いと更新処理が行えずに情報が古いままとなってしまう可能性があるので今回は見送り。
次に思いついたのはVisualforceページの埋め込みです。Lightningコンポーネントと違う部分で詳細ページレイアウト内の任意の位置に差し込むことができます。・・・が高さは固定値となるため見栄えが少し崩れる問題がありました。
どうしたものかなと悩んでいるところにTwitterで関連レコードコンポーネントをつかった方法を教えてもらいました。
関連レコードで表示する場合は取引先のアクションを用意する必要があります。
レイアウトの設定で説明項目のみ表示させます。
アクションの準備ができたら商談のLightningページ設定で関連レコードコンポーネントを追加します。
ヘッダーの表示ラベルは任意のタイトルをつけたいときに入力します。参照項目は取引先を選択、更新アクションは先ほど作成した取引先の更新アクションを指定します。作成アクションは特に気にせずで大丈夫です。
これで商談の詳細ページに取引先の説明項目を表示できました。一つの取引先に複数の商談を作成したときにどの商談ページを開いていても共通の補足情報を表示できます。
関連レコードコンポーネントで説明項目を表示する場合、内容に応じて表示高さを自動調整してくれます。そのため文字の途中までしか表示されなかったり、続きはスクロールして確認というようなことは発生しないのですが、説明の値の行数が多くなってしまうとその下にある情報に気づきづらくなります。基本的には5〜10行ぐらいで管理するのがいいと思いますが、どうしてもながくなってしまう場合は別タブ表示などの対応を行ったほうがいいと思います。
上記の方法で設定を行った場合、関連レコードコンポーネントのメニューには「参照」と「削除」の二種類が表示されていると思います。「参照」を選択すると参照元(この場合は取引先レコード)のページへ移動できます。
注意が必要なのは削除の方です。削除という表記ですが実態は取引先レコードとの関連付けを解除する操作になります。通常の編集ページでは商談レコードの取引先参照項目は必須項目となりますが、この部分から解除する場合は必須チェックの判定対象外として操作を行うことができます。なので知らぬ間に取引先と紐付かない商談が作成される可能性がでてきます。(補足として関連付けがクリアされるだけで取引先データ自体が削除されるわけではないため、一般ユーザの削除権限を無効化してもこの削除メニューは利用可能となってしまいます。)
この問題の対応方法は簡単で入力規則で対応できます。
ユーザには削除のメニューの利用は不要ですと伝えて基本的には操作しないルールとしつつ、誤って選択された場合は入力規則でブロックするという方法でシステムの整合性を担保できると思います。
関連レコードコンポーネントの利用に関してはこんな感じでした。説明項目など一部の情報のみ表示するという方法は今まで使ったことがなかったのですが非常に便利だと思います。鉛筆アイコンからデータの編集は可能ですが、そちらはプロファイルの編集権限で制御できると思います。(基本的に取引先で編集OKだったら編集できても問題はず。)
関連レコードコンポーネントをつかって商談に取引先の項目表示を試してみました。取引先の説明項目は自由入力のための項目で、補足や注意事項などユーザがメモしたい情報が登録されます。
商談のページに取引先の説明項目が表示されると商談のページのみで作業を進められて助かるという要望がありました。
最初に思いついたのは数式をつかった方法です。ですが数式項目はロングテキストエリア型の項目の値を参照することができません。取引先の説明項目はロングテキスト型の項目のため、数式による方法は実現不可でした。
数式対応は不可だったため検索してみたところワークフロールールで値を持ってくる方法が見つかりましたが、更新などのアクションが無いと更新処理が行えずに情報が古いままとなってしまう可能性があるので今回は見送り。
次に思いついたのはVisualforceページの埋め込みです。Lightningコンポーネントと違う部分で詳細ページレイアウト内の任意の位置に差し込むことができます。・・・が高さは固定値となるため見栄えが少し崩れる問題がありました。
どうしたものかなと悩んでいるところにTwitterで関連レコードコンポーネントをつかった方法を教えてもらいました。
関連レコードで表示する場合は取引先のアクションを用意する必要があります。
レイアウトの設定で説明項目のみ表示させます。
アクションの準備ができたら商談のLightningページ設定で関連レコードコンポーネントを追加します。
ヘッダーの表示ラベルは任意のタイトルをつけたいときに入力します。参照項目は取引先を選択、更新アクションは先ほど作成した取引先の更新アクションを指定します。作成アクションは特に気にせずで大丈夫です。
これで商談の詳細ページに取引先の説明項目を表示できました。一つの取引先に複数の商談を作成したときにどの商談ページを開いていても共通の補足情報を表示できます。
関連レコードコンポーネントで説明項目を表示する場合、内容に応じて表示高さを自動調整してくれます。そのため文字の途中までしか表示されなかったり、続きはスクロールして確認というようなことは発生しないのですが、説明の値の行数が多くなってしまうとその下にある情報に気づきづらくなります。基本的には5〜10行ぐらいで管理するのがいいと思いますが、どうしてもながくなってしまう場合は別タブ表示などの対応を行ったほうがいいと思います。
上記の方法で設定を行った場合、関連レコードコンポーネントのメニューには「参照」と「削除」の二種類が表示されていると思います。「参照」を選択すると参照元(この場合は取引先レコード)のページへ移動できます。
注意が必要なのは削除の方です。削除という表記ですが実態は取引先レコードとの関連付けを解除する操作になります。通常の編集ページでは商談レコードの取引先参照項目は必須項目となりますが、この部分から解除する場合は必須チェックの判定対象外として操作を行うことができます。なので知らぬ間に取引先と紐付かない商談が作成される可能性がでてきます。(補足として関連付けがクリアされるだけで取引先データ自体が削除されるわけではないため、一般ユーザの削除権限を無効化してもこの削除メニューは利用可能となってしまいます。)
この問題の対応方法は簡単で入力規則で対応できます。
ユーザには削除のメニューの利用は不要ですと伝えて基本的には操作しないルールとしつつ、誤って選択された場合は入力規則でブロックするという方法でシステムの整合性を担保できると思います。
関連レコードコンポーネントの利用に関してはこんな感じでした。説明項目など一部の情報のみ表示するという方法は今まで使ったことがなかったのですが非常に便利だと思います。鉛筆アイコンからデータの編集は可能ですが、そちらはプロファイルの編集権限で制御できると思います。(基本的に取引先で編集OKだったら編集できても問題はず。)
Apexで日付の曜日部分を取得したいときは、一度日時型に変換して「.format('E')」の処理で取得できます。
// 月曜日
Datetime day1 = Datetime.newInstance(2019, 9, 9);
System.debug(day1.format('E'));
// 火曜日
Datetime day2 = Datetime.newInstance(2019, 9, 10);
System.debug(day2.format('E'));
// 水曜日
Datetime day3 = Datetime.newInstance(2019, 9, 11);
System.debug(day3.format('E'));
// 木曜日
Datetime day4 = Datetime.newInstance(2019, 9, 12);
System.debug(day4.format('E'));
// 金曜日
Datetime day5 = Datetime.newInstance(2019, 9, 13);
System.debug(day5.format('E'));
// 土曜日
Datetime day6 = Datetime.newInstance(2019, 9, 14);
System.debug(day6.format('E'));
// 日曜日
Datetime day7 = Datetime.newInstance(2019, 9, 15);
System.debug(day7.format('E'));'月'、'火'ではなく'Mon'や'Thu'という形で取得できるのでそこから日本語表記には別途変換処理が必要になります。
変換用の共通クラスを用意しておくと使い回せると思います。