営業部門における鉄板"Chatter活用方法"

この記事で学べること営業部門で使われるchatterの活用方法Salesforceのレコードに紐づくコミュニケーション方法Chatterグループを使った、特定のグループでのコミュニケーションChatterを使ってダッシュボードを他の人に共有する方法本日は営業部門で効果的にChatterを活用頂ける代表的な使い方を3つご紹介します。​Chatterを活用した情報共有を行うことで、リード情報や商談情報にすぐにアクセスすることができます。また顧客・案件管理といった営業担当者の活動を可視化することも可能になります。レコード（商談）フィードでのコミュニケーションChatter内で商談に関する情報共有を行うことで対象商談や取引先にワンクリックでアクセスできるため、１つの画面上で知りたい情報を簡単に得ることができます。​ここでは例として株式会社A様の商談を使ってコミュニケーションのやりとりを見ていきましょう。[商談]タブから該当レコード[株式会社A]を開きます。商談レコード内のChatter画面に共有したい内容を入力し、[共有]ボタンをクリックします。​その後、[Chatter]タブを開くと先ほどの商談レコード内で共有した内容がChatterにも反映されています。​自分宛にコメントが届くと、右上のベルマークから確認することができます。これなら投稿に対してコメントがあると、どの画面上で操作をしていても通知にすぐ気づくことができますね。​レコード上でコミュニケーションをとることで得ることができるメリットを挙げます。ユーザや商談情報などの各レコードをChatter内で呼び出すことができる自分宛のコメントはバッジ表示により通知してくれるため、タイムリーに返信が可能Chatterでのやりとりは関連するリード情報や商談情報側にも残るので、履歴管理もできる商談情報側での履歴はこのようになります。​Chatterグループでの質問や相談Chatterグループではキーワード毎のグループを作ることできます。チームやプロジェクトメンバー間の情報共有をスムーズに行うことができます。ここでは[情報共有]というChatterグループを作成し、次回の社外イベントで配るエコバックの色についてのアンケート、新規顧客の獲得に対する案や対策をグループメンバーに求めてみます。​​​質問では営業担当者1の方がコメントしてくれています。アンケートでは3人が回答してくれていますが、アンケート投稿の右下をみると既読者は４人いますね。このように既読者人数に対して、何人が回答しているのかといった回答率も簡単に確認することができます。​​Chatterグループで得ることができるメリットを挙げます。質問やアンケートを簡単に作成できる投稿に対して参照（既読）者の回数確認や、いいね！などメンバーの反応を確認しやすい所属チーム用、個別指示用、情報共有用といった必要に応じたグループの使い分けが可能ダッシュボードのグラフをChatterフィードに投稿Chatterフィードに投稿することで最新の活動状況を共有することができます。営業担当者の入力漏れや、異常値や売上進捗などのグラフを営業マネージャーがChatterに投稿することで最新の活動状況を共有することができます。​まず[ダッシュボード]タブから対象となるダッシュボードを選択します。コンポーネント右上の[展開]をクリックすると[コンポーネントを共有]が表示されます。[コンポーネントを共有]をクリックすると、選択したダッシュボードとともにコメントも入力して投稿することができます。​​ここでは＠東地区所属チームに今月の目標売上金額をチームメンバーに共有してみました。目標売上金額300万円に対して、現時点では170万円みたいですね。東地区所属チームの営業担当者は残り130万円を目標にすればよいことがわかりました。​ダッシュボードをChatterフィードに投稿することで得られるメリットいくつか挙げます。営業担当者の入力漏れや売上進捗などのグラフをグループ内で共有会議で使用する資料や連絡等を、最新の状態で共有​以上３つが営業部門での代表的なChatterの活用方法でした。​Chatterの場合、フォロー対象がユーザだけではなく、商談のレコードやファイルなどの社内「情報」をフォローできる点が大きな特長です。メールでのやり取りだけですと、顧客や案件情報の詳細を把握するのに限度がありますが、Chatterを活用することで、1つのレコード上で必要となる複数の情報を確認できます。添付ファイルにおいてはメールをさかのぼって探さなくても、該当するレコードにアクセスするだけで簡単にファイルを見つけることもできます。​「どのような情報が必要とされているのか」、「誰に共有する情報なのか」といった情報共有の目的を明確にし、最新情報をキャッチアップすることが営業部門でChatterを効果的に活用することにつながります。​またChatterはSalesforceモバイルアプリケーションに対応しているので外出先でも簡単に確認可能です。FacebookやTwitterのような感覚でビジネスシーンでも利用できるので、営業部門で是非活用してみてください。考慮事項ダッシュボードをChatterに投稿するには、レポートダッシュボードの事前作成が必要ダッシュボードで[コンポーネントを共有］ボタンを表示するには以下の設定が必要[クイック検索]ボックスに[レポートおよびダッシュボードの設定]と入力し、[ダッシュボードコンポーネントスナップショットを有効化]のチェックボックスをオンにする学習ツールChatterのフィード追跡（ヘルプドキュメント）フィード追跡の有効化（Trailhead)投稿、アンケート、質問の作成Chatter でのダッシュボードコンポーネントの画像の共有（ヘルプドキュメント）Chatter へのダッシュボードコンポーネントのスナップショットの投稿（ヘルプドキュメント）​​

社内コミュニケーションを円滑にするヒント

この記事で学べることChatterで情報を収集するために有効な機能Chatterで適切に情報を発信するコツChatter有効活用ポイント1. 情報のピックアップ（選択）とストック（蓄積）社内SNSとして活用できるChatterですが、投稿数が多いと過去の投稿はどんどん流れてしまい、求めている情報がなかなか見つけにくいと悩まれている方も多いのではないでしょうか。Chatterの４つの機能を使いこなすことであふれる投稿の中から欲しい情報をすぐにピックアップすることができ、ストックしておくことも可能です。グループの作成：部やチーム、キーワード毎にグループを作成して情報共有が可能なため、目的やテーマにそった、求めている情報が集約ブックマーク：保存しておきたい、あとで見返したい投稿をブックマークすることで必要な時に確認ができる#ハッシュタグ：関連、共通するトピックを一つにまとめることができるため、情報収集が簡単にグローバル検索：全体から検索することで関連ワードをすばやく入手。フォローしていない人が投稿した資料や、ナレッジも情報として吸収することができる​対象となる投稿の右上の[▼]をクリックすると、[ブックマークする]と表示が出ます。ブックマークをすると、投稿右上に黄色の三角マークがつきます。また左側の[ブックマーク済み]にはブックマークをした投稿が格納されているので、簡単に確認することができます。２．投稿について投稿画面では投稿内容を工夫できるような機能がいくつかあります。“＠”メンションで名前を入力することで対象となる人に向けて通知、“/”スラッシュからレコード名を入力することで、Chatterから対象のレコードにワンクリックでとぶことができます。また宛先の下の[クリップ]のマークをクリックすると、ファイル添付をすることができます。​太字や下線、箇条書きを使うことで、より投稿が見やすく内容を明確に伝えることができます。​また、ファイルを添付したあとに修正箇所が発覚し、ファイルを差し替えたい場合があります。​同じような名前のファイルを再添付したら、ファイル数が多くなるだけでなく、過去と最新のファイルとの見分けがつかなくなってしまう可能性があります。そんなときにぜひ使っていただきたいのが[新しいバージョンをアップロード]です。​対象となるファイルをクリック｜ [▼]｜[新しいバージョンをアップロード]をクリックすると、新しいファイルとコメントを添付することができます。これでファイルが重複せず、最新のファイルを共有することができますね。[ファイル詳細を表示]をクリックすれば、アップロードした過去のバージョンを確認することも可能です。3. フィードと並び替えオプション各Chatter フィードで使用可能な並べ替えオプションと検索条件オプションは異なります。詳細については学習ツールにURLを記載していますが、ピックアップしてご説明したいと思います。 [最近の活動]と[最新の投稿]による投稿の並び替えフィード上にある[並び替え]を選択すると、投稿の並び替えをすることができます。​フィードをコメントの新しい順番に並び替える場合は[最近の活動] 、フィードを投稿の新しい順番に並び替える場合は[最新の投稿]を選びます。私のドラフトとストリームとは？​左側のフィード一覧をみると、[自分がフォローするもの]、[参照したグループ一覧]などありますが、[私のドラフト]や[ストリーム]とは何のことかご存知でしょうか。​私のドラフトとは、「編集した投稿内容を下書き保存したい」といった場合に非常に便利です。ドラフト投稿機能では、Chatter 投稿の作成時にファイル、リンク、画像、メンション、ハッシュタグ、他のリッチテキストなどのコンテンツを含む投稿が、入力時に自動で下書き保存されます。​保存された投稿内容の右側にある[▼]をクリックし、[編集]、[公開]、[削除]のいずれかで投稿内容を完成させることができます。​Chatterストリームとは、複数の関連フィードをストリームという 1 つのビューにまとめて作成するカスタムフィードのことです。最大 25 個の異なるフィードやフィード種別の投稿を組み合わせて最大 100 個のストリームを作成できます。たとえば、現在取り組んでいるプロジェクトに関して投稿されたさまざまな情報を入手したい場合、ストリームを使用すれば、プロジェクトに取り組んでいるグループ、関連するレコード、担当者からのフィードを集約することができます。​このようにフォローするレコードを９つから選択することができるので、関連するさまざまな情報を集約し、1 つのストリームの中で全体像を把握できるようになります。考慮事項[私のドラフト] を使用する場合は[ドラフト投稿]が有効になっているか確認学習ツール新しいバージョンのファイルのアップロード（ヘルプドキュメント）フィードの使用（ヘルプドキュメント）ドラフト投稿（ヘルプドキュメント）Lightning ExperienceのChatter：Chatterエキスパートになる（Trailhead）まとめChatterでは多くの便利機能が搭載されているため、今回ご紹介できなかった機能も含め、さまざまな使い方ができます。​情報共有をメールではなく、Chatter内で行うことでファイルを添付する際にはサイズを気にせず送信することができ、最新ファイルをすぐに差し替えることが可能です。​また、送信者/受信者しか確認できないメールに比べて、Chatterはタイムライン表示なので見たい人が見る、営業担当者が変わった際に、タイムラインをさかのぼれば過去のやりとりなど確認ができるなどスピードや、生産性の向上にもつながります。​ぜひChatterを社内コミュニケーションツールとして有効活用してみてください。

サイバー脅威に対するSalesforceの監視、検出、対応

この記事で学べること不正アクセス、ランサムウェア、DoS/DDoS攻撃等、多様なサイバー脅威に対してSalesforceはどのような監視、検出、対応を行っているか理解できる。​1.  はじめに本記事では不正アクセス、ランサムウェア、DoS/DDoS攻撃等、多様なサイバー脅威からSalesforceがどのようにしてお客様にご利用いただいているSalesforceの本番システムのインフラストラクチャーを保護しているかを説明します。​2. インシデントレスポンス計画の整備Salesforceではインシデントレスポンス計画が整備されています。Salesforceでは、標準化されたインシデント管理プロセス、各インシデントに応じたインシデント対応マトリックスおよび手順書が存在し、これに従い24時間365日体制で、セキュリティインシデントの軽重を問わず、お客様にサービスを提供する本番システムの安定性を維持するために、速やかな対応がとれる体制が整備されています。 インシデントレスポンス計画は以下のリンクからご確認いただけます。​また、このインシデント対応計画は、SalesforceのCSIRTチームによって四半期ごとにテストおよび訓練されています。3. CSIRTの設置Salesforceでは、セキュリティ・インシデント対応チーム(Computer Security Incident Response Team。以下CSIRT)を設置しており、正式なインシデント管理プロセスに従って調査、管理、コミュニケーションおよび解決の活動を行っております。4. CSIRTによるログ監視とセキュリティインシデントの検知と対応Salesforceの本番システムのインフラストラクチャーは、ネットワーク機器、サーバ、ファイアウォール、侵入検知システム、マルウェア対策、ファイル改ざん検知、データベース等のログを記録しています。これらのログはログ管理サーバで集約・相関分析され、CSIRTチームが24時間365日ログを監視しており、セキュリティアラートの通知を受け取った後、不正侵入の試みを検出した場合は、該当通信の遮断、マルウェアの駆除などの対応が即座にできる体制としています。このシステムログは1年間保管しており、また、システムログは改ざんや不正アクセスから保護するための様々なコントロールを実施しています。​また、DoS/DDoS攻撃については、ネットワークセキュリティチームが24時間365日体制でネットワークトラフィックを監視しており、DoS/DDoS攻撃を検出した後、社内対応プロセスに従い、迅速にDDoS攻撃を緩和する対応が行われます。​5. 脅威インテリジェンスを活用したプロアクティブな脅威の検知と対応上記では、セキュリティアラートをCSIRTがリアクティブに対応するインシデント監視、対応プロセスを説明しましたが、Salesforceではリアクティブにインシデントの監視、対応を行うだけでなく、プロアクティブなサイバー脅威への検出、対応も実施しています。​SalesforceのCSIRTは広範なパブリックおよびプライベートの脅威インテリジェンスフィードとコミュニティを常時監視し、最新のサイバー脅威を分析しています。これらの脅威インテリジェンス(IoCとTTP)は、新しい検知シグネチャとしてセキュリティ監視システムに自動的に配布されます。脅威インテリジェンスは未知の脅威の検出と攻撃の検出と対応にかかる時間を短縮するためにも利用しています。​また、これらの脅威インテリジェンスを使用して、SalesforceのDetection & Response チームはSalesforceの本番システムのインフラストラクチャー内に疑わしいアクティビティがないかどうかの検出を行う機械学習を使用したアノマリーベースによるスレットハンティングも実施しています。​また、Salesforceの脅威インテリジェンスチームはSalesforceの本番システムのインフラストラクチャーをターゲットに攻撃している攻撃グループを常時監視し、その影響度、攻撃可能性の観点から攻撃グループの優先付けを行い、定期的に攻撃グループの評価を実施しています。そして、それぞれの攻撃グループが使用する攻撃手法に対して、当社の事業運営とお客様のビジネスに損害を与えないように、随時、Salesforceの本番システムのインフラストラクチャーの防止、検知、対応措置の見直しを実施しています。​6. セキュリティインシデントが発生した場合のお客様への通知セキュリティインシデントが発生した場合、すべてのお客様に影響がある事象はTrustサイトに掲載されます。個別のお客様のセキュリティインシデントについては管理者とセキュリティコンタクトとして登録されたユーザーにメールが送信されます。セキュリティコンタクトの登録方法は以下のリンクをご参照下さい。​​

Summer '23 お問合せする前に知って頂きたい情報

Summer ’23 で皆さまに知ってほしい情報を、リリースノートから抜粋してまとめました。※ 本記事の内容は新機能情報の中から一部抜粋して記載しております。英語版と日本語版の差異があれば英語版を優先するものといたします。また、その他の更新情報などは必ずリリースノートを参照ください。※ ナレッジ記事の右下にある言語設定から「日本語」を選択ください。英語のみ表示される場合は英語での確認をお願いいたします。※ 製品ごとの各新機能を紹介するオンデマンド動画はSummer’23 特設ページからご覧ください（6/30 更新）新たに追加されたリリースノート抜粋情報ICU ロケール形式の有効化（リリース更新）どこにいても業務を遂行できるように、International Components for Unicode (ICU) ロケール形式を採用します。多要素認証が Salesforce によって自動有効化された後のアカウントのアクセス再取得2022 年 2 月 1 日、Salesforce 製品にアクセスするときに多要素認証 (MFA) を使用する契約上の要件が有効になりました。新しい組織でデフォルトでブロックされる OAuth 2.0 ユーザ名パスワードフローSummer '23 以降で組織を作成した場合、OAuth 2.0 ユーザ名パスワードフローはデフォルトでブロックされます。ユーザ名パスワードフローにはセキュリティリスクがあります。代わりに、OAuth 2.0 クライアントのログイン情報フローを使用することをお勧めします。[オプトアウト済み] 項目の状況の使用お客様からのフィードバックに基づいて、最近更新された項目値をプロスペクトの [オプトアウト済み] 項目の情報源として使用できるようになりました。​※ オンラインコミュニティで詳細を投稿しておりますので、こちらもご確認くださいケースメール通知のシステムアドレスとしてデフォルトの No-Reply アドレスを使用 (リリース更新)[設定] の [組織のアドレス] ページから、デフォルトの No-Reply アドレスを設定します。[特別な目的の組織のメールアドレス] にメールアドレスを追加し、新しいデフォルトの No-Reply アドレスに送信される検証メールで説明されている手順に従います。便利になります/使い方が変わります！すべての検索条件を 1 か所に配置してユーザインターフェースを改善1 つのポップアップウィンドウにすべての検索条件オプションが表示されるようになったため、絞り込みプロセスが簡素化され、時間が節約されます。UI 要素の色のコントラストの改善テキスト以外の UI 要素 (ボタンやチェックボックス など) や、一部のテキスト UI 要素 (リンクなど) を表示するときの色のコントラストがアクセシビリティ基準に合わせて改善されました。ユーザのメールアドレスの検証Spring’23からユーザのメールアドレスが未検証の場合、メール送信ができなくなりました。メールアドレスを検証するためには以下の2つのどちらかを行う必要がありました。パスワードリセットを行うApex メソッドを利用するSummer'23ではメールアドレスが未検証の場合ユーザレコードの [メール] 項目の横に「検証」というリンクが表示されるようになり、本リンクをクリックすることで簡単に検証用メールがユーザに送信できるようになりました。メールに記載されている URL をクリックすることで、「検証」の表記が「検証済み」に変わりメールアドレスの検証が簡単にできるようになります。CASESAFEID関数の変更CASESAFEID関数では、有効な15文字のSalesforce IDのみが、大文字と小文字を区別しない18文字のIDに変換されるようになりました。SSO ログインでの Salesforce MFA の使用SSOログインでSalesforce多要素認証 (MFA) サービスを使用する方法が新しくなり、改善されました。ユーザのMFAを有効にした後、SSO設定ページで設定を選択して簡単にMFAをSSOに拡張できます。拡張トランザクションセキュリティフレームワークのログイン情報の監視ユーザのログインフローが安全であることを検証するために、拡張トランザクションセキュリティフレームワークのLoginEvent オブジェクトで [認証メソッド参照]、[ログインサブ種別]、および [ログイン種別] 条件を使用して監視できます。拡張コンテンツを使用したカスタムドメインの設定とメンテナンスの詳細の確認カスタムドメインを使用して、“https://www.example.com”などの所有するカスタムドメインで Experience Cloud サイ トを提供し、ブランド設定された環境をユーザに提供します。制約が加わります/ご自身の環境をご確認ください！不可になった新規プロセスの作成プロセスビルダープロセスの廃止に向けた次のステップを実行するために、新規プロセスは作成できなく なりました。既存のプロセスビルダープロセスは引き続き有効化、無効化、編集できます。​MFA の自動有効化の続行: お客様の組織に適用されるタイミングと方法の確認 (リリース更新)Salesforce では、2022 年 2 月 1 日より、Salesforce 製品にアクセスするすべてのお客様に多要素認証 (MFA) の使用を義務付けています。期限切れの Sandbox ライセンスの管理Sandbox 割り当てを超えた場合、最も長い時間使用されていないSandboxから適切な数のSandboxがロックされます。また操作を何も行わなず、ロック期間が 60 日を超えた Sandbox は削除され、復元できなくなります。ゲストユーザから送信されたメールの制限 (リリース更新)Summer’23から、組織はゲストユーザレコード内の未検証のメールアドレスからメールを送信することが制限されます。 この更新を確認するには、[設定] から [クイック検索] ボックスに「リリース更新」と入力して、[リリース更新] を選択します。[Restrict Emails Sent from the Guest User (ゲストユーザから送信されたメールの制限)] の手順に従います。ケースメール通知のシステムアドレスとしてデフォルトの No-Reply アドレスを使用 (リリース更新)[設定] の [組織のアドレス] ページから、デフォルトの No-Reply アドレスを設定します。[特別な目的の組織のメールアドレス] にメールアドレスを追加し、新しいデフォルトの No-Reply アドレスに送信される検証メールで説明されている手順に従います。デフォルトの No-Reply アドレスを検証したら、[リリース更新] で [テスト実行] を設定して開始します。この更新は、Spring '21 で最初に使用可能になり、Spring '23 で適用される予定でしたが、適用日が Summer '23 に延期されました。対象の方はご注意くださいService Cloud Voice コンタクトセンターの最新の機能強化の取得（Service Cloud）コンタクトセンター向けの Service Cloud Voice の機能強化とバグ修正を活用します。Summer’23から各組織が更新されたタイミングでコンタクトセンターのアップデートが行われます。注) 既存のコンタクトセンターを更新する為には、今まで通り手動で実施する必要があります。Salesforce Edge ネットワークへの移行に向けた Experience Cloud サイトの準備Salesforce Edge ネットワークが、Summer ‘23 からローリング方式でリリースされます。対象のお客様にはメールが送られているので、ご確認、ご対応お願いいたします。開発者（Developer）向けLightning Web コンポーネント用および Aura コンポーネント用 Lightning Web セキュリティの使用 (正式リリー ス)Aura コンポーネント用 Lightning Web Security (LWS) が正式リリースされました。非同期 SOQL の廃止非同期 SOQL は、Summer '23 にすべての Salesforce 組織で廃止される予定です。この廃止により、非同期SOQLをご利用のお客様は代替の実装を行う必要があります。Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止 (リリース更新)当初Summer’23で予定されていたSalesforce Platform APIバージョン21.0 ~ 30.0の廃止は、Summer’25に延期されましたMarketing Cloud (Account Engagementを除く）※ 日本語のリリースノートは6月以降公開予定のため、英語のリリースノートから2点抜粋して記載。本セクションは6月以降に更新いたしますUpdate Legacy REST API Routes AccessExpand Mobile Reporting with New Dimensions and Measurements​

APIバージョンを定期的に更新しましょう

この記事で学べることAPIバージョンを定期的に更新することの重要性APIバージョンのサポート対象期間APIとはAPI（Application Programing Interfaceの略）は、外部システムから自システムに対するリクエストを受け取るために用意された窓口（インターフェース）です。外部システムからSalesforceの情報にアクセスする必要がある時にはSalesforceのAPIを使用します。例えば、基幹システムの売上データをSalesforceに取り込む処理（夜間バッチなど）であったり、社内システムからのリクエストでSalesforceのデータを参照する時に使用します。APIのバージョンAPIにはバージョンという概念があります。APIを使用するときは、以下のように宛先とバージョンを指定してアクセスをします。以下の例では、外部システムから、Salesforceに対してSOAP APIの54.0のバージョンでアクセスをしています。上記例はSOAP APIですが、他にもいくつか種類があり、いずれも、バージョンを指定する必要があります。※APIの種類については、Salesforce プラットフォーム API について知る（Trailhead）をご確認ください。​APIの最新バージョンは、Salesforce の年3回のバージョンアップのタイミングで更新されます。​例Summer ’22： APIバージョン55.0 Winter ’23：APIバージョン56.0・・・​しかし、APIバージョンは外部システムによって明示的に指定されるため、お客様（外部システム）にて定期的に新しいバージョンに更新していただく必要があります。そして、Salesforceではあらかじめ最低限のサポート対象期間が決まっています。​APIのサポート対象期間Salesforce は、API バージョンを最初のリリース日から最低 3 年間サポートします。API の品質およびパフォーマンスを充実させ、改善するために、3 年を超えるバージョンのサポートは停止される場合があります。API バージョン廃止の予定がある場合、サポートが終了する最低 1 年前までに事前通知されます。​※実際に廃止になった例は、Salesforce Platform API バージョン 7.0 ～ 20.0 の廃止（ナレッジ）をご覧ください​APIをご利用の場合は、上記サポート期間を目安に定期的にAPIバージョンを更新いただくことを推奨します。​APIバージョンの更新更新箇所の確認：APIバージョンを更新する際は、まずはどこでAPIを使用しているかを把握している必要があります。開発を外部発注した場合は、ベンダーから受け取った仕様書に、使用しているAPIバージョンの記載があることを確認し、大切に保管します。社内で開発をする場合も、APIバージョンを含めた仕様を後で確認ができるように管理方法を決めて、社内で共有しておきましょう。​更新作業：実際のAPIバージョン更新作業は、Salesforce以外のシステムの設定変更であったり、AJAX Toolkitを使用した開発をしている場合はデプロイが必要になります。そのため、通常はベンダーや開発者様にて実施いただく作業になります。外部ベンダーへ依頼する場合には、社内プロセス（予算取りや承認申請など）に時間がかかることもあるかもしれませんので、早めに準備をしておきましょう。​その他：データローダもAPIを使用します。PCの画面上でデータローダを起動しご利用いただいている場合は、Salesforceの[設定]画面からデータローダのダウンロードをする事で、新しいAPIバージョンを使用する最新のデータローダを再インストールすることができます。データローダのツール自体のサポートは最新バージョンのみとなりますが、少なくとも3年に1度はデータローダを再インストールすることをお勧めします。学習ツールSalesforce プラットフォーム API について知る（Trailhead）Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止（サクセスナビ）Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止（ナレッジ）SOAP API 開発者ガイドREST API 開発者ガイドBulk API 開発者ガイドデータローダのインストール手順（ナレッジ）まとめSalesforceのAPIバージョンは、年3回のバージョンアップで更新されるリリース日から3 年を超えるAPIバージョンのサポートは停止される場合がありますAPIバージョン廃止の影響を防ぐため、定期的にお客様でのAPIバージョン更新作業を推奨します

(2023年2月) Salesforceの運用に関する重要なお知らせ

この記事で学べることSalesforce コア製品に関する重要な技術情報バージョンアップ情報やメンテナンス情報(バージョンアップ以外)、IP アドレスフィルタリングをしている場合に必要なIPアドレス範囲に関する情報、製品廃止情報、リリース更新などの重要情報セキュリティに関する重要なアップデート​動画で更新内容を学ぶhttps://play.vidyard.com/KbVvJ5UfNAUerk66H83XN6​​全ての資料をダウンロードして学ぶダウンロードはこちら記事で更新内容を学ぶ​本記事は「Salesforceの運用に関するお知らせ」の2月号となります。こちらの記事では、メンテナンス情報や技術情報、セキュリティ関連情報の構成で、特に重要な更新情報をピックアップしてご紹介いたします。必要なアクションをお客様にいち早く気づいていただくことを目的としていますので、毎月必ずご確認いただけますと幸いです。​​2023年2月のトピックはこちらになります。本記事では、前月との差分である赤字の部分と、特に重要な情報をピックアップしてご紹介します。​最初にSpring'23のリリースに関する情報です。2023年 2月12日にバージョンアップがあり、Spring '23になりました。3月13日~16日にかけて、恒例の新機能ウェブセミナーを開催予定です。Spring ’23 新機能リリースからお申し込みいただけるようになっております。また、Release Moduleの翻訳されましたので、ウェブセミナーの参加が難しい方は、ぜひTrailheadをご活用ください。​関連リンクSpring '23新機能リリースリリースノート（翻訳版）Release SiteSpring '23 Release HighlightsRelease in a BoxFeature matrix​こちらは、今までのKnown Issueサイトが新しくなったことのの共有です。Known Issueサイトでは、Salesforceの既知の問題を公開しております。カテゴリやステータスで絞り込みができて、問題の概要、再現手順、回避策等をご確認いただけます。ご自身の組織が影響を受けている問題があれば、[Report]をクリックすることで、問題をフォローすることができます。問題に更新があれば通知を受け取ることができますので、ぜひご利用ください。​続いて、少し気が早いですが、次期バージョンであるSummer '23のスケジュールです。Summer '23のリリースは、Sandboxが5月7日、本番環境は6月11日にバージョンアップの予定です。​関連リンク：Trustサイト次は、Spring '23リリースノートの更新情報です。先月までWinter '23の更新情報をお伝えしていましたが、今月からSpring '23のの更新情報になります。今回は、1月2日以降の更新内容の中から、管理者様に把握しておいていただきたい内容をピックアップしてます。​無効な選択リスト値の数の制限 (リリース更新)元々、リリース更新の位置付けだった制限が通常のリリースに変更されました。今まで無効な選択リスト値を無制限に使用することができていました。これによりパフォーマンスに影響が出ることがありました。Spring '23より、組織の健全性とパフォーマンスを改善するために、無効な選択リスト値の数を制限することができるようになりました。このオプションを有効化すると、項目毎に無効な選択リスト値の最大は4000になります。Lightning Web コンポーネント (正式リリース) と Aura コンポーネント (ベータ) での Lightning Web セキュリティの使用Lightning Web Security (LWS) は、Lightning Lockerに代わる、Lightning Web コンポーネント（LWC）のための新しいクライアントサイドセキュリティアーキテクチャです。Salesforceでは、LWSの段階的なリリースを継続しており、Spring '23では、LWS for Auraのベータ版がリリースされました。今回のリリースノートの変更点は、LWS for LWC（GA）とLWS for Aura（ベータ）機能がWinter '23で既に有効であった場合に、Spring '23の本番組織でのLWSの適用方法が纏まった表が追加されました。詳細はリリースノートをご確認ください。コンテンツ盗聴保護を有効化 (リリース更新)適用時期がSummer '23に延期されました。Visualforce ページとコンポーネントでの <script> および <style> コンテキストの式言語評価のエスケープ (リリース更新)リリース更新はキャンセルされました。メール検証を目的とするドメイン所有権の確認Spring '22から、Salesforceからメールを送信する際に、Fromのアドレスが既に検証済みでない場合、メール検証が必要になりました。Spring '23から、SSO経由でSalesforceにログインしているユーザは、管理者がDKIMの設定をしている場合にDKIMを使ってメール検証ができるようになった旨が1月23日に追記されました。また、その検証のタイミングに関する詳細が1月30日にリリースノートに追加されました。​​関連リンクWinter '23 リリースノート - リリースノートの変更メール-to-ケースの Lightning スレッドを使用した重複ケースの防止古くからメール-to-ケースをご利用のお客様にとって重要な内容です。メール-to-ケースでは、従来スレッドIDを使用してメールとケースを紐づけていました。数年前からリリース更新で、その仕組みをヘッダーベースのスレッドに切り替える予定でしたが、お客様からのフィードバックを元に、Spring '23にLightningスレッドをリリースしました。現在も従来のスレッドIDを使用している場合は、ぜひLightningスレッドへの切り替えのご検討をお願いします。Encourage Users to Update to the Latest Mobile Publisher App Versionこちらは拡張ドメイン関連の内容です。Aura のサイトテンプレートを使用しているExperience Cloud サイトの場合、Mobile Publisher for Experience Cloud アプリケーションをご利用のユーザーに対して、拡張ドメインをサポートするアプリケーションのバージョンに更新するよう促すメッセージを表示したり、更新を要求することができるようになったというリリースノートが追加されました。事前にアプリケーションを更新することで、拡張ドメインを有効化することによるサービス中断を回避することができます。ぜひこちらの新機能をご利用ください。Added a release note to announce a change to Salesforce mobile app access via iOS phone and Android web browsers.Spring '23から、Lightning Onlyのユーザが、iOS やAndroidのモバイル端末のブラウザでSalesforceにアクセスしようとすると、Salesforceモバイルアプリケーションの使用を促すページにリダイレクトされるようになりました。以前までは、Lightning Onlyのユーザであっても、Classicの画面が表示されていました。拡張ドメインのリリース (リリース更新)Spring ’23での自動有効化から組織を除外(オプトアウト)する手順が明確になりました。​​関連リンクWinter '23 リリースノート - リリースノートの変更​​続いて、MFAに関する内容です。​​まずはMFA適用に関するロードマップです。2月12日にSpring’23がリリースされましたが、そのタイミングで一部の組織についてMFAが自動有効化されました。次の自動有効化のタイミングは６月に予定されているSummer'23のリリースです。自動有効化の対象となる組織の管理者様には事前にメール通知が行われますので、Salesforceからのメールをご確認ください。​関連リンク多要素認証 (MFA) 適用ロードマップ​MFAの自動有効化については、Spring'23のリリースノートでも情報を公開しているので、改めてご確認ください。​​関連リンクMFA の準備: 自動適用が Spring ’23 で開始MFA の自動有効化: お客様の組織に適用されるタイミングと方法の確認 (リリース更新)Chatter Free および Chatter External ユーザの MFA の自動有効化および適用からの自動的な除外続いて、インフラ強化に関するアップデートです。​​許可すべき Salesforce の IP アドレスとドメインという公開ナレッジに更新がございます。Salesforceで使用しているIPアドレス範囲について、APNICとRIPEで使用しているIPアドレス範囲に更新があります。現時点では英語版のナレッジのみでの更新ではございますが、詳細は公開ナレッジをご参照ください。​​関連リンク許可すべき Salesforce の IP アドレスとドメインHyperforce 上の Salesforce サービスへの中断しないアクセスを維持するSalesforce アプリケーションからのメールを受信できるようにする​​続いてリリース更新に関するアップデートのご紹介です。​こちらでは、当初はSpring'23での適用が予定されていましたが、延期になったリリース更新を記載しています。延期になったリリース更新についてはヘルプ等をご覧いただき、それぞれの自動有効化日までにお客様組織に適用できるようにご計画いただければと思います。​​関連リンクケースメール通知のシステムアドレスとしてデフォルトの No-Reply アドレスを使用 (リリース更新)Visualforce JavaScript Remoting API の JsonAccess アノテーション検証の有効化 (リリース更新)ICU ロケール形式の有効化 (リリース更新)メンテナンス計画の頻度の項目からメンテナンス作業ルールへの移行 (リリース更新)（未翻訳）最新の情報は英語版をご参照ください​​続いて、次期バージョンであるSummer'23で適用されるリリース更新です。Summer '23で適用予定のリリース更新の中から管理者様に特にご認識いただいきたい更新を4つピックアップしてご紹介します。​​まずは「フローでのセッション ID へのアクセスを無効化」です。こちらは、フローの中で$Api.Session_ID 変数が使用できなくなるという更新になりますので、該当するようなフローを作成している場合は変更をご検討ください。​​関連リンクフローでのセッション ID へのアクセスを無効化 (リリース更新)Apex クラスへの明示的なアクセス権を適用するルールの無効化 (リリース更新)ナレッジ：Apex クラスへの明示的なアクセス権を適用するルールの無効化」リリース更新の準備フローオーケストレーションオブジェクトの共有の有効化 (リリース更新)​続いて、「Google Analytics 4」に関する更新です。Experience CloudサイトでGoogle Analytics トラッキングIDを使用している場合に更新が必要となりますのでご確認ください。次に、「Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止」です。こちらは特に重要な更新になりますので、のちほど詳細をご紹介します。​​関連リンクAura サイトから Google アナリティクス 4 への移行 (リリース更新)イベントログファイル生成のオプトイン (リリース更新)コンテンツ盗聴保護を有効化 (リリース更新)ゲストユーザによる承認申請の編集または削除の防止 (リリース更新)Salesforce Platform API バージョン 21.0 ～ 30.0 の廃止 (リリース更新)Lightning アプリケーションの CSRF トークンのセキュリティの機能強化 (リリース更新)​最後にMFAに関するリリース更新です。MFAのセクションでもご説明させて頂いた通り、Summer'23でMFAが自動有効化される組織の管理者様にはメールでの通知が行われますので、そちらもご確認ください。​​関連リンクケースメール通知のシステムアドレスとしてデフォルトの No-Reply アドレスを使用 (リリース更新)MFA の自動有効化: お客様の組織に適用されるタイミングと方法の確認 (リリース更新)​​続いて、その他の更新です。​​Spring'23では拡張ドメインの自動有効化が予定されていましたが、管理者様にて除外することができました。Summer'23でも自動有効化が予定されておりますが、管理者様にて除外することはできません。Summer'23リリース後に無効化することはできますが、一度有効化されますため、自動有効化による影響が発生する可能性もございます。そのためSummer'23までに拡張ドメイン適用のご準備を進めていただければと思います。​​関連リンク拡張ドメインのスケジュール​続いて、機能の廃止です。​​メンテナンス計画の[頻度] 項目と [頻度種別] 項目の廃止が進められており、2024年2月の廃止が予定されておりますのでご確認ください。​また、2023年6月以降、Salesforce モバイル アプリケーションのバージョンが228以下の場合、Salesforceにログインすることができなくなりますのでモバイルアプリケーションのバージョンの更新をお願い致します。​​関連リンクメンテナンス計画の頻度種別項目の廃止Salesforce モバイルアプリケーションのバージョン 228 の廃止​​「Salesforce Platform APIバージョン 21.0~30.0 の廃止について」です。こちらは、影響度の大きい更新の一つですので、毎月ご紹介しています。来年2023年6月をもちまして、APIバージョン21.0~30.0 は利用不可になる予定です。本件に関して、2月15日に製品コミュニケーションメールが送信されており、また機能廃止に関するダイジェストもメールで送信されていますので、そちらも併せてご確認いただき、早めのご対応をご検討ください。​関連リンクSalesforce Platform API バージョン 21.0 ～ 30.0 の廃止Salesforce Event Log File BrowserEventLogFile オブジェクトの API Total Usageイベント種別​最後に、コミュニティライセンスユーザにおけるSalesforce モバイルアプリケーションでのアクセスの廃止です。Summer'23のリリースを以って、コミュニティライセンスのユーザはSalesforce モバイルアプリケーションを使用してSalesforceにアクセスすることができなくなります。そのため、該当するような方法でのアクセスを行っているユーザ様につきましては、ブラウザの利用やMoblile Publisherのご利用をご検討いただけますよう、お願いします。​​関連リンクSalesforce モバイルアプリケーションコミュニティライセンスアクセスの廃止コミュニティライセンスを持つ新規ユーザに対するアクセス制限Salesforce モバイルアプリケーションコミュニティライセンスアクセスの廃止の計画​2月度分の更新情報は以上となります。最後までご覧いただき、ありがとうございました。

簡単な手続きを自動化してみよう

この記事で学べることSalesforceでは、業務負荷を軽減するためいくつかの自動化機能が提供されています。https://help.salesforce.com/articleView?id=process_which_tool.htm&type=5​今回はその中でも、わかりやすく簡単に設定できる“ワークフロー”をご紹介いたします。​注：実業務で自動化を検討する場合、こちらのTrailheadにも記載されているように、ワークフローのみでは処理が複雑/煩雑になる可能性があります。どの自動化ツールを利用するかは、自動化したいプロセスの複雑さと設定方法を加味して選択くださいワークフローとはワークフローは簡単な社内手続きや他のプロセスを自動化するためのツールで、「もしxxxだったら、yyyyという処理を実行する」という簡単な処理を自動で行います。その“xxxだったらyyyを”という定義が“ワークフロールール”です。​ワークフロールールにより、特定の条件が満たされたときに“ワークフローアクション”が実行されます。実行されるアクションは、即座に実行することも、または特定の日時に実行することもできます。設定手順1. オブジェクトどのオブジェクトのレコードで操作が行われたときに起動するかを選択。2. 評価条件ワークフロールールの評価するタイミングの設定。3. アクションToDo、メールアラート、項目自動更新、アウトバウンドメッセージから選択。4. タイムトリガ条件を満たしてから、アクションを実行するまでの期間を定義することができる。ある日付を基準に「○日前」「○時間後」など、時間単位か日単位かを設定。5. アクションToDo、メールアラート、項目自動更新、アウトバウンドメッセージから選択。※タイムトリガを使用しない場合は設定手順3までで設定は完了です。​ワークフロールールの活用事例ワークフロールールの活用事例について３つご紹介いたします。１．契約期限切れ前のフォローアップ​​ルール：契約終了の30日前になったら営業担当者に、20日前になったら、営業部長に契約更新をするためのメールを通知する​契約終了日が近づいているのにも関わらず、 [状況]が[Activated]になっている場合、30日前であれば営業担当者に、20日前になっても[Activated]から更新されない場合、営業部長にメール通知をするというものです。※時間ベースのアクションを2つ設定していますが、30日前に営業担当者によって更新された場合は、営業部長にはメール通知は届かなくなります。​２．ケースがオープンになった場合、顧客対応のフォローアップをするToDoの作成​ルール：大規模取引の新規ケースが作成されたら、営業部長にメールで通知し、フォローアップを取引先所有者に割り当てる​ここでいう大規模取引というのは、年間売上高が3億円以上または従業員数が1万人以上の取引先が対象です。この条件に当てはまる取引先ケースが作成された場合に、営業部長にその旨をメール通知し、フォローアップを取引先所有者に割り当てるというものです。​３．新規ユーザの自動有効化​ルール：新規ユーザが作成された場合に、ユーザを有効化しログインの許可する​新規ユーザが作成された場合に、まだ有効化されていないユーザを項目自動更新でユーザの[有効]チェックボックスに自動的にチェックマークつけることでSalesforceにログインできるようにするというものです。時間ベースのアクションとはルール適用時のワークフローは、ルール条件に一致した場合レコードの作成または編集直後にアクションが実行されるのに対して、時間ベースのワークフローはアクションの実行を将来のある時点に予約しておくことができます。​[クイック検索]ボックスで[時間ベースのアクション]と入力します。ここで予約されているアクションを確認することができます。​​時間ベースのワークフローの制限や考慮事項評価条件でレコードが [作成されたとき、および編集されるたび]に設定した場合、時間ベースワークフローアクションを設定することはできない一度ルール条件に合致してアクションをセットした後、レコードが更新されてルール条件を満たさなかった場合、アクションは実行されないレコードが更新され、評価条件をレコードが [作成されたとき、およびその後基準を満たすように編集されたとき] に設定した場合は、自動的にレコードの待機中のアクションをキューに戻すことができる 学習ツールワークフロールールの作成（ヘルプドキュメント）時間ベースのアクションとタイムトリガの考慮事項（ヘルプドキュメント）FAQ - 時間ベースのワークフロー（ヘルプドキュメント）まとめ以上がワークフロールールの活用事例のご紹介でした。​ルールに定義された条件に基づいて、自動的にタスクをユーザに割り当て、特定の項目を更新することができるワークフロールールは営業、マーケティング、サポートなどの自動化に役立ちます。​ワークフロールールをはじめとする自動化ツールを活用することで、業務の効率化だけでなく、業務ルールの徹底など様々なメリットがあるのでぜひご活用ください。​

日々の定型業務を自動化し時短＆効率化！「プロセスビルダー」を使いこなそう

この記事で学べることプロセスビルダーの概要プロセスビルダーの使用例レコード作成/更新できるオブジェクトワークフロールールでは該当オブジェクトのレコード、および親レコードの更新のみが可能ですが、プロセスビルダーでは、子レコードの作成、更新も行うことができます。​プロセスで実行できるアクション・レコード作成と更新：新規レコードの作成、関連付けられたレコードの項目更新・Chatter投稿：ユーザ、Chatterグループ、プロセスを開始したレコードにフィードを投稿・承認申請：ユーザが手動で申請することなく、レコード承認申請を自動送信・フロー起動：複雑なビジネスプロセスを自動化するフローを起動・Apex：カスタマイズされた機能を追加するApexメソッドを呼び出す・クイックアクション：オブジェクト固有のアクションまたはグローバルアクションを使用して、レコード作成と更新、活動の記録を行う​プロセスビルダーではメールアラート、項目自動更新のほか上記のアクションがサポートされています。プロセスを開始するタイミングプロセスの開始時期を識別します。次の場合に開始されるようにプロセスを設定できます。・レコードが変更されたとき・プラットフォームイベントメッセージを受信したとき・別のプロセスから呼び出されたとき※この項目は、新規プロセスの作成時にのみ使用できます。プロセスビルダーを利用した設定例プロセスビルダーの使用例について３つほどご紹介いたします。例1．商談が成立/不成立したらChatterに投稿​​商談が成立の場合、[東地区所属チーム]のChatterグループに[商談名]、[金額]、[商談割引金額]を添えたメッセージを投稿商談が不成立の場合、[東地区所属チーム]のChatterグループに[商談名]、[金額]、[商談不成立の理由]を添えたメッセージを投稿​今回はこの２つの条件に当てはまるプロセスを作成しました。ではこのプロセスが実行すると、どのようにChatterグループに投稿されるのでしょうか。こちらをご覧ください。​​このように商談が成立/不成立した場合、自動的にChatter（東地区所属チーム）への投稿をすることができ、アクションによって投稿内容を変更することもできます。メール通知でなくChatterグループであれば、東地区所属のチームメンバー全員が商談結果を把握することができますね。​例2. 商談の割引率が30％以上の場合、上司の承認を得る必要がある​商談レコードページの[承認申請]をクリックしなくても、商談の割引率が30％以上の場合は自動的に上司に申請通知が届くようになります。[承認プロセス]では事前に作成した「商談値引き申請」プロセスを活用します。レコード承認申請を自動送信してくれれば、ユーザが手動で申請する必要がないため申請漏れを防ぐことができますね。​​例3. 取引先の請求先住所が変わったら、関連する取引責任者の住所（郵送先）も変更する​取引先の請求先住所が変えた場合、関連する取引責任者の住所も手作業で変更することなく、プロセスを組むだけで同時変更が可能になります。つまり関連したオブジェクトであれば、条件に合致するレコードの一括更新ができるということです。一定のルールに従ってアクションが実行されるので抜け漏れ防止や、人によって入力の仕方が異なるといったばらつきを回避することができますね。学習ツールLightning プロセスビルダー（ヘルプドキュメント）使用する自動化ツール（ヘルプドキュメント）クイックスタート：プロセスビルダー（Trailhead）まとめいかがでしたでしょうか。プロセスビルダーはワークフローよりも視覚的に作成することができ、自動化できるアクションが豊富にあります。​記録、報告、更新といった「定型化された手作業」を簡単に自動化することができるため、作業時間、工数の削減につながります。​こちらのTrailheadモジュールもご覧いただき、是非活用してみてください。​​​​

初心者向け！すぐに活用できるAccount Engagement(旧Pardot)の自動化シナリオ解説

見込み客を発見し確実にフォローするための３つの自動化シナリオを eBook を使ってご紹介シナリオ作成における設計方法と流れシーン別のメールテンプレートの考え方施策の「自動化」を検討しましょうここまで「施策実行」のフェーズでは「メールを送る」、「スコアリングする」、「営業へ通知をする」といった一つ一つのマーケティング活動をPardotで実装する方法についてご説明してきました。本記事ではそれらを「一連のシナリオ」として考え・設計し、自動化する方法について学ぶこ

ICUロケール形式の有効化

この記事で学べることICUロケール形式の有効化の背景と適用時期ICUロケール形式の有効化における変更点ICUロケール形式の有効化までの推奨アクションICUロケール形式の有効化の方法ICUロケール形式に関するFAQICUロケール形式の採用の背景Salesforce システム管理者は組織のデフォルトのロケールを設定できます。またユーザは個人設定ページで各自が使用するロケールを設定できます。このロケールにより、日付、時刻、通貨、住所、名前、数値などの表示形式（フォーマット）が制御されます​この表示形式について、現在の Salesforce Platform では Java Development Kit (JDK) ロケール形式を使用していますが、JDKロケール形式は定期的な更新がなく、国際標準との差異が発生しています。​Salesforceでは、Salesforce Platform を常に最新の国際標準に準拠させる取り組みの一環として、Winter '20 で新しいロケール形式（ICUロケール形式）を採用しました。ICUロケール形式の採用により、世界中の ICU 準拠のアプリケーションとのインテグレーションが向上します。​参考情報 : 新しい国際ロケール形式によるグローバル対応​​ICUロケール形式が有効化される時期Winter'20 のリリース以降に作成された組織では、ICU ロケール形式が既定で有効になっています。​Winter'20 のリリース(2019年10月)以前に作成された組織については、JDKロケール形式が使用されています。JDKロケール形式が使用されている組織が ICU ロケール形式を適用できるように、Salesforceでは リリース更新を提供しています。＊上記は設定画面のメニューより「リリース更新」を選択したときの画面です。​[ICUロケール形式を有効化]の自動適用について、当初はSpring’24を予定しておりましたが、自動適用時期が以下の通り変更となりました。Spring'24のリリースですべての組織で[ICUロケール形式を有効化]を適用をするのではなく、Spring'24以降で段階的に自動適用を進めます。[ICUロケール形式を有効化]が適用される30 ～ 60 日前にSalesforceは管理者様にメールで通知します。[ICUロケール形式を有効化]の段階的な適用はSummer'25のリリースまで継続されます。参考情報 : Winter’25 リリースノート : ICU ロケール形式の有効化 (リリース更新)​なお、システム管理者様は設定メニューを使用して、[ICUロケール形式を有効化]の自動適用をSummer'25のリリースまで延期させることができます。[ICUロケール形式を有効化]の適用をSummer'25のリリースまで延期する場合は、以下の手順を実施します。設定メニューのクイック検索ボックスに「ユーザーインターフェース」と入力します。「ユーザーインターフェース」をクリックし、設定画面を表示させます。「ユーザーインターフェース」セクションにある「ICU ロケール形式をスケジュールされたロールアウトの一環として有効化」という設定項目があるので、チェックボックスをオフにします。​＊この設定はJDKロケール形式が使用されている組織でのみ表示されます。​参考情報 : JDK ロケール形式の廃止と ICU ロケール形式の有効化リリース更新​​現在JDKロケール形式をご利用中の組織の管理者様は、SalesforceによるICUロケール形式有効化の自動適用を待つのではなく、影響範囲をご確認のうえで、計画的に適用できるようにご準備を進めていただくことを推奨します。​組織で使用しているロケール形式の確認方法現在のSalesforce Platformでは、JDKロケール形式とICUロケール形式の両方がサポートされています。Salesforce 組織でどちらのロケール形式が採用されているかを確認するためには「リリース更新」を確認します。​▼ICUロケール形式のリリース更新でテスト実行が有効化されている[設定]→[リリース更新]→[要対応]タブを押下。[ICUロケール形式の有効化]の[使用開始]をクリック[この更新は、テストできる状態になりました。]と表示されていたら、テスト実行によりICUロケール形式を利用中。それ以外の場合、組織は JDK ロケール形式を使用しています。​▼ICUロケール形式のリリース更新が適用されている[設定]→[リリース更新]→[アーカイブ済み]タブを押下[ICUロケール形式の有効化]の有無を確認。[アーカイブ済み]タブにある[ICUロケール形式の有効化]を確認して、ステップバイステップガイドに従ってテスト実行を完了している場合には、[完了]とマークされており、リリース更新の適用によりICUロケール形式を利用中。参考情報 : 組織が ICU と JDK のどちらのロケール形式を使用しているかの判断​​ICUロケール形式を有効化したときの変更点ICUロケール形式がSalesforce 組織に適用されることで変更が発生する項目は以下のものがあります。日付（Date）日付時間（Datetime）時刻(Time)通貨（Currency)数字（Number、Integer）​すべてのロケールにおいて上記項目で変更が発生するのではなく、ユーザが使用しているロケールによって変更点は異なります。例として、日本語、日本語（日本）、英語（アメリカ）の３つのロケールにおける変更点をご紹介します。ロケール毎の各データタイプ（形式種別）への影響は JDK と ICU ロケール形式の相違点 に掲載されていますが、影響のあるデータタイプは標準画面やカスタム画面では使用されない場合もあります。ICUロケール形式が有効化されたときの動作イメージは次のセクションでご紹介します。​参考情報 : JDK と ICU ロケール形式の相違点​​ICUロケール形式有効化時の動作イメージ「日本語（日本）」のロケールを選択している場合において、ICUロケール形式が適用された際の標準画面のイメージは以下のとおりです。Lightning Experienceの標準画面ではChatterの日付に「Date:Long」のデータタイプが使用されています。そして「日本語（日本）」ロケールの場合、「Date:Long」のデータタイプはICUロケール形式が有効化されたときの形式変更対象なので、表示形式が「2022/03/15」から「2022年3月15日」に変更されていることがわかります。しかし標準画面の他の項目では通常 Short のデータタイプが使用されており、「日本語（日本）」ロケールでは Short のデータタイプは形式の変更がないため、ICUロケール形式が適用されていても表示形式に変更はありません。​それでは次に、「日本語（日本）」のロケールを選択している場合において、ICUロケール形式が適用された際のVisualforceページのイメージを見てみます。​Visualforceページを使用していたとしても通常は Short のデータタイプが使用されているため、[日本語(日本)]のロケールではICUロケール形式が適用されても表示形式は変わりません。​「日本語（日本）」のロケールを使用していた場合の標準画面とVisualforceページを例にして動作イメージをご紹介しましたが、異なるロケールを使用していた場合の例として、「英語（アメリカ）」のロケールを使用していた場合の標準画面の動作イメージをご紹介します。「英語（アメリカ）」のロケールではICUロケール形式の有効化において「Date:Long」は形式変更対象ではなく、「Date Time:Short」が形式変更対象に含まれています。そして日付時間型項目では「Date Time:Short」のデータタイプが使用されているため、該当の項目において、「8/1/2022 12:00PM」から「8/1/2022, 12:00PM」に表示形式が変わっている（カンマが追加されている）ことが確認できます。このように、使用しているロケールによって表示形式が変更される項目が変わっていることが確認できます。​​Apex クラス/トリガ、および Visualforce ページを使用している場合の留意点ICUロケール形式はAPI バージョン 45.0 以降で使用できます。ApexやVisualforceページなどのカスタマイズで ICU ロケール形式を使用するには、Apex クラス、Apex トリガ、および Visualforce ページを最新の API バージョンに更新します。​ApexやVisualforceページなどのカスタマイズが API バージョン 44.0 以前を使用している場合、JDKロケール形式が返されるため、データの整合性の問題やエンドユーザの困惑が発生するなどの影響が発生する可能性があります。 ​以下に影響例の１つとして、API バージョン 44以前のVisualforceページを使用した場合の例をご紹介します。＊この例は[英語 (アメリカ)]ロケールを使用している場合の例です。[英語 (アメリカ)]ロケールでは日付時間項目[Date Time:Short]について影響がありますが、[日本語 (日本)]ロケールでは[Date Time: Short]や[Date:Short]は形式変更対象ではないため、この例に示すパターンのエラーは発生しません）​[英語 (アメリカ)]ロケールを使用している場合、[Date Time:Short]は形式変更対象であり、[Date Time:Short]は日付時間型項目で使用されているので、APIバージョン45以降のVisualforceページでは表示形式が変わります。しかし、VisualforceページのAPIバージョンが44以前の場合は、ICUロケール形式が使用できずJDKロケール形式が使用されるため、表示形式が変わりません。​APIバージョン44以前のVisualforceページは表示形式が変わらないのですが、Visualforce ページのインライン編集の処理では最新のAPIバージョンが使用されます。つまり、Visualforce ページで apex:detail を使用している場合、インライン編集時にはAPIバージョン44以前でもICUロケール形式を使用します。しかし、APIバージョン44以前のVisualforceページでは、ICUロケール形式が使用できないためエラーが発生します。以上がAPIバージョン44以前のVisualforceページを使用していた場合の影響例です。​もう１つ影響例をご紹介します。Apexクラスで以下のメソッドのようにロケール形式に依存するメソッドを使用している場合やLightningコンポーネントで$Localeを使用している場合には、ロケール形式の変更によって影響が出る可能性があります。​ロケール形式に依存するApexメソッド例Date.format()Date.parse()DateTime.format()DataTime.parse()DateTime.formatLong() などロケール形式を意識したカスタマイズを実装されている場合、形式の変更により現在のカスタムロジック（文字列の判定など）が正しく動作しなくなる可能性があります。​参考情報 : Apex クラス、Apex トリガ、および Visualforce ページの API バージョン​​ICUロケール形式の有効化までの推奨アクションICUロケール形式が適用されると、使用しているロケールによって日付・時刻・通貨等の表示形式が一部変更されます。​該当項目を使用した検索条件が利用されている場合（レポート、入力規則など）、なんらかの影響が発生する可能性があります。また、Apex クラス、Apex トリガ、Visualforceページにて、API バージョン44.0以前をご利用の場合はJDKロケール形式が返されるため、エラー等の問題が発生する可能性があります。​そのため、事前にSandbox等でICUロケール形式を有効化して動作テストを実施し、Salesforce組織での影響有無を確認の上で、本番環境で有効化することを推奨します。(Salesforceによる自動適用を待つのではなく、管理者様にて事前にテスト/評価、有効化していただくことを推奨します。)動作テストでは、表示上の確認だけではなくVisualforce ページのインライン編集やカスタムコードの挙動、インストール済みパッケージの動作等についても御確認ください。​参考情報 : ICU ロケール形式の採用に関する考慮事項​​ICUロケール形式の有効化の方法ICUロケール形式の有効化は「リリース更新」から実施します。最初にSandboxでICUロケール形式を有効化し、動作テストを実施します。影響がないことが確認されたら、本番環境でICUロケール形式を有効化してください。「リリース更新」を使用してICUロケール形式を有効化する方法は以下のとおりです。​１．[設定]→[リリース更新]→[要対応]タブを押下して、[ICUロケール形式の有効化]の[使用開始]をクリック２．[テスト実行を有効化]をクリック。３．[このリリース更新の影響を評価]の「完了」ボタンをクリックし、有効化​動作テストにあたっての事前確認事項Salesforce組織で現在使用されているロケールとユーザの確認SOQL クエリを使用して、組織で使用されているロケールと各ロケールのユーザ数を確認し、影響調査や動作テストが必要なロケールの種類を調べます。<SOQLクエリ>SELECT toLabel(LocaleSidKey) LocaleName, LocaleSidKey, Count(id) UserCount FROM User where IsActive=true GROUP BY LocaleSidKey​<クエリ実行結果のイメージ>*上記は開発者コンソールを使用してSOQLクエリを実行した結果のイメージです。この結果の例では、日本語/日本語(日本)/英語(アメリカ)が使用されていることが確認できます。​参考情報 : 使用中のロケールの判断​Apexクラス、Apexトリガ、Visualforceページ のAPIバージョンの確認ICUロケールを適用するには APIバージョンが 45.0以上の必要があります。APIバージョンが45.0未満の場合は、45.0以上に更新します。API バージョン 45.0 以上にアップグレードしない場合、ユーザに「無効な日付と時間です」といったParseException エラーが表示される可能性があります。​参考情報 : Apex クラス、Apex トリガ、および Visualforce ページの API バージョン​Apexクラスで使用しているメソッドの確認Apexクラスで以下のメソッドのように、ロケール形式に依存するメソッドで影響が無いか確認します。Date.format(),Date.parse(),Date.toStartOfWeek(),DateTime.format(),DataTime.parse(),DateTime.formatLong()等​影響がある場合は、ロケール形式に依存しないコードとするためのガイドラインを適用します。・標準メソッドを利用　- 日付形式のデータから”月”を抽出する場合は、Dateクラスの month()を利用する。　- 整数値と通貨値は、書式設定する必要が生じるまで書式設定のない整数として処理。 など・値に追加の処理を行う場合、ロケールに依存しない形式を使用・ユーザが選択しているロケール形式へのデータの変換は、そのデータ処理の最後のステップとする。​参考情報 : コードでのロケールに依存しないメソッドの使用​Lightningコンポーネントの確認$Localeを使用していると、ユーザが選択しているロケール形式が使用されるので、ICUロケール形式の適用によって影響を受ける可能性があります。そのため使用箇所がないか確認します。​参考情報 : Lightning コンポーネント開発者ガイド​​ICUロケール形式の有効化に関するFAQQ：ICUロケール形式の有効化後、[日本語（日本）]や[日本語]のロケールを使用した場合、Classicの標準画面では影響がありますか。A：Lightning Experience と Classicで差異はありません。Chatterの投稿時間等では表示形式に変更があります。​Q：ICUロケール形式の対象範囲は、REST APIや、SOAP API、Bulk APIも含みますか。A：SOAP/REST/Bulk APIではロケールに依存しないデータ型が使用されます。ただし、Apex クラスを公開するApex SOAP/REST web servicesではロケールに依存するデータ型が使用可能な為、影響がでる可能性があります。​Q：ApexやVisualforceを多用しているのですが、全てについてバージョンを上げる対応が必要でしょうか。A：例えばVisualforceページについては、44以下のAPIバージョンのままICUロケールを有効化すると、インライン編集での保存時にエラーが発生する可能性があります。予期せぬ問題が発生しないようにする為に、Sandbox上でAPIバージョンは45以上の新しいバージョンに上げて頂いた上で、動作確認テストを実施して頂く事を推奨しています。APIバージョン44以下のものが残る場合でも、Sandbox上でICUロケール形式を適用しての動作確認テストは十分に実施するようにしてください。​Q：ICUロケール形式が強制適用される時期は延長可能ですか。A：Summer'25までであれば、管理者様にて設定画面から延期することが可能です。​Q：ICUロケール形式が自動適用されたら、表示内容が変わったり、エラーが表示されるようになるのでしょうか。A：使用するロケールや、カスタマイズ内容によって影響が異なります。ICUロケールが適用された際に本番環境で影響が出ないように、事前にSandboxでの動作確認テストの実施をお願いいたします。​Q：ICUロケールの適用を Spring ’25 から Summer ’25 に延期するための期限はいつですか？A：ICUロケールの適用を延期するには、組織が Spring '25にアップグレードされる前に、[スケジュールされたロールアウトの一環として ICU ロケール形式を有効化] のチェックボックスの選択を解除する必要があります。​Q：リリース更新が失敗した場合は通知がありますか？A：はい。Sandbox または本番組織でリリースアップデートの適用が失敗した場合、組織管理者にメールが送信されます。​※最新の FAQ に関しては下記のナレッジ記事も併せてご参照下さいJDK ロケール形式の廃止と ICU ロケール形式の有効化リリース更新

Summer '24 リリースノート斜め読み

Forward-Looking Statements​本記事の内容は新機能情報の中から一部抜粋して記載しております。英語版と日本語版の差異があれば英語版を優先するものといたします。また、その他の更新情報などは必ずリリースノートを参照ください。​重要な更新Winter'25 で強制ログインが永久に無効にセキュリティを強化するため、'25 Winter 以降、ログイン URL のクエリ文字列パラメーターとしてユーザー名とパスワードを渡して Salesforce にログインする「強制ログイン」が無効になります。この変更により、URL 経由の強制ログインを使用している実装やサードパーティインテグレーションや、直接ログイン (自動ログイン) リンクが壊れます。サービスの中断を避けるため、強制ログインを使用しているインテグレーション機能を更新してください。本番組織への直接ログインの MFA がデフォルトで有効化Salesforce アカウントへの不正アクセスを防止するため、ユーザーのログイン時には多要素認証 (MFA) が必要です。お客様がこの契約上のセキュリティ要件を満たしやすくするために、新しい本番組織の稼働を開始するときに MFA は直接ログインプロセスのデフォルト設定となりました。Sandbox 組織はこの変更の影響を受けません。試用期間中の組織は、サブスクリプションに移行するまでは影響を受けません。​Service Cloudに関するリリース参照 ID の無効化と新しいメールスレッド動作への移行 (リリース更新)この更新により、参照 ID スレッドが無効になり、メール-to-ケースの Lightning スレッドに移行します。新しいメール-to-ケーススレッドの動作では、受信メールの照合に参照 ID は使用されません。代わりに、メールの件名または本文でセキュアトークンを使用して照合されます。一致が見つからない場合は、メールヘッダーに含まれるメタデータもチェックされます。この更新は Winter '21 で最初に使用可能になりました。セキュリティに関するリリースMFA が無効な場合の Salesforce システム管理者へのアプリケーション内リマインダーの表示Salesforce 製品での多要素認証 (MFA) の使用が 2022 年 2 月 1 日より契約上の必須要件となりました。MFA の使用を技術的に適用するという当初の計画の代わりに、新しい通知モデルを実装しました。組織全体の MFA 設定をお客様が無効にした場合、MFA 要件に準拠していないことになります。MFA が再有効化されるまで、組織のすべてのシステム管理者にアプリケーション内警告が定期的に表示されます。​対象: この変更は、すべてのエディションの Lightning Experience とすべてのバージョンのモバイルアプリケーションに適用されます。証明書の有効期限に関する通知の受取人の制限証明書の有効期限に関するメール通知を受け取るユーザーを制限できるようになりました。証明書を管理するシステム管理者にのみ、新しい「Receive Certificate Expiration Notification (証明書の有効期限に関する通知メールの受信)」ユーザー権限を割り当てます。また、通知メールには、有効期限が切れる前に証明書を更新する方法の詳細も記載されるようになりました。​対象: この変更は、Enterprise Edition、Performance Edition、Unlimited Edition、および Developer Edition の Lightning Experience および Salesforce Classic に適用されます。新しい設定ドメインの追加ブラウザーでサードパーティ Cookie がブロックされている場合に Lightning Experience の [設定] ページにコンテンツが正しく読み込まれるようにします。インターネットに対する一般的なアクセス権がある場合は、特に操作は必要ありません。会社でファイアウォールまたは許可リストを介してインターネットへのユーザーまたはサーバーのアクセスを制御する場合、IT 部門は会社の許可済みドメインのリストに *.salesforce-setup.com を追加する必要があります。このドメインで Salesforce の [設定] ページがホストされるようになっています。​​

多要素認証(MFA) 導入後に発生する可能性がある事象と事前にご理解頂きたいポイント

この記事で学べること多要素認証 (MFA) 導入後に発生する可能性のある事象日々のオペレーションやビジネスを止め無いために事前にご理解頂きたい MFA 利用のポイント背景Salesforce の 2022年2月より MFA の利用を必須化に伴い、非常に多くのお客様に MFA を利用して安全に Salesforce をお使い頂けております。利用の増加に伴い MFA 導入後のトラブルに関するお問い合わせも増えております。この記事では MFA 導入後に発生する可能性がある事象と日々のオペレーションやビジネスを止め無いために理解しておいて頂きたい点を紹介させて頂きます。MFA の運用を検討する一助となれば幸いです。多要素認証 (MFA) 導入後に発生する可能性のある事象Salesforce の MFA 導入後に発生する可能性のある事象として下記のような点が挙げられます。​何らかの障害(例：Salesforce の障害、お使いのスマートフォンの機器/通信障害)の影響で Salesforce の MFA を認証できない認証に必要なデバイスが紛失した・壊れた​いずれの場合でも複数の認証要素(例: スマートフォンで Salesforce Authenticator + セキュリティキー)をあらかじめ登録する事でリスクを低減頂けます。特にシステム管理者様については少なくとも 2 つ以上の検証方法を登録頂く事をビジネスを止めないためのベストプラクティスとして推奨させて頂いております。​MFA を有効化した後でシステム管理者がロックアウトされないようにするには?アクセス回復計画を準備して、通常の検証手段にアクセスできなくなった場合にシステム管理者が実行できる手順を用意しておいてください。次のベストプラクティスを検討してください。・各システム管理者は、少なくとも 2 つの検証手段を登録する必要があります。・バックアップセキュリティキーは、金庫など、職場の安全な場所に保管します。・ユーザと MFA 設定を管理する権限を持つアカウントを少なくとも 2 つ用意します。こうすることで、一方のアカウントがロックアウトされても、他方のアカウントを使用してアクセスを回復できます。通信障害等で Salesforce Authenticator の プッシュ通知が来ない場合通信障害や Salesforce の障害等が発生した際によく頂くお問い合わせとして Salesforce Authenticator の プッシュ通知が来ず認証ができないというご相談を頂きます。このような場合、下記のヘルプサイトに記載のように  Salesforce Authenticator に表示されている 6 桁のコードでも Salesforce にログイン頂く事が可能な場合がございますので、まずこちらを一度お試し下さい。​​Salesforce Authenticator のトラブルシューティングブラウザ上に表示される Salesforce のモバイルデバイスの確認ページで、「お困りですか？」をタップしてから、「別の検証方法を使用してください」をタップします。SalesforceAuthenticator からの 6 桁のコードを入力します。これは、電話がオフラインの場合でも機能します。​下記操作手順のステップとなりますので、ご参照下さい。(*Summer’22 リリース時点の画面キャプチャとなります。)​​お困りですか？をクリックします​​「別の検証方法を使用して下さい」をクリックします​「認証アプリケーションからのコードを使用」をクリックします​表示される画面の「確認コード」に Salesforce Authenticator に表示されている 6 桁のコードを入力し、「検証」をクリックします​補足:SSO (Single Sign On) を利用されているお客様最後に蛇足とはなりますが Salesforce の MFA 必須化に伴い複数のアプリケーションをご利用のお客様では SSO を導入され SSO の ID プロバイダーでの MFA を利用されるお客様も増加いたしました。直接 MFA とは関連いたしませんが Salesforce のベストプラクティスでは SSO を利用されているお客様におかれましても管理者の方については ID プロバイダーでの障害発生時に備えて直接ログインの経路を残す事が推奨されております点、ご認識置き頂き、一部のユーザーについては並行して Salesforce への直接ログイン頂く経路と MFA の設定をして頂きますとトラブル時の対応がスムーズになるかと存じます。ご参照いただければ幸いです。 ​シングルサインオンの FAQhttps://help.salesforce.com/s/articleView?id=sf.sso_tips.htm&type=5&language=ja​メモ：Salesforce システム管理者のログイン認証情報は無効にしないことをお勧めします。システム管理者は、ユーザ名とパスワードを指定して直接 Salesforce にログインできる必要があります。これは、SSO 停止などの問題に対応できるようにするためです。​学習ツール今から始める Salesforce MFA対策セミナー（MFA導入事例）https://play.vidyard.com/pNUeSkRji6hjjpwiRk2Xdq.html​実際に導入後にトラブルが発生したお客様にて、どのように対応されたかという点が事例が公開されております。ご参照下さい。MFA サポートプランの設定https://help.salesforce.com/s/articleView?id=sf.mfa_establish_support_plan.htm&type=5&language=jaMFA の運用計画を検討頂く際にご参照下さい。まとめこの記事では MFA の導入後に発生する可能性があるトラブルに対して、(特に管理者について) 2 つ以上の検証要素をあらかじめ準備頂く事が継続的なビジネスの運営に有効である旨を説明させて頂きました。また、通信障害や Salesforce で障害が発生した際に Salesforce Authenticator をお使いのお客様からよく頂戴するご質問としてプッシュ通知が来ず認証できないという点がありますが、そのような場合は Salesforce Authenticator の画面上に表示されます 6 桁のコードを入力することでログインいただける可能性がある旨、説明させて頂きました。上記の情報等を踏まえて、MFA 導入後の運用を円滑に進めて頂ければ幸いです。