SFDC：プロフィールのデフォルトアイコン変更について

Summer'17でユーザのデフォルトアイコンが変更されました。今まで人のアイコンでしたがSalesforceのマスコットキャラクタが表示されるようになっています。

この機能はLightning Experienceでのみ有効化されます。Salesforce Classicを利用している場合は今まで通りのアイコンが表示されます。

会社システムのアイコンとしては少しかわいい感じですが、基本的には社員の顔写真をきちんと設定しましょうという方針なんだと思います。

個人的に少し気になったのはCommunity Cloudユーザへの影響です。Community Cloudは社外の人が利用するため基本的には顔写真は設定されないと思います。社内と違って理由や事情を説明する機会もなさそうかなーと考えていたのですが、確認してみたところ、Lightning Experienceでのみ有効化される仕様となっているためCommunity Cloudユーザへの影響はありませんでした。

その他の影響の無い部分

Chatterグループのアイコンには影響ありませんでした。

Chatterフィードに表示されるアイコンにも影響ありませんでした。

所有者項目に表示されるアイコンにも影響ありませんでした。

ということでこの変更はユーザのプロフィールページと右上のアイコン部分だけで、普段目にする場所には影響はなかったみたいです。

SFDC：自動活動キャプチャでGoogleまたはOffice 365の利用ログ集計

Salesforceの活動履歴は顧客にどのようなアクションをおこなったかを記録できる便利な機能ですが、手入力は時間が掛かるのでできれば自動化したい部分です。Inbox または Sales Cloud Einsteinライセンスを契約することで、自動活動キャプチャの機能を利用できるようになるみたいです。

こういった情報をレポートで集計することで業務分析が可能になります。

参考

SFDC：重複管理でデータ品質の向上

Trailheadの重複管理をやってみました。
trailhead.salesforce.com

重複管理は下記オブジェクトをサポート

• 法人取引先
• 取引先責任者
• リード
• 個人取引先
• カスタムオブジェクトから作成されたレコード

※標準オブジェクトは一部のみ

重複管理機能のキーワード

一致ルール

重複レコードを識別するための一致条件。
Salesforce には、法人取引先用、取引先責任者およびリード用、個人取引先用の 3 つの標準一致ルールが付属しています。他の一致ルールも簡単に作成できます。

重複ルール

Salesforce が一致ルールを使用する時期、および重複が発生したときにとるアクションを決定します。
重複管理を設定する方法によっては、重複を作成しそうになると営業担当にアラートが表示されます。または、営業担当は重複の作成をブロックされます。
会社が Spring ’15 以降に Salesforce の使用を開始した場合、法人取引先、取引先責任者、リード、個人取引先用の標準重複ルールが提供されています。

取引先責任者のメールアドレスチェックを試してみる

設定→一致ルール

オブジェクトで取引先責任者を選択

名前と条件を指定

作成されたタイミングは無効の状態です。

条件に問題が無いことを確認してから有効化します。

一致ルールが作成されると重複チェックの条件指定が行われました。続いて重複発生時の対応を指定します。設定→重複ルールを選択します。

設定画面はこんな感じです。

一致ルールは細かく設定できます。

取引先責任者の比較対象

比較対象をリードに変更したりできます。

一致ルール

先程作成した一致ルールを選択します。

最後に有効化して完了です。

これで取引先責任者を登録時に既に存在しているメールアドレスを入力しているとアラートが表示されます。

アラート内のリンクをクリックすると対象の既存レコードを確認することができます。

この取引先責任者を開くのリンクをクリックするとその場で既存レコードページに移動できます。(登録しようとしていたデータはクリアされます)

アラート表示を確認後に再度保存ボタンをクリックすると保存処理を実行できます。

設定時の注意

一致ルールですが有効化中は編集することができません。内容を変更したい場合は一度無効化する必要があります。一番左側に表示されているのは削除なので誤って削除しないように気をつける必要があります。

また、重複ルールも無効にしておく必要があります。

一致ルールですが、ANDやOR条件で複雑な条件にも対応できます。

SFDC：データローダとダブルクォーテーションエラーの対応方法

データローダでデータ取り込み時に下記のエラーに遭遇することがあると思います。

Found unescaped quote. A value with quote should be within a quote

こちらのエラーが発生する原因にダブルクォーテーションの有無が関係していることがあります。データローダでは値の中にダブルクォーテーションが含まれている場合、一手間加える必要があります。

例えば次のようなデータの場合・・・

取引先名,コメント
株式会社サンプル,これは"サンプル"です。

ダブルクォーテーションの部分を次のように変更する必要があります。

取引先名,コメント
株式会社サンプル,これは""サンプル""です。

もしダブルクォーテーションが末尾部分に掛かっている場合は、その値全体を別途囲う必要があります。

取引先名,コメント
株式会社サンプル,"これは""サンプル"""

データローダでエラーが発生したときはダブルクォーテーションの有無をチェックしてみるといいと思います。

このルールについてはヘルプにまとめられています。

help.salesforce.com

SFDC：フィード追跡の無効化とレコードフィードの投稿履歴

Salesforceではフィード追跡の有効化機能を利用することでレコードに紐付く形でChatter投稿を行うことができます。

便利な機能ですが、必要もないのに有効化すると、本来投稿するべき他のレコードフィードと勘違いして投稿してしまうケースがあったりすると思います。なので利用目的が無い場合は無効化しておいた方が余計な混乱を防ぐことに繋がる場合もあると思います。

フィード追跡の無効化を行おうとした際に１つ気になる点がでてきました。。投稿済みのレコードフィードの扱いです。無効化後はChatterフィードの部分が非表示になるので投稿自体が見えなくなるのは想定通りなのですが、無効化後にどうしてももう一度確認したい投稿がある...となったときに復旧できるのか気になりました。

ということで設定画面からチェックを外して無効化を行い・・・

Chatter投稿が見えなくなることを確認します。

その後、再度フィード追跡を有効化して・・・

再表示されたChatterフィードを見てみると・・

無事に過去の投稿も表示されました。

もしかすると無効化後に何日経過すると非表示になるという可能性もありますが、基本的には無効化しても投稿したいが消えるわけではなく、再度有効化したタイミングでと投稿を再表示できるみたいです。

SFDC：Force.com Sitesで構築された予約ページで仮予約の仕組みを運用してみてわかったこと

Force.com SitesはForce.comプラットフォーム上でネイティブに動作するパブリックWebサイトやアプリケーションを作成できる仕組みです。

JP:Sites - developer.force.com

Salesforceのデータベースに登録された情報を利用できるWebサイトを構築できるので、開発者以外のスタッフでもメンテナンスできるサイトを構築できます。ホームページや製品紹介のサイト、ログインページを用意してCommunity Cloudと連携させるといった使い方がよくされていると思います。

少し前にこのForce.com Sitesで構築された予約ページを引き継ぎました。その予約ページの機能の中に仮予約の仕組みが用意されていたのですが、実際に運用を回してみていろいろわかったことがあるので紹介します。

予約ページの利用の流れ

1. 予約ページにアクセス
2. 日時を選択
3. 予約に必要な情報を入力 (名前や連絡先など)
4. 次へボタンで確認ページへ移動
5. 入力した内容に誤りがないかを確認
6. 仮予約ボタンをクリック
   (予約データが作成される。ステータス→仮予約)
7. 仮予約完了画面に移動。本予約までの流れを確認
8. 顧客が仮予約完了通知メールを受信
9. 通知メールに記載されたURLをクリック
   (24時間クリックしないとキャンセル扱い)
10. 本予約完了ページへ移動
11. 予約確定 (ステータス→予約確定・その他必要な処理が実行される)

ざっくりこんな感じです。仮予約の仕組みがあることで誤ったメールアドレスを入力したり存在しない連絡先を入力した場合に、予約確定の作業を進められないメリットがあります。また24時間すぎると本予約のリンクが無効になり放置された予約作業を無効にすることができます。

実際に運用してみて

仮予約完了通知メールから本予約を行う流れですが下記のパターンが発生しました。

• 通知メールに記載された本予約のリンククリックを行わない
  (メールや必要な操作に気づかない)
• PCメールブロックなどにより通知メールが届かない

本来、社内スタッフは予約確定した情報のみ気にすればいいのですが、上記のパターンにより利用者は予約したつもりでもシステム上は予約されていない状況が発生しました。

その結果、自動化されているはずの予約手続きを社内スタッフが状況を確認して手動で対応しなくてはならない問題が発生しました。また本予約完了ページで実行されるはずの処理が実行されないので、その部分の対応も必要になりスタッフへの負担が増加することになりました。

現在

先日予約ページの再開発を行いこの仮予約の仕組みを除外しました。これにより利用者は今までよりも１つ手順が少ない状態で予約手続きを進めることができます。また必要事項を入力して予約ボタンを押せばその場で予約完了ページが表示されるため、メールが届かない場合でも予約が確定したことを確認できるようになりました。

システム上も必ず予約確定のステータスで予約情報が登録されるため、不要な手作業が発生することは無くなりました。開発者側としても予約のオペレーションがシンプルになったことでコードの量が少なくなりメンテナンス性が向上するメリットがありました。

まとめ

仮予約の仕組みを実際に運用してみてスタッフへの負荷が掛かるオペレーションになることが確認できました。また仮予約という複雑な仕組みがあることでメンテナンスしずらいシステムが出来上がることが確認できました。

もし予約ページの開発を依頼されて、仮予約の仕組みが欲しいという話になったときは上記のようなリスクを伝えてできるだけシンプルなオペレーションになるように話を進めると利用者に負担の掛からないシステムを開発できると思います。

SFDC：無効ユーザをレコードの所有者に設定するときの制限について

Salesforceでは所有者の項目をつかって誰が担当しているレコードかを管理できます。通常の運用時には気にする必要がありませんが、過去のデータなどで既に無効になったユーザを所有者として設定したいことがあると思います。ですが無効になったユーザは所有者として指定することができません。そのためこういった操作を行うには一時的に有効化にして設定していく必要があります。

検証してみたところApex処理から所有者更新処理を行ってもエラーとなります。

開発者コンソールのクエリエディターでも不可です。

Apexトリガ経由でもエラーとなりました。

ですが無効ユーザを所有者にセットできる特殊なパターンがあります。Apexトリガのafter updateで参照先レコードの所有者を更新する場合です。今回取引先と取引先責任者で確認しました。

更新前の取引先

更新前の取引先責任者

検証用に下記のトリガを用意しました。

※雑につくった書き方です。通常の開発ではマネしないでください。。

これで取引先責任者を更新してApexトリガを動かすと無効ユーザで更新できます。

ということで上記のようなパターンなら無効ユーザでも所有者としてセットすることが可能です。

補足

今回の件ですが、始めに上記パターンで所有者をセットできたことに気づきました。それでApex経由なら無効ユーザでも大丈夫と勘違いしたのですが、それができるのは一部のパターンだけで実際にはApex経由でも所有者としてセットできないみたいです。なので過去データをキレイにする場合は一時的にユーザを有効化して更新してから無効に戻す必要があります。

おまけ

この検証中にもう一つ気づいた仕様があります。無効になったユーザのレコードを引き継ぐため所有者を有効なユーザに変更したときの場合です。取引の所有者を切り替えると取引先責任者の所有者も自動で切り替わりました。無効ユーザの扱いまわりはこういった仕組みが用意されているみたです。