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

この記事で学べることSalesforce コア製品に関する重要な技術情報バージョンアップ情報やメンテナンス情報(バージョンアップ以外)、IP アドレスフィルタリングをしている場合に必要なIPアドレス範囲に関する情報、製品廃止情報、リリース更新などの重要情報セキュリティに関する重要なアップデート​動画で更新内容を学ぶhttps://play.vidyard.com/tEN94z8S7u6GdjK3qB2sEj​全ての資料をダウンロードして学ぶダウンロードはこちら記事で更新内容を学ぶ本記事は「Salesforceの運用に関するお知らせ」の11月号となります。こちらの記事では、メンテナンス情報や技術情報、セキュリティ関連情報の構成で、特に重要な更新情報をピックアップしてご紹介いたします。必要なアクションをお客様にいち早く気づいていただくことを目的としていますので、毎月必ずご確認いただけますと幸いです。​2022年11月のトピックはこちらになります。本記事では、前月との差分である赤字の部分と、特に重要な情報をピックアップしてご紹介します。​Winter’23リリースに関する更新情報です。先日実施したWinter ’23 新機能に関するウェブセミナーの録画がサクセスナビより視聴いただけます。製品毎に再生できるようになっていますので、参加できなかったお客様も、ぜひお時間ある時にご覧ください。​関連リンクWinter '23 新機能リリース（10/16 日本時間）Winter'23プレリリース環境のサインアップサイトWinter’23 リリースノート(日本語)Salesforce Sandbox プレビュー手順リリースサイトRelease in a BoxリリースモジュールRelease Overview DeckFeature MatrixThe 360 Blogバージョンアップに備えましょうWinter '23 新機能リリース​続いて、Winter’23 リリースノートの更新情報です。10/18以降の更新内容の中から、管理者様に把握しておいていただきたい内容をピックアップしています。​/services Is No Longer Available as a Base URL for Site PagesExperience Cloudサイトをご利用のお客様にご確認いただきたい内容です。サイトページのベースURLとして"/services"の使用を制限することについてのリリースノートが追加されました。既存のサイトページは影響を受けませんが、/services を使用している既存のオブジェクトページのサブページを移動または更新するには、最初にベース URL の名前を変更する必要がありますので、ご注意ください。​Plan for Salesforce Mobile App Community License Access RetirementモバイルでSalesforceアプリケーションをご利用のお客様にご確認いただきたい内容です。Summer '23リリースで、CommunityライセンスでのSalesforce モバイルアプリケーションの利用ができなくなるアナウンスが追加されました。Summer '23以降は、Webブラウザからコミュニティにアクセスいただくことができます。​Review the New Timeline for Enhanced DomainsこちらはSalesforceをご利用のすべてのお客様向けの情報です。拡張ドメインの自動適用のスケジュールが変更になりました。こちらは後半で詳細をご説明します。​Convert Dataflows to Recipes (Generally Available)CRM Analyticsをご利用のお客様にご確認いただきたい内容です。データフローをレシピに変換する機能が一般公開された旨のアナウンスが追加されました。​Enable JsonAccess Annotation Validation for the Visualforce JavaScript Remoting API (Release Update)「Visualforce JavaScript Remoting API の JsonAccess アノテーション検証の有効化」のリリース更新の適用が、Spring '23からWinter '24に延期になりました。​Metadata API2022年11月より、認証プロバイダーのコンシューマーシークレットは暗号化されたテキストではなく、平文で入力しなければならないというリリースノートが追加されました。暗号化された値として入力された既存のコンシューマーシークレットは、Winter ‘23を通してデプロイすることができます。コンシューマーシークレットはプレースホルダー値としてエクスポートされます。​関連リンクWinter '23 リリースノート - リリースノートの変更/services Is No Longer Available as a Base URL for Site PagesPlan for Salesforce Mobile App Community License Access RetirementReview the New Timeline for Enhanced DomainsConvert Dataflows to Recipes (Generally Available)Enable JsonAccess Annotation Validation for the Visualforce JavaScript Remoting API (Release Update)Metadata API​こちらは先月と内容は変わりませんが、重要な情報のため再掲載しています。IE11のサポート終了に関するお知らせです。Microsoft社がIE11のサポートを終了したことを受けて、Salesforceも今年一杯でIE11のサポートを終了します。IE11をご利用中のお客様は、サポートされているブラウザへの移行をお願いします。​関連リンクLightning Experience でサポートされるブラウザおよびデバイスすべてのブラウザに関する推奨事項と要件Lightning Platform における IE11 サポート終了について​続いて、MFAに関する内容です。​Salesforce 多要素認証に関する FAQのナレッジの英語版が11/3に更新されています。内容は、後ほどご紹介します。また、多要素認証 (MFA) 適用ロードマップのナレッジも、英語版のみ10/28に更新されています。​関連リンクTrailblazer Community：多要素認証(MFA)コミュニティ 日本Salesforce 多要素認証に関する FAQ多要素認証（MFA）設定マニュアル ダウンロード多要素認証 (MFA) 適用ロードマップMFA特設ページ​Tableau Onlineご利用のお客様の強制適用の時期が延期されています。特権ユーザの適用予定は、2023年の3/13 - 3/17、その他のユーザの適用予定は4/17 - 4/21になっています。また、Sales CloudやService Cloud等ご利用のお客様の自動適用のスケジュールに関して、先月の記事では、リリース更新にMFAの自動適用に関する内容が表示されている場合、Spring '23に自動適用される旨をお伝えしました。ですが、Spring '23の自動適用の対象となる組織については、12月中旬にメール通知にて対象のお客様にお知らせをさせていただく運びとなりました。必ずしも、リリース更新が表示されているからと言って、Spring '23で自動適用されるわけではございませんが、メール通知を受け取られたら、早めに準備を進めていただけますよう、お願いします。なお、万が一間に合わないという場合には、こちらも早めに弊社サポートへご連絡をいただけますようお願いします。​関連リンク多要素認証 (MFA) 適用ロードマップ​続いて、Salesforce 多要素認証に関する FAQのナレッジの更新情報です。Tableau Onlineで、セキュリティキーと組み込み認証がサポートされるようになった点が更新されています。​続いて、インフラ強化に関する更新情報です。​まずはインスタンスリフレッシュについてです。インスタンスリフレッシュは、アップグレードされた新しいインフラストラクチャで構成されているインスタンスにお客様の組織を移動することで、パフォーマンスレベルを維持することを目的としています。今後の予定として、本番組織ではなく、主に日本以外のお客様のSandboxにおいて2022年12月18日にインスタンスリフレッシュが予定されています。スライドに記載されているインスタンスにてSandboxをご利用のお客様は、「インスタンスリフレッシュメンテナンス」の公開ナレッジをご確認いただき、ご準備をお願い致します。​続いてリリース更新に関する更新情報のご紹介です。​こちらの一覧は次期バージョンであるSprgin'23のリリースで有効化されるリリース更新の一部ですが、その中にある「拡張ドメイン」の有効化についてアップデートがあります。これまではSpring'23で強制適用される予定だったのですが、この予定が変更されています。詳細は後述します。​関連リンクユーザの個人情報のより強力な保護の有効化 (リリース更新)Experience Cloud サイトで Apex によって取得されるナビゲーションメニューへのユーザアクセス権限の適用 (リリース更新)コンテンツ盗聴保護を有効化 (リリース更新)拡張ドメインの有効化 (リリース更新)ICU ロケール形式の有効化 (リリース更新)​こちらは「SAML シングルサインオンフレームワークの更新」に関するリリース更新です。こちらは以前からご紹介させていただいておりますが、このリリース更新が自動適用されると、 SAMLによるシングルサインオンの動作に影響を与える可能性がございますため、Sandboxでリリース更新を有効にしていただき、動作の事前確認をお願い致します。​関連リンクSAML シングルサインオンフレームワークのアップグレード (リリース更新)サービスプロバイダとして Salesforce を使用した SAML シングルサインオンSAML ID プロバイダとしての SalesforceSalesforce 組織または Experience Cloud サイト間の SAML SSO の設定シングルログアウト​こちらでは先程ご紹介した拡張ドメインの適用時期に関する更新をご紹介します。拡張ドメインの有効化はSpring'23以降、自動有効化と強制適用を段階的に実施します。Spring'23では、全ての組織に拡張ドメインが自動有効化されますが、事前に自動有効化の対象から除外することができ、また適用後に無効化することができます。Summer'23ではこの時点で拡張ドメイン未適用の全ての組織に対して拡張ドメインが自動有効化されますが、このリリースにおいても適用後に無効化することができます。Winte'24ではこの時点で拡張ドメインが未適用である組織全てに対して強制適用が行われ、それ以降で拡張ドメインを無効化することはできません。​関連リンクEnhanced Domains Timeline拡張ドメイン拡張ドメインに関する考慮事項Salesforce ドメイン (「私のドメイン」 と拡張ドメイン) の変更に備えた準備拡張ドメインを使用する理由My Domain and Enhanced Domains Quick Reference Guideサクセスナビ - 拡張ドメインの有効化とその準備 ​こちらでは拡張ドメインの自動有効化から強制適用までのタイムラインを図に纏めています。今後予定されている自動有効化と強制適用のいずれにおいてもお客様での作業が必要となりますので、拡張ドメインの適用を計画的に進めていただければと思います。​こちらは以前にもご紹介したものですが、Spring'23のリリースが近づいてきているので再掲載しています。こちらの更新は、メールアドレスの検証を終えていないユーザがSalesforce上でメール送信処理を行った際に、メールアドレス確認を目的とした検証用メールが対象ユーザに対して送信されるというものです。Spring’23のリリース以降、未検証のメールアドレスからのメール送信はできなくなる予定ですのでご注意ください。関連リンクWinter'23 リリースノート Salesforce からメールを送信するためのメールアドレスの検証Spring '22 「 Salesforce メール確認 」という件名の認証メールについて​最後に機能廃止に関する更新情報です。​まずはField Service のモバイルアプリケーション バージョン226の廃止です。2023年2月1日以降、iOS および Android のバージョン 226 以下の Field Service モバイルアプリケーションにてログインができなくなりますのでバージョンアップの計画をお願いします。​次はWork.com WorkSpace Command Center です。こちらは契約期間が終了すると、サービスにアクセスできなくなります。​最後に「Salesforce Platform APIバージョン 21.0~30.0 の廃止について」です。こちらは以前からご紹介している内容ですが、影響度の大きい更新の一つですので改めてご紹介させていただきます。API バージョン21.0から30.0は既にサポート終了となっておりましたが、今後は来年2023年6月をもちまして利用不可となることを予定しております。本件に関して、11月14日に製品コミュニケーションメールが送信されており、また機能廃止に関するダイジェストもメールで送信されていますので、そちらも併せてご確認いただき、早めのご対応をご検討ください。​関連リンクSalesforce Platform API バージョン 21.0 ～ 30.0 の廃止Salesforce Event Log File BrowserEventLogFile オブジェクトの API Total Usageイベント種別​11月度分の更新情報は以上となります。最後までご覧いただき、ありがとうございました。​​​​​​​

連載：『営業改革のコンパス～規模に応じたトランスフォーメーションの最適設計～』vol.13

Vol. 10 、Vol. 11、Vol. 12に続いて、上記の図「営業改革プロジェクトの標準的なプロセス」からステップ6 KPI、データ分析と活用以降を解説していきます。ステップ6 KPI、データ分析と活用データが蓄積されてくると、分析とその結果を踏まえたアドバイスが可能になります。この時点で、目的や改革方針に沿って決めたKPIの評価や見直しを行いながら、PDCAサイクルを回していきます。​この段階で見直しが必要なことがわかれば、ステップ3 に戻り、修正してITに適用し、再度トレーニングを行います。​実際、初期はスピード重視でSFAの標準機能に合わせて営業プロセスを作成したものの、現場で使っていくうちにより実態に合ったプロセスを作り上げ、画面を追加でデザインし、開発・実装した企業もありました。逆に、最初に入力項目を作り過ぎたため、運用が回らず大幅に項目を見直すことを行った企業もありました。​いずれにしても営業改革は最初から正解が分かっている改革ではありません。よって、半年から1年のサイクルで、ステップ3「方針決定、ビジョンやゴールの設定、価値観のすり合わせ」から、ステップ6「KPI、データ分析と活用」を繰り返すことで、より改革は効果を発揮し結果へと結びついていきます。​また、営業活動プロジェクトでよく行われるのが、優秀な営業担当者のノウハウを形式知化し、全社に展開して底上げを図ろうとする試みです。顧客訪問の回数や頻度、訪問する相手、活動ステージ、見積提示のタイミング、取得する情報、事務確認、目的達成度合いなど、あらゆる観点から活動を分析し、成績上位者と他の営業担当者を比較し、違いを見ていくと、最も営業成績に直結する要素が明らかになります。​このような分析とナレッジの標準化や展開は、営業戦略部門や営業支援部門の役割と考えます。客観的な視点で営業活動の特徴をつかみ、製品特性や地域特性などに合わせてカスタマイズし、すべての営業担当者が実践できるように標準化していきます。​こうした営業担当者の行動分析、売上予測などは、システムを入れたからといって、一夜にして可能になるわけではありません。どの順番で何をすべきか、それによって何ができるかを理解し、段階的に積み上げていくことが大切です。​ステップ7 定着化と展開改革を進めていくには、小さな成功が必要です。それをきっかけに、現場担当者や経営者、プロジェクト・チームの間で一気に活動に盛り上がることもあります。​新しいプロセスややり方で上手く回り始めると、営業生産性の向上、機会損失の抑制、情報共有スピードの向上、部門間の連携促進、会議の質の向上といったメリットが見られるようになります。ただし、それが現場レベルまで定着するまでには、長い時間がかかります。成功事例を見ても、営業の動き方が変わり、効果を実感するには１年以上かかるプロジェクトも珍しくありません。粘り強く取り組んでいくことが大切です。​その間、プロジェクト・チームは辛抱の時間を過ごします。しつこく、熱く、丁寧に営業現場と向き合ってください。プロジェクトに対して反応がよくわからない営業担当者もたくさんいると思いますが、実は「様子見」をしているのです。​「真似しやすい」例をあげ、「勝ち馬」に乗りやすい環境を整えてください。小さな成功が出たら、ぜひ積極的に社内広報活動を行っていただければと思います。社内報、営業会議、全社会議など誰もが見るところで表彰、共有を行うことで「あれは勝ち馬だ」と営業担当者は理解します。その結果、現場への浸透がますます進み、当初のプロジェクト目的が達成されるのです。誰もが「勝ち馬」に乗りたいのです。ただ、それが勝ち馬かどうかわからないと大きく踏み込めません。積極的にプロジェクト・オーナーの協力を仰ぎ、どのような使い方が良い使い方かを広めましょう。​新しいプロセスや行動様式が定着し、必要なデータが蓄積され活用可能になることで、新たな発想ができるようになります。海外展開、サポート部門との連携強化、インサイドセールスの導入、営業とマーケティングの連動など、次なる展開に移れるのです。これについては多くの事例が存在しますし、セールスフォース・ドットコムも実践しています。ぜひ社員に聞いてみていただければと思います。​​​著者：田崎純一郎（たさき じゅんいちろう）セールスフォース・ドットコムセールスイネーブルメントシニアディレクター​————————————————完全版eBookをダウンロード提供中本連載『営業改革のコンパス～規模に応じたトランスフォーメーションの最適設計～』第3章（Vol. 10〜13の記事）は、完全版のeBookにまとめています。ぜひ、下記からダウンロードしてお読みください。​【 第3章 ダウンロードはこちら 】​Vol. 6～9の記事は第2章の内容になります。第2章のeBookにて完全版を公開しております。ぜひ、下記からダウンロードしてお読みください。​【 第2章 ダウンロードはこちら 】​​Vol. 1〜5の記事は第1章の内容になります。eBookにて完全版を公開しております。ぜひ、下記からダウンロードしてお読みください。​【 第1章 ダウンロードはこちら 】​連載記事＜第1章＞Vol. 1 営業改革で解決したい課題は何か - 営業組織の規模と営業改革テーマVol. 2 営業マネジメント50人の壁 ― 営業支援システムの導入率からみる営業組織の課題Vol. 3 営業組織の規模によって異なる課題感 ― データの収集と活用Vol. 4 現場が見えなくなる中規模組織Vol. 5 使いこなせていない51名以上の営業組織は「営業案件の可視化やパイプライン管理ができていない」​＜第2章＞Vol. 6 営業活動は不完全情報ゲームVol. 7 営業を“群衆”ではなく“組織”に -情報を使って160時間の使い方を最適化Vol. 8 営業情報は製品中心ではなく「顧客データを中心」にフロントとバックをつなげるVol. 9 作ったものを売る営業から、売れるものを作る会社へ​＜第3章＞Vol. 10 営業改革プロジェクトでは、どんな困難に直面するのか？Vol. 11 チームの結成・メンバーの選定 ～ 方針決定、ビジョンやゴールの設定、価値観のすり合わせVol. 12 情報プラットフォーム（ITシステム）選定 ～ 組織変更の実施、教育・社内トレーニング​​＜関連セミナーご案内＞Salesforceでは、営業改革をサポートするウェブセミナーをご用意しています。あらゆる企業規模・業界において営業マネージャーの方々がどのようにSalesforceを活用すべきかをご紹介します。ぜひご活用ください。https://successjp.salesforce.com/article/NAI-000042

連載：『営業改革のコンパス～規模に応じたトランスフォーメーションの最適設計～』vol.9

作ったものを売る営業から、売れるものを作る会社へ例えば、Eコマースの世界では、顧客が一度は気に入ってクリックし買い物カゴに入れたものの、最終的な購入までいかなかったものがわかります。メールなどで買い忘れはないか連絡したり、価格が変更されたことを通知して再度購買を促し、それでも購入に至らなければ、どの商品と比較されたのか分析し製品の改善につなげています。​同様に、最近では実店舗でも人工知能（AI）の画像解析により、顧客が手に取ったけれども購入に至らなかった商品がわかるようになってきました。もちろん無人店舗や万引き防止にも役立つのですが、それによって陳列の改善や顧客がなぜ買わなかったかを深く分析する取り組みが始まっています。​また、みなさんよくご存知のアパレル産業では、ファーストリテイリングやザラなどの製造小売り（SPA）と呼ばれる業態の企業が飛躍的な成長を遂げ、農業では生産（1次）、加工（2次）、流通販売（3次）をすべて手掛ける6次産業化が起こっています。これまでの「作る企業」と「売る企業」という役割分担ではなく、「作って売る」。​そして、顧客の反応をすぐに製品やサービスに反映する。顧客の必要なものを必要なだけ作れば、利益を削ってまで安売りする必要はありません。これらの動きは顧客中心の考え方への大きなシフトの一環であり、実践している企業はすでに存在しているのです。​世界の先進企業はいま、顧客接点を担うフロント業務をカスタマー・リレーションシップ・マネジメント（CRM）を中心に改革し、バックエンド業務（支援業務）との連携を図ろうと懸命に取り組んでいます。ネット店舗も独立した存在ではなく、リアル店舗と在庫情報を共有し、どちらからでもシームレスに手に入れられる環境を整備しています。BtoBの世界も顧客中心の考え方で収集・管理した情報を活用しながら、フロントとバックエンドを連携させることが、営業改革で取り組むべきシステムの主要テーマなのです。​次回からは「営業改革のプロジェクトの進め方」について具体的に解説していきます。公開は11/4（木）を予定しております。​​著者：田崎純一郎（たさき じゅんいちろう）セールスフォース・ドットコムセールスイネーブルメントシニアディレクター​————————————————完全版eBookをダウンロード提供中本連載『営業改革のコンパス～規模に応じたトランスフォーメーションの最適設計～』第3章（Vol. 10〜13の記事）は、完全版のeBookにまとめています。ぜひ、下記からダウンロードしてお読みください。【 第3章 ダウンロードはこちら 】​Vol. 6～9の記事は第2章の内容になります。第2章のeBookにて完全版を公開しております。ぜひ、下記からダウンロードしてお読みください。【 第2章 ダウンロードはこちら 】​​Vol. 1〜5の記事は第1章の内容になります。eBookにて完全版を公開しております。ぜひ、下記からダウンロードしてお読みください。【 第1章 ダウンロードはこちら 】​連載記事＜第1章＞Vol. 1 営業改革で解決したい課題は何か - 営業組織の規模と営業改革テーマVol. 2 営業マネジメント50人の壁 ― 営業支援システムの導入率からみる営業組織の課題Vol. 3 営業組織の規模によって異なる課題感 ― データの収集と活用Vol. 4 現場が見えなくなる中規模組織Vol. 5 使いこなせていない51名以上の営業組織は「営業案件の可視化やパイプライン管理ができていない」​＜第2章＞Vol. 6 営業活動は不完全情報ゲームVol. 7 営業を“群衆”ではなく“組織”に -情報を使って160時間の使い方を最適化Vol. 8 営業情報は製品中心ではなく「顧客データを中心」にフロントとバックをつなげる​＜第3章＞Vol. 10 営業改革プロジェクトでは、どんな困難に直面するのか？Vol. 11 チームの結成・メンバーの選定 ～ 方針決定、ビジョンやゴールの設定、価値観のすり合わせVol. 12 情報プラットフォーム（ITシステム）選定 ～ 組織変更の実施、教育・社内トレーニングVol. 13 KPI、データ分析と活用 ～ 定着化と展開​​＜関連セミナーご案内＞Salesforceでは、営業改革をサポートするウェブセミナーをご用意しています。あらゆる企業規模・業界において営業マネージャーの方々がどのようにSalesforceを活用すべきかをご紹介します。ぜひご活用ください。https://successjp.salesforce.com/article/NAI-000042

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

この記事で学べることSalesforce コア製品に関する重要な技術情報バージョンアップ情報やメンテナンス情報(バージョンアップ以外)、IP アドレスフィルタリングをしている場合に必要なIPアドレス範囲に関する情報、製品廃止情報、リリース更新などの重要情報セキュリティに関する重要なアップデート​動画で更新内容を学ぶhttps://play.vidyard.com/TGeXbhV1YTFFpio7J5rXSC​全ての資料をダウンロードして学ぶダウンロードはこちら記事で更新内容を学ぶ本記事は「Salesforceの運用に関する重要なお知らせ」の10月号となります。こちらの記事では、メンテナンス情報や技術情報、セキュリティ関連情報の構成で、特に重要な更新情報をピックアップしてご紹介いたします。必要なアクションをお客様にいち早く気づいていただくことを目的としていますので、毎月必ずご確認いただけますと幸いです。​2022年10月のトピックはこちらになります。本記事では、前月との差分である赤字の部分と、特に重要な情報をピックアップしてご紹介します。​Winter ‘23のバージョンアップが、10/16に実施されました。新機能に関するウェブセミナーが、11/8~11にスケジュールされています。新機能ウェブセミナーの申し込みページへのリンクより、お申し込みができるようになっていますので、奮ってご参加ください。​関連リンクWinter'23プレリリース環境のサインアップサイトWinter’23 リリースノート(日本語)Salesforce Sandbox プレビュー手順リリースサイトRelease in a BoxリリースモジュールRelease Overview DeckFeature MatrixThe 360 Blogバージョンアップに備えましょうWinter '23 新機能リリース​続いて、Winter '23リリースノートの更新情報についてです。9月分と10月分の更新の中で、重要なものをピックアップしています。​Spring '23 での一部のユーザの MFA の自動有効化 (リリース更新)先月の「Salesforceの運用に関する重要なお知らせ」では、ユーザ数が100名未満の組織において、Winter '23のリリース更新画面にMFAの自動有効化が表示される予定である旨お伝えしました。今回の変更点は、100名未満の条件は使用しなくなった旨が追記されています。そのため、100名以上のユーザ数がいる組織の管理者様も、必ずリリース更新画面をご確認いただけますよう、お願いします。リリース更新にMFAの自動有効化が表示されていたら、Spring '23に自動有効化が行われる予定なので、その前にSalesforceに直接ログインするユーザ様に対するMFAの設定が完了していることをご確認お願いします。​Review Hourly Send Limits for Single Emailsメールコンポーザー（＝メールアクション）を使って、外部へメール送信をする場合の、時間毎の新たな制限がついかされたという内容です。今まで、Salesforceの画面から、手動で送信するメールについては、特に制限はありませんでしたが、2022年9月22日以降に新規作成された組織については、1時間毎に250件までという制限ができました。なお、既存の日次送信制限（5000件）は変わりません。​My Domain Login Page Was Changed[私のドメインの画面に、認証プロバイダーや証明書を使用してログインができるような設定をしている場合に、ログイン ページの表記に変更が加わったという内容になります。変更前後の画面は、リリースノートでご確認いただけます。​より大量の予測をさらにすばやく保存をするというCRMAの機能の正式リリース大規模な予測の書き戻しが有効になっている時の、デフォルトの制限に関する情報が更新されました。今まで200万だったものが500万に変更されました。​Chatter Free and Chatter External Users Are Automatically Excluded from MFA Auto-Enablement and Enforcement皆様ご存知の通り、Chattr FreeやChatter Extrnal UserはMFAの対象外です。そのため、MFAの自動有効化や強制適用の対象にはならない旨が追加されました。​関連リンクSpring '23 での一部のユーザの MFA の自動有効化 (リリース更新)Review Hourly Send Limits for Single EmailsMy Domain Login Page Was Changedより大量の予測をさらにすばやく保存 (正式リリース)Chatter Free and Chatter External Users Are Automatically Excluded from MFA Auto-Enablement and Enforcement次は、IE11のサポート終了に関するお知らせです。こちらはこれまでのご案内と変更はありませんが、重要な内容なので再掲載しています。Microsoft社がIE11のサポートを終了したことを受けて、Salesforceも今年一杯でIE11のサポートを終了します。IE11をご利用中のお客様は、サポートされているブラウザへの移行をお願いします。​関連リンクLightning Experience でサポートされるブラウザおよびデバイスすべてのブラウザに関する推奨事項と要件Lightning Platform における IE11 サポート終了について​続いてはLightning Syncに関する情報です。こちらも新たな情報はありませんが、重要な内容のため再掲載となります。Microsoft社は2022年10月から、Exchange Onlineの基本認証の廃止をアナウンスしています。そのため、Lightning Syncの接続方法として、サービスアカウントを使用している場合には、今月中に接続方法の移行が必要です。対応方法など詳細につきましては、関連リンクをご確認ください。​関連リンクReview Microsoft Announcements on Basic Authentication Retirement for Exchange OnlineMicrosoft Office 365 での Lightning Sync サービスアカウント接続方法について​そして、MFA関連のリソースの更新情報です。Salesforce 多要素認証に関する FAQ のナレッジが、英語版のみ10/7に更新されています。また、多要素認証 (MFA) 適用ロードマップ のナレッジが、英語版のみ9/28に更新されています。​関連リンクTrailblazer Community：多要素認証(MFA)コミュニティ 日本Salesforce 多要素認証に関する FAQ多要素認証（MFA）設定マニュアル ダウンロード多要素認証 (MFA) 適用ロードマップMFA特設ページ​ロードマップの具体的な変更点は、Marketing CloudのInteligence（Datrama）の強制適用が10/6に実施されました。​関連リンク多要素認証 (MFA) 適用ロードマップ​MFAのナレッジの変更点は、以下5点です。​#1：ナレッジに、自動有効化と強制適用についての説明のセクションが追加されました#2：U2Fセキュリティキーに関するセクションが削除されました#3：リカバリーコードを主要な検証方法として使用すべきではない旨が追記されてます​以下は、パートナー様向けの情報です。#4：パートナーがお客様のユーザアカウントを使用する場合の MFA の取り扱いについて追記されてます#5：1 つのユーザアカウントを複数のパートナーが使用する場合のガイダンスが追記されました。詳細は関連リンクに纏められておりますので、パートナーの皆様はご確認お願いします。​関連リンクHow to Satisfy the MFA Requirement for the Partner Admin Shared Login Use Case​続いてはインフラ強化に関する情報です。最初にインスタンスリフレッシュについてです。​インスタンスリフレッシュは、アップグレードされたインフラストラクチャで構成されているインスタンスにお客様の組織を移動することで、パフォーマンスレベルを維持することを目的としています。今後の予定として、本番組織ではなく、（主に日本以外のお客様の）Sandboxにおいて2022年11月6日と12月18日にインスタンスリフレッシュが予定されています。上記スライドに記載されているインスタンスにてSandboxをご利用のお客様は、関連リンクをご確認いただき、ご準備をお願い致します。​関連リンクインスタンスリフレッシュメンテナンス続いて、「Salesforce アプリケーションからのメールを受信できるようにする」のナレッジに更新がありました。ARINで使用されているIPアドレス範囲に新しい範囲が追加されていますので、Salesforce 組織からのメール受信をIPアドレスでフィルタされているお客様はナレッジをご確認ください。また翻訳版ナレッジの更新が完了していないため、詳細につきましては英語版のナレッジをご確認ください。​関連リンク許可すべき Salesforce の IP アドレスとドメインHyperforce 上の Salesforce サービスへの中断しないアクセスを維持するSalesforce アプリケーションからのメールを受信できるようにする​続いて今後自動適用が予定されているリリース更新をご紹介します。Spring'23で自動適用されるリリース更新は、現時点で13個が予定されています。​関連リンクユーザの個人情報のより強力な保護の有効化Experience Cloud サイトで Apex によって取得されるナビゲーションメニューへのユーザアクセス権限の適用コンテンツ盗聴保護を有効化拡張ドメインの有効化ICU ロケール形式の有効化​​リリース更新の中には、お客様組織おけるログインの動作や使用されるURLについて変更が行われる更新、またお客様のカスタマイズについても動作に変更が加わる可能性がある更新がございます。そのため、事前にお客様組織における影響を確認するためにも、リリース更新の内容をご確認いただき、Sandboxにて動作確認/テストを実施いただくことを推奨しております。今回はこれらのリリース更新のなかで、特にご認識いただきたい更新を２つご紹介します。​関連リンクVisualforce JavaScript Remoting API の JsonAccess アノテーション検証の有効化Visualforce ページのクロスサイトスクリプティングを防止するための <apex:inputField> 要素の label 属性のエスケープSpring '23 での一部のユーザの MFA の自動有効化メンテナンス計画の頻度の項目からメンテナンス作業ルールへの移行Experience Cloud ゲストユーザには詳細なフロー権限が必要SAML シングルサインオンフレームワークのアップグレードケースメール通知のシステムアドレスとしてデフォルトの No-Reply アドレスを使用ユーザコンテキストでの REST API を介したフローの実行​1つ目は「SAML シングルサインオンフレームワークの更新」です。こちらは以前にもご紹介いたしましたが、このリリース更新が自動適用されると、 SAMLによるシングルサインオンの動作に影響を与える可能性がございますため、Sandboxでリリース更新を有効にしていただき、動作の事前確認をお願い致します。​関連リンクSAML シングルサインオンフレームワークのアップグレード (リリース更新)サービスプロバイダとして Salesforce を使用した SAML シングルサインオンSAML ID プロバイダとしての SalesforceSalesforce 組織または Experience Cloud サイト間の SAML SSO の設定シングルログアウト​2つ目は拡張ドメインです。こちらも以前からご紹介しておりますが、最新のブラウザ要件に準拠することを目的として、Salesforce 組織のドメイン形式を更新します。Experience Cloud のような外部公開しているURLを含む複数のURLが更新されるため、Sandbox で拡張ドメインを有効化することによる事前確認を推奨しており、併せて自動適用前に本番環境へ適用することも推奨しております。影響度の高い更新となりますため必ずご確認いただけますと幸いです。​関連リンクSalesforce ドメイン (「私のドメイン」 と拡張ドメイン) の変更に備えた準備拡張ドメインを使用する理由My Domain and Enhanced Domains Quick Reference Guide拡張ドメインの有効化とその準備 拡張ドメインの有効化​続いて、機能の廃止についてです。まずは、Marketing Cloudに関するもので、Thunderhead が組み込まれた従来版の Interaction Studio 製品の廃止です。こちらは2023 年 3 月 1 日に廃止が予定されています。​関連リンクMC Interaction Studio Thunderhead Retirement続いて、「Salesforce Maps ライブ追跡のサードパーティインテグレーション」です。こちらは機能の契約期間によって廃止日が変わりますのでご確認ください。​関連リンクSalesforce Maps ライブ追跡のサードパーティインテグレーションの廃止について​新たな情報ではございませんが、赤枠に記載の Salesforce Platform APIバージョン 21.0~30.0 の廃止について、影響度の大きい更新の一つですので改めてご紹介させていただきます。​API バージョン21.0~30.0は、既にSummer’22 でサポート終了となっておりましたが、今後は来年2023年6月をもちまして利用不可とすることを予定しております。お客様の利用状況や開発内容によっては、対応に時間がかかる場合もございますので早めの対応を推奨しております。確認方法や対応方法につきまして、ナレッジなどのコンテンツをご用意しておりますのでご確認ください。​関連リンクSalesforce Platform API バージョン 21.0 ～ 30.0 の廃止Salesforce Event Log File BrowserEventLogFile オブジェクトの API Total Usageイベント種別​10月度分の更新情報は以上となります。最後までご覧いただき、ありがとうございました。​

ファーストパーティクッキーとサードパーティクッキーについて

この記事で学べることファーストパーティクッキーとサードパーティクッキーの違いを理解するファーストパーティトラッキング機能とその考慮事項を理解するはじめにAccount Engagementでは、WEBサイトにトラッキングコードを設置することで、WEBサイトを訪問されたことをトラッキングすることが可能です。​このトラッキングの記録には、ユーザーが利用するブラウザー上に保持されるクッキー情報が利用されます。​トラッキング用のクッキーにはファーストパーティーとサードパーティーの2種類ありますが、近年ChromeやFirefoxなどブラウザ提供各社によるプライバシー対策強化によって、サードパーティクッキーに対する規制が強化される流れがあり、Webマーケティングを行う側も対応が求められています。​そこで本記事では、ファーストパーティクッキーとサードパーティクッキーの違い、Account Engagementにおけるそれらの扱い方について解説します。クッキー（Cookie）とはクッキーとは、WEBサイトへアクセスを行った際に一時的なデータを記録する仕組みです。​クッキーは大きく分けて2種類あり、それぞれ「ファーストパーティクッキー（1st Party Cookie）」「サードパーティクッキー（3rd Party Cookie）」と呼ばれています。ファーストパーティクッキーとはファーストパーティクッキーとは、ユーザーが実際に訪問したWEBサイトのドメインから発行されるクッキーであり、ユーザーやブラウザーからブロックされる可能性は低くなっています。​たとえば、WEBサイトのドメインが「aaa.com」の場合、「aaa.com」から発行されるクッキーがファーストパーティクッキーとなります。​ファーストパーティクッキーは、実際に訪問しているサイトのドメインから発行されるため、ユーザーやブラウザーからクッキーの利用がブロックされる可能性は低くなります。サードパーティクッキーとは一方、サードパーティクッキーとは、ユーザーが実際に訪問していないドメインから発行されるクッキーです。​たとえば、WEBサイトのドメインが「aaa.com」の場合、Webサイト上に設置された広告媒体などを経由して「zzz.net」というドメインで発行されるのが、サードパーティクッキーとなります。​このように、ドメインを横断したユーザの行動履歴を保持するため、マーケティング分野ではリターゲティング広告などで広くサードパーティクッキーが利用されています。ファーストパーティトラッキング機能についてAccount Engagementでは、従来よりファーストパーティクッキーとサードパーティクッキーを併用してトラッキングを行ってきました。​しかし近年は、プライバシー保護の観点によりブラウザー側の規制などが進み、サードパーティクッキーの利用が制限される場面が多くなっています。​そこで、Account Engagementでも任意のドメインでファーストパーティクッキーによるトラッキングを可能とする機能が提供されました。​ファーストパーティクッキーによるトラッキングを行うことで、WEBサイト上のアクティビティをより確実に追跡し、アクティブな見込み客の発掘・育成に活用しましょう。設定方法ファーストパーティトラッキング機能を有効化する方法、トラッキングコードの実装方法については、初期設定ガイドにて詳細な手順をご確認ください。ファーストパーティトラッキング機能に関する考慮事項2023 年 2 月 13 日以降にAccount Engagementのアカウントを作成された場合、デフォルトでファーストパーティトラッキング機能が有効になっています。WEBサイトのルートドメインとトラッカードメインのルートドメインが一致している場合に限り、ファーストパーティクッキーによるトラッキングが可能になります。ファーストパーティクッキーのトラッキングが可能なパターンWEBサイトのドメイン： aaa.com （ルートドメイン aaa.com ）トラッカードメイン： go.aaa.com （ルートドメイン aaa.com ）ファーストパーティクッキーのトラッキングが不可のパターンWEBサイトのドメイン： aaa.com （ルートドメイン aaa.com ）トラッカードメイン： go.bbb.com （ルートドメイン bbb.com ）ファーストパーティトラッキング機能を有効にした場合でも、サードパーティクッキーを併用することは可能です。ドメインを横断したトラッキングを目的とし、サードパーティクッキーを併用されたい場合は、ファーストパーティトラッキング機能有効化の際に下記2つのオプションのチェックを有効にします。サードパーティクッキーをファーストパーティトラッキングと併用サードパーティトラッキングを使用学習ツールヘルプ：クッキーとアクティビティトラッキングヘルプ：ファーストパーティトラッキングへのアップグレードヘルプ：ファーストパーティトラッキングに関する考慮事項サクセスナビ：初期設定を完了しましょうサクセスナビ：アクティブ化を理解しましょうまとめ本記事では、クッキーの種類やAccount Engagementにおけるファーストパーティトラッキング機能について解説しました。運用方法や他社事例などについてご質問がございましたら、 Account Engagement(旧Pardot) 日本 グループまたは質問広場～初心者から上級者まで～ 日本 グループにてご質問ください。個別の技術的なご質問がございましたら、ヘルプ & トレーニングより弊社サポートへお問合せください

メール内トラッキングリンクとフォームの事前入力の仕組みについて

この記事で学べることマーケティングメールのリンククリックトラッキングの仕組みを知るフォームの事前入力機能について知る意図せぬトラッキングを防ぐ方法を知るはじめにAccount Engagement から送信するメールには、宛先のプロスペクトの開封やメール内のリンククリックをアクティビティとして検知する仕組みがあります。​この機能によって、メールの開封やリンクのクリックを起点として、自動で追客メールを送信したり、営業にアプローチを促す通知を送信したり、さまざまなマーケティングオートメーション機能を実行させることができます。​さらに、Account Engagement のフォームには、プロスペクトがメールリンクからフォームを開いた際にプロスペクト情報を項目に値として予め呼び出す機能があり、この機能により入力の手間を省き、コンバージョン率の向上に繋げることができます。​この様に便利な機能である一方で、安全、効果的に活用するためには、その仕組みを理解する必要があります。​本記事では、Account Engagement におけるメールのリンククリックのトラッキングと、フォーム項目の事前入力の機能、またその考慮事項について解説します。メールのリンククリックトラッキングの仕組みAccount Engagement では、メールを送信する際、メール作成時に記載された URL を、宛先のプロスペクト固有のトラッキングリンクに書き換えて送信します。​例えば、メール内の URL をトラッキングリンクに変換するか否かを制御する一つの方法として、URL の頭に http:// や https:// のプロトコルを記載する・しない、があります。​プロトコルを記載した場合、受信したメール内のリンクは、以下の様にトラッキングリンクに変換されますが、クリックすると実際のページが表示されます。​トラッキングリンクは各プロスペクトに対して一意で発行され、プロスペクトがリンクをクリックすると、プロスペクトには実際のページを表示させ、Account Engagement では「プロスペクト◯◯がこのリンクをクリックした」ということをアクティビティとして検知します。​こちらが実際のプロスペクトレコードのアクティビティとして記録された様子です。この機能を利用して、例えばリストメールを送信する際の完了アクション設定で、リンクがクリックされた際に、追客メールを自動で送信したり、営業に対して Salesforce の ToDo を発行してアプローチを促すなど、自動の後処理を実行することができます。​メール内のトラッキングリンクは、プロスペクトごとに固有の識別子を付与しており、リンクがクリックされるとプロスペクトが使用しているブラウザにトラッキング用の Cookie を払い出します。​これにより、以降そのブラウザで Account Engagement フォームを開くと、プロスペクトの情報が呼び出され、入力済みのフォーム項目は値が事前入力されたかたちで表示されます。プロスペクトも入力の手間が省け、よりフォームを送信しやすくなり、コンバージョン率の向上に繋がります。​この様に便利である一方でいくつか考慮が必要な点があります。考慮事項メール内のトラッキングリンクは、プロスペクトに対して一意のものです。また、トラッキング用の Cookie はあくまでブラウザに対して付与されるもであり、人物を識別するものではありません。​つまり、あるプロスペクトに送信されたメール内のリンクが、メール転送や直接の共有によって他人に共有され、他人のブラウザでリンクをクリックした場合、以下の事象につながります。​他人がクリックしたことが、プロスペクトのアクティビティとして記録される他人のブラウザでフォームを表示すると、プロスペクトの項目値が事前入力されて表示される​メール内のトラッキングリンクが共有されることを完全に防ぐことは難しいですが、以下の様な対策方法が考えられます。（画像はクリックで拡大表示できます）それぞれの内容について、詳細は以下ナレッジに記載されています。メールリンクのトラッキングAccount Engagement でメールリンクが書き直されるフォームに他人の情報が入力されているのはなぜですか？フォームのトラブルシューティングと FAQ学習ツールTrailhead : Pardot Lightning アプリケーションを使用したエンゲージメントの向上とリードの育成サクセスナビ : メールを配信しましょうまとめ本記事では、Account Engagement におけるメールトラッキングとフォームの事前入力機能について解説しました。​運用方法や他社事例などについてご質問がございましたら、 Account Engagement(旧Pardot) 日本 グループまたは質問広場～初心者から上級者まで～ 日本 グループにてご質問いただけます。個別の技術的なご質問がございましたら、ヘルプ & トレーニングより弊社サポートへお問合せください。

Data Cloud セグメントを基に Account Engagement ダイナミックリストを作成する

この記事で学べることAccount Engagement と Data Cloud を連携する方法Data Cloud セグメントを基に Account Engagement ダイナミックリストを作成する方法はじめに本記事では、Summer ’23 リリースで追加された、Data Cloud セグメントを基に Account Engagement ダイナミックリストを作成する方法についてご紹介します。​AWS S3 や Google Cloud Storage などの外部ストレージや取り込み API、B2C Commerce などあらゆる外部データソースから取り込んだ顧客やエンゲージメントデータを基に作成した Data Cloud セグメントを利用することで、Salesforce や Account Engagement のデータを超えた条件でダイナミックリストを作成できるようになります。​Data Cloud を併用するメリットには以下の様なものがあります。​販売管理や EC のデータなど外部から Data Cloud へ取り込んだ顧客関連データを検索条件に利用できるData Cloud の計算済みインサイト機能を併用し、「◯◯製品を 3 回購入した」など柔軟な集計条件を利用できる検索条件に使用するオブジェクトを、起点のオブジェクトを含めて最大 5 階層まで辿れる*最大 7,500 個のオブジェクトを基にセグメントの検索条件を定義できる** 参考情報【Data Cloud の制限とガイドライン】​上記のメリットにより、さらに柔軟なターゲティングができるようになります。​イメージ図 (画像のダブルクリックで拡大可)前提当機能を利用するためには、Data Cloud の有償契約、または、Enterprise Edition 以上にて提供される無償の Data Cloud Provisioning の有効化が必要です。また、Data Cloud セグメントを利用するには、別途有償のセグメンテーションと有効化機能オプションが必要です。​また、Data Cloud での請求は処理するデータ数・量など使用量に応じて計算されます。(旧 Customer Data Platform にご契約の場合はこちらの請求方法となります)​【Data Cloud の請求可能な利用状況の種別】​重要：セグメンテーションと有効化オプションの購入方法や使用量の確認・請求方法などについての詳細は、契約書を参照いただくか、弊社営業担当者にお問い合わせください。設定方法1. 組織で Data Cloud を有効化する現在 Data Cloud を契約していない Enterprise Edition 以上の Salesforce 組織においては、組織の Your Account 機能経由で無償版 Data Cloud Provisioning にサインアップできます。​Data Cloud の初期設定は多岐のステップに渡りますが、有効化から初期設定まで一連の設定はクイックスタートガイドが参考になります。​下記では、クイックスタートガイドをベースに、Account Engatement 連携で必要な追加設定を補足しながら解説します。​まずは Salesforce 組織設定の [Data Cloud] メニューより、[Data Cloud の設定と接続] の章まで設定します。​【Data Cloud クイックスタートガイド】​2. Data Cloud のデータストリームを設定するData Cloud では、データストリームレコードを介して各種ソースから取り込んだデータを、データレイクオブジェクト (以降 DLO と表記) に格納します。​そこから、データモデルオブジェクト (以降 DMO と表記) という Data Cloud 内で構造的に統一されたオブジェクトにまとめる (正規化) ことで、多様なソースから取り込んだデータを基にセグメント作成に利用できるようになります (参考)​＊詳細については、トレイル【Trailhead : Data Cloud の詳細を知る】の Data Cloud での取得とモデリング モジュールを参照​【Data Cloud クイックスタートガイド】の [Data Cloud の設定と接続] セクションの設定を進める[追加設定] 途中、ヘルプ 【権限セットとプロファイルでの項目権限の設定】の手順を参考に、Data Cloud Salesforce Connector 権限セットに対して、リードおよび取引先責任者オブジェクトの各種 Account Engagement 関連項目 (項目名 「Account Engagement ~」) および、その他 Data Cloud へ同期したいオブジェクトや項目に対して参照権限を付与【Data Cloud クイックスタートガイド】に戻り、 [データの取り込みと対応づけ] セクションで、Sales Cloud バンドルでデータストリームを作成注意：この際、取り込む対象項目に各種 Account Engagement 関連項目 (項目名 「Account Engagement ~」) を含める[追加設定] Sales Cloud バンドルでリードおよび取引先責任者のデータストリームが追加されたら、【Account Engagement から Data Cloud へのプロスペクトデータのインポート】の [データモデルオブジェクトへの Account Engagement データのマッピング] の手順に従い、それぞれの DLO <=> DMO のマッピングを設定注意：マッピング設定にて、Individual DMO の鉛筆アイコンより [Account Engagement Integration ID] モデル項目を作成し、リード (取引先責任者) ID 項目をマッピングContact Point Phone DMO の [Formatted E164 Phone Number] 項目には、リードや取引先責任者の電話番号を紐付け​リード DSO の [Account Engagement Integration ID] モデル項目のマッピング例​要件に応じて、セグメントの検索条件で利用する、その他データソースを Data Cloud へ接続します。​利用可能なデータソースは多岐に渡りますが、代表的な AWS S3 を題材にデータ取り込みの基本操作を解説した弊社サポートの Youtube 動画をご覧ください。​【【Salesforce サポート】Data Cloud | はじめてのデータストリーム設定手順 〜AmazonS3からのデータ取り込み編〜】​3. ID 解決で重複レコードを統合するData Cloud は多種多様なデータソースから顧客データを取り込むことができますが、それにより重複レコードも取り込まれる可能性があります。​余計なデータを取り込まないようにデータソース側 (本件では Salesforce) であらかじめ不要なレコードを整理することが推奨されますが、Data Cloud 内でも一致ルールを定義することで取り込んだ重複した顧客レコードを一つの統合個人 (Unified Individual) に統合することが可能です。​まずは [ID 解決] タブの新規作成画面で [プライマリデータモデルオブジェクト] で「Individual」を選択します (ルールセット ID は省略可)。​次に [一致ルール] を定義します。​[プライマリデータモデルオブジェクト] で「Individual」を選択した場合、条件には個人 (Individual)、連絡先メール (Contact Point Email) などの連絡先 DMOの項目値を利用できますが、ここでは例として氏名およびメールアドレスが完全一致する重複レコードを統合するルールを指定します。​氏名などのあいまい一致は英数字のみで利用でき、日本語の値に対しては完全一致のみ利用可能です。​一致ルールを定義したら、次に [調整ルール] を定義します。​ [調整ルール] では、統合されたレコードのうち、どのレコードの項目値を正として統合レコードで利用するかを選択します。[最終更新] : 最後に更新されたレコードの値を使用[最も頻繁] : 統合されたレコードの中で最も多く入力されている値を使用[ソースの優先度] : 統合されたレコードのオブジェクトの優先順位で値を使用[Individual ID] 項目では、[ソースの優先度] を利用します。​​保存後、[ルールセットを実行] より実行すると、処理結果画面に統合されたレコード数など以下のように表示されます。​各項目の意味についてはこちらに記載されています。​4. Data Cloud セグメントを作成するID 解決まで設定が完了したら、各種 DMO を基に Data Cloud セグメントを作成します。​【Data Cloud でのセグメントの作成】​💡ヒント💡  DMO 同士の関連性を確認するには、オブジェクト同士の関連性をビジュアルで表現する [データモデル] タブの [グラフ] ビューがおすすめです。​例えば以下の赤枠からは、Salesforce から取り込んだ取引先責任者 (Account Contact) は直接 Data Cloud の Individual (個人) に紐づいており、リードは取引先責任者 (Account Contact) を介して間接的に Individual (個人) と紐づいていることがわかります。​この DMO 同士の関係性は、後ほどセグメントで検索条件を定義する際に必要となるため、控えておくと便利です。​セグメントの作成は方法は【 Trailhead : セグメンテーションと有効化 】が参考になりますので、一読をおすすめします。​最初に [セグメント対象] を選択しますが、重複排除のため、前の ID 解決ステップで作成した統合個人 (Unified Individual) DMO を選択することが推奨されています。次に、セグメントの公開 (更新) 頻度を選択します。​高速公開は Marketing Cloud に対してデータを連携する選択肢のため、それ以外は標準公開を選択します。検索条件の設定画面で、左側パネルから項目を右側の [Include] エリアにドラッグ＆ドロップして条件を指定します。​除外条件を定義したい場合は [Exclude] タブに切り替えて追加します。例として、以下の条件で設定の流れをご紹介します。顧客 (リードまたは取引先責任者) の会社名が「Highlanders」（架空の会社名）である2023/03/01 以降、少なくとも 1 回のメールアクティビティがあるまずは、「顧客 (リードまたは取引先責任者) の会社名が「Highlanders」である」の条件から設定します。左側パネルの [関連属性] より [Account Contact] > [Account] と辿り、[Account Name] 項目を右側にドラッグアンドドロップ[メジャメント] に利用する 集計タイプ  (例 : 件数|以上|1) を選択[Account Name] 項目の値の検索条件 (例 : 次の値を等しい|Highlanders) を指定リードレコードも含められたい場合は、一度左側パネルの [関連属性] の家アイコンにてトップに戻り、 [Lead] に入り、[Company Name] 項目で同様にフィルターを指定次は「2023/03/01 以降、少なくとも 1 回のメールアクティビティがある」の条件です。左側パネルの [関連属性] より [Email Engagement] を開き、[Engagement Date Time] 項目を右側にドラッグアンドドロップ[メジャメント] に利用する 集計タイプ  (例 : 件数|以上|1) を選択[Engagement Data Time] 項目の値の検索条件 (例 : 次の日の後|2023/03/01) を指定最後に右側の AND / OR 条件にて、内側の [Account Contact] および [Lead] 条件を OR で、Email Engagement を外側の AND で指定条件を指定したら、[今すぐ公開] よりセグメントを公開します。下記のメッセージが表示されますが、Account Engagement のダイナミックリストで利用する分には対応は不要です。セグメントの公開が完了すると、[公開履歴] に抽出されたレコードが確認できます。​これで、Data Cloud セグメントの作成は完了です。​5. 組織で Data Cloud と Account Engagement を接続する次に、Data Cloud と Account Engagement を接続します。[設定] の [クイック検索] ボックスに「Data Cloud」と入力します。[設定] で [Account Engagement] を選択します。[はじめよう] をクリックします。接続する Account Engagement ビジネスユニットを [選択されたビジネスユニット] 列に追加し、[完了] をクリックします。* Data Cloud Salesforce 組織に関連付けられているビジネスユニットのみを接続できます。ビジネスユニットは後で追加、削除できます。​6. Account Engagement で Data Cloud セグメントを使いダイナミックリストを作成する最後に Account Engagement にてダイナミックリストを作成します。ビジネスユニットごとに最大 5 つのダイナミックリスト、リストごとに最大 100 万のプロスペクトを含めることができます。作成する際、[ダイナミックリスト種別] に「Data Cloud セグメント」を選択し、作成した Data Cloud セグメントを選択します。ダイナミックリストの抽出処理の完了を待ち、Data Cloud セグメントと同じ件数がリスト化されていることを確認できます。これで、Data Cloud セグメントを基に作成した Account Engagement ダイナミックリストに対して、メール送信等を実施できるようになりました。​Data Cloud セグメントと Account Engagement ダイナミックリストでレコード件数が合わない場合は、以下の点を確認ください。​基となるリードや取引先責任者レコードが、Data Cloud と直接つながる Salesforce に存在するかData Cloud は他の Salesforce 組織のリードや取引先責任者なども取り込めるが、Account Engagement のダイナミックリストで利用できるのは、Data Cloud と直接つながる Salesforce にあるリードや取引先責任者のみSalesforce と Account Engagement 間で、リードや取引先責任者とプロスペクトレコードが同期しているかData Cloud セグメントに含まれるリードや取引先責任者が同期するプロスペクトレコードのみが対象参考Account Engagement: Data Cloud インテグレーション実装ガイドまとめ本記事では、Summer ’23 にリリースされた、Data Cloud で作成したセグメントを基に Account Engagement のダイナミックリストを作成する機能について解説しました。​運用方法や他社事例などについては、質問広場～初心者から上級者まで～ 日本 グループまたは Account Engagement(旧Pardot) 日本 グループにてご質問ください。​個別の技術質問につきましては、ヘルプ & トレーニングより弊社サポートへお問合せください。

オートメーション機能の期間指定の条件

この記事で学べることAccount Engagement オートメーション機能の期間条件の違いについて理解する期間条件を使い分けてプロスペクトを抽出するはじめにAccount Engagement では、オートメーション機能（ダイナミックリスト、オートメーションルール、Engagement Studio）のルール条件に期間を指定することが可能です。指定可能な条件の演算子には複数のオプションが用意されていますが、それらが具体的にどの期間を指定しているのか、図式でわかりやすく解説していきます。​期間指定ができる条件Account Engagement のオートメーション機能で日数指定ができる条件は以下の 3 パターンです。プロスペクトのメール開封メールを開封しているメールを開封していないプロスペクトの時間数日前に作成数日前の最新アクティビティプロスペクトのカスタム項目（日付型）前提期間指定時には以下の点に留意する必要があります。期間指定は、時間ではなく、0 時起点の日数でカウントする相対期間の条件の場合は、抽出実行時点の日付（本日）を起点にする期間指定のパターン（１）プロスペクトのメール開封過去を遡る一定期間にメールを開封した / 開封していないプロスペクトを絞り込みます。​設定例過去 1 週間以内にメールを開封したプロスペクトを抽出条件例：[プロスペクトのメール開封]｜[メールを開封している]｜最後の [1] [週]過去 3 日以内にメールを開封していないプロスペクトを抽出条件例：[プロスペクトのメール開封]｜[メールを開封していない]｜最後の [3] [日]期間指定のパターン（２）プロスペクトの時間過去を遡る一定期間に作成された / 作成されていない・アクティビティがある / アクティビティがないプロスペクトを絞り込みます。設定例過去 60 日以内にアクティビティがあるプロスペクトを抽出条件例：[プロスペクトの時間]｜[数日前の最新アクティビティ]｜[次の値より小さい]｜ [60]過去 30 日より前に作成されたプロスペクトを抽出条件例：[プロスペクトの時間]｜[数日前に作成]｜[次の値より大きい]｜ [30]期間指定のパターン（３）プロスペクトのカスタム項目（日付型）日付型のプロスペクトカスタム項目に対して、特定期間や特定日前後の日付値を持つプロスペクトを絞り込みます。指定可能な演算子のうち、以下について紹介していきます。​次の日付より前：指定日より過去の日付（指定日を含まない）次の日付より後 ：指定日より未来の日付（指定日を含まない）次の間：指定期間（指定日を含む）設定例項目値が [2024-01-01] より前のプロスペクトを抽出条件例：[プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日付より前]｜ [2024-01-01]項目値が [2024-01-01] より後のプロスペクトを抽出条件例：[プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日付より後]｜ [2024-01-01]項目値が [2023-12-29] 〜 [2024-01-03] の間のプロスペクトを抽出条件例：[プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の間]｜ [2023-12-29] および  [2024-01-03]​次の間：指定期間（指定日を含む）次の日数以上前：指定日数以上の過去の日付次の日数以内前：指定日数以内の過去の日付（本日を含む）次の日数以上後：指定日数以上の未来の日付次の日数以内後：指定日数以内の未来の日付（本日を含む）設定例プロスペクト項目（日付型）の値が 3 日前のプロスペクトを抽出条件例：すべて一致[プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日数以上前]｜ [3][プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日数以内前]｜ [3]​プロスペクト項目（日付型）の値が本日のプロスペクトを抽出　　　　　　以下パターンどちらかで指定が可能です。条件例 パターン 1：すべて一致[プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日数以上前]｜ [0][プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日数以内前]｜ [0]条件例  パターン 2：すべて一致[プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日数以上後]｜ [0][プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日数以内後]｜ [0]​プロスペクト項目（日付型）の値が 3 日後のプロスペクトを抽出条件例：すべて一致[プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日数以上後]｜ [3][プロスペクトのカスタム項目]｜[（プロスペクトカスタム項目名）]｜[次の日数以内後]｜ [3]学習ツールヘルプ記事：オートメーションルールの条件ヘルプ記事：ダイナミックリストルール条件ヘルプ記事：Engagement プログラムのルールナレッジ記事：Account Engagement (旧Pardot) に関するよくある質問まとめ本記事では、Account Engagement オートメーションルール機能における期間指定の条件について解説しました。運用方法や他社事例などについてご質問がございましたら、 Account Engagement(旧Pardot) 日本 グループまたは質問広場～初心者から上級者まで～ 日本 グループにてご質問ください。個別の技術的なご質問がございましたら、ヘルプ & トレーニングより弊社サポートへお問合せください

継続的な改善を実施しましょう

この記事で学べること運用開始後にやるべきことシステムや運用の改善におけるポイントこの記事のゴールこの記事のゴールは「運用開始後に何をすべきかを理解する」ことです。そのために、以下3ステップで進めていきます。運用開始後の進行イメージ運用改善の進め方システム改善におけるポイント運用開始後の進行イメージ運用開始までにさまざまな検討と実装を行いましたが、運用開始後の定期的な改善も極めて重要です。Sales Cloudは状況の変化に合わせて、設計・運用を改善し続けることで、業務に合ったシステムであり続けることが可能です。そのため、ステップ3の「運用開始に向けて必要な役割を明確にしましょう」で決定した役割は、運用開始後も継続して担っていただくことが必要です。​運用開始後の進行イメージを参考に、定例会議の目的と頻度、アジェンダ検討し、PDCAサイクルを回していきましょう。※担当、時間は参考です。自社の役割に応じて適宜ご変更ください。※重要なのは定期的に改善の会議を設定することです。運用改善の進め方1．行動の変化を起こすためのサクセスマップの作成状況の変化に合わせてシステムを最適化していくということは、同時に目標や目標達成に向けた戦略や活動についても定期的に見直しを行い改善をしていく必要があります。​「目標達成のためにやるべきこと検討しましょう」では、運用開始に向けて早期に着手するための手法をご案内しましたが、運用改善や新年度など節目となるタイミングで、目標達成に向けた計画をアイデアベースで持ち寄りながら整理するためのサクセスマップを利用することをおすすめいたします。サクセスマップについての説明や作成の流れはこちらの記事の動画にて詳しくご説明しております。​2．現場からの改善要望・意見を収集し改善を行う経営層・マネジメントの目線で「いかに目標達成を実現させるか」というサクセスマップを用いた改善方法に加え、利用ユーザー目線で「現場からの改善要望・意見を収集」を行い、日々の業務により浸透をさせていくという改善方法も併せて実施しましょう。​要望・意見の受け付け方はさまざまですが、Sales Cloud上で受け付ける場合は、要望受付用のChatterグループを作成したり、要望を管理するカスタムオブジェクトを作成することで、Sales Cloud上に要望を蓄積し管理することができます。Sales Cloud上ではなく、SlackなどのチャットツールやExcel/スプレッドシートで要望を受け付けても問題ありません。その際は、以下のように一覧として管理することをおすすめします。要望・意見を受け付けたら、優先順位をつけて対応していきましょう。参考までに、2つの優先順位づけ方法をご紹介します。​まず1つは、ビジネスへの影響度と実装難易度の二軸で優先順位を決める方法です。ビジネスの影響度が高く、実装難易度が低い要望から対応します。次に、Sales CloudのChatter機能を活用する方法です。「いいね！」の数が多い投稿が、多くのユーザーが賛同している要望をみなして優先的に対応します。システム改善におけるポイント現場の要望・意見を受け付けて改善することは大事ですが、すべてをSales Cloudに反映すればいいというわけではありません。現場からのリクエストのたびにSales Cloudの入力項目を増やせば、逆に使い勝手の悪いシステムになる可能性があります。また、声の大きい利用ユーザーや部署だけの要望を受け付けていると、特定の利用ユーザーや部署だけが使いやすいシステムになってしまう可能性もあります。そのため、収集した要望・意見をシステムに反映する基準や、反映した後の利用ユーザーへの説明方法など、ルールをしっかり定義しておきましょう。学習ツールより詳しく知りたい方は、エキスパートコーチングのオンデマンド動画をご視聴ください。Premier Success Planをご契約のお客様は、動画視聴後1対1のフォローアップセッションにお申し込みいただけます。カスタムオブジェクトの作成：Platform : オブジェクト設計の基礎運用開始後の進行イメージ/運用改善の進め方：活用度向上支援（SFA 運用ルール、トレーニング、定着化プラン）また、AppExchangeについてはこちらのWebページをご参照ください。まとめSales Cloudは運用開始後も継続的に改善することが重要です。運用開始後も定例会議を実施しながら、より良いシステムへと改善し、成果創出へとつなげていきましょう。​ご不明点やエラーの解消が必要な場合は、弊社テクニカルサポートにお問合せください。弊社サポートエンジニアが貴社のSalesforce環境を確認の上、具体的な手順をご案内いたします。ナレッジ記事：Salesforce カスタマーサポートへの問い合わせ次は、いよいよ最後の章です！自社の活用状況を診断するための方法を理解しましょう！次の記事：自社の活用状況を診断しましょう​「活用7ステップ」全体に戻りたい場合はこちら

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

この記事で学べること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 - 時間ベースのワークフロー（ヘルプドキュメント）まとめ以上がワークフロールールの活用事例のご紹介でした。​ルールに定義された条件に基づいて、自動的にタスクをユーザに割り当て、特定の項目を更新することができるワークフロールールは営業、マーケティング、サポートなどの自動化に役立ちます。​ワークフロールールをはじめとする自動化ツールを活用することで、業務の効率化だけでなく、業務ルールの徹底など様々なメリットがあるのでぜひご活用ください。​

項目監査履歴とは

この記事で学べることデータの変更履歴の長期保存がどうして必要なのかを理解し、標準機能で提供される項目履歴管理との違いを理解します。項目単位に変更履歴を設定する方法を学びます。項目履歴管理（標準機能）との違い項目監査履歴（オプション）は、項目履歴管理（標準機能）の制限を拡張させたものですが、利用できるエディション、オブジェクトあたりの追跡できる項目数、保存期間、および保存場所に以下のような違いがあります。​​項目履歴管理項目監査履歴​利用可能なエディション全てEnterprise、Performance、Unlimited​項目数/オブジェクト最大20項目最大60項目​保管期間本番組織に18 か月API 経由で最大 24 か月アクセス可本番組織に18ヶ月アーカイブ後は無期限​保管場所StandardObjectNameHistory または CustomObjectName__Historyアーカイブ前は項目履歴管理と同じアーカイブ後はFieldHistoryArchive Big Object項目監査履歴を利用するメリットイベントモニタリングは、ページまたはレコードレベルでユーザのアクセス履歴を追跡するためのログを提供しますが、更に項目監査履歴を利用することで、レコード内の項目値がどのように変更されたかという履歴を追跡することができるようになります。以下のような要件を満たす必要があるお客様にメリットをもたらします。データの変更履歴を監査証跡として提示し、更新処理が正確で改ざんなどの不正がないことを証明することが求められるが、以下の点で標準機能ではお客様の要求を満たすことができない場合追跡したい項目がオブジェクトあたり20項目を超えるデータを21ヶ月以上の長期間保管したい個人情報保護法や GDPR に求められる個人情報の正確性に対して厳密に準拠したい場合企業の会計情報に影響を与える情報を Salesforce 内で保存管理をしている場合規制業種のお客様（金融サービス、ヘルスケア、ライフサイエンス、医療機器、研究機関など）が、法令やガイドラインで求められる履歴データの保持要件に適合する場合顧客のレコードの項目値がどのように変更されたかの履歴を、過去に遡って調べる必要がある場合変更履歴を保管する仕組みを予めユーザに周知することで期待される、不正行為（コミッションに関係する金額の改ざんなど）の抑止効果コーポレイトガバナンスを強化したい場合項目監査履歴の特徴項目監査履歴データは、Salesforce 組織のデータストレージ制限には含まれませんので、ログを蓄積することでお客様組織のストレージが消費されてしまう心配はありません（項目履歴管理も同様の仕様です）データの変更履歴は、オプションの契約手続きが完了すると、本番組織に18ヶ月保管した後 Big Object にアーカイブされるよう自動的に仕様が拡張されますので、お客様側での特別な設定作業は不要です一部のオブジェクトに対しては、オブジェクトごとに保持ポリシーを定義できます。本番組織の保存期間は 0 〜 18 ヶ月、アーカイブの保存期間は  0 〜 無期限、の範囲で設定可能ですアーカイブデータには 、データローダーやSOQL または Bulk API によるクエリを実行することでアクセスできます 変更履歴を追跡するために必要な設定・操作項目の変更履歴を追跡するための基本的な設定手順は、項目履歴管理（標準機能）と同じです。レコードの変更履歴を管理する を参照ください。項目監査履歴（オプション）で必要となる設定や操作はに以下のものがあります。Salesforce メタデータ API を使用して、オブジェクト単位で変更履歴の保持ポリシーを更新できます。この設定を行うのは、アーカイブデータの保持ポリシーに設定されているデフォルト値（本番組織に18ヶ月、アーカイブは無期限）を変更する場合のみです。例えば、取引先オブジェクトの変更履歴は、本番組織には6か月間、アーカイブには5年間保持する、といった内容でポリシーを変更することができます。メタデータの具体的な編集例はヘルプ記事を参照くださいアーカイブデータを照会するには、FieldHistoryArchive オブジェクトに対して SOQL クエリを実行します。実行する SOQL 文の例は、SOQL with FieldHistoryArchive（英語）を参照ください データローダーで、FieldHistoryArchive オブジェクトのデータをエクスポートすることもできます一般的な考慮事項本番データのレコードを削除すると、関連する履歴レコードもカスケード削除される仕様は項目履歴管理と同じですが、Big Object にアーカイブされたデータは削除されません。このデータを削除するための手順は、「項目履歴および項目監査履歴データの削除」を参照してください項目監査履歴を有効にしている組織で、後からプラットフォーム暗号化を有効にした場合、アーカイブされたデータは自動的に暗号化されません。ヘルプ記事をご確認いただき、アーカイブされたデータを暗号化するためには弊社サポートにお問い合わせください学習ツールサクセスナビ：レコードの変更履歴を管理するヘルプ ：項目監査履歴実装ガイド：Field Audit Trail Implementation Guide(英語)トレイルヘッド：アプリケーションへのセキュリティレイヤの追加まとめ項目監査履歴により、長年にわたり、内部統制が適切に行われていることを確認し、第三者に証明できることによりコーポレートガバナンスの強化が実現できます。項目履歴管理（標準機能）の制限拡張オプションですので、ライセンス購入後に特別セットアップは必要にありませんが、保存期間を調整する場合には設定が必要です。

実装時の注意点を理解しましょう

この記事で学べること運用開始に向けた実装時の注意点活用しやすくするための工夫・アイデアこの記事のゴールこの記事のゴールは「運用開始に向けた実装時の注意点、活用をしやすくするための工夫・アイデアを理解する」ことです。そのために、以下3ステップで進めていきます。可能な限り標準機能で実装する必要最低限な項目を実装する実装におけるステップと、実装時の工夫・アイデア可能な限り標準機能で実装するSales Cloudには最初から用意されている標準機能と自由に定義して設定ができる機能があります。その中で、Salesforceは最初から用意されている「標準オブジェクト」や「標準項目」を使用することを推奨しています。​標準機能を使うべき理由導入にかかる初期投資を削減できるSalesforceの年3回のバージョンアップの恩恵を受けられるAppExchange(機能を拡張するためのアプリ)の価値を最大限に利用できる​​表示する名称変更​例えば「リード」「商談」など標準オブジェクトや標準項目を使いたいが、聞き馴染みのない名称で活用推進に不安が残る場合は、画面表示する名称だけを変更設定することもできます。ほとんどの標準オブジェクトや標準項目については、画面表示する名称を利用ユーザーが日常的に使っている用語に変更設定することができます。標準機能をベースに利用ユーザーが閲覧する名称だけ変更する方法もご検討ください。​ヘルプ記事：オブジェクト、タブ、項目の表示ラベルの名称変更必要最低限な項目を実装する既存のツールやExcelをベースにSales Cloudの入力画面を設計するときには注意が必要です。理由は主に2つあります。既存のツールと全く同じ設計をしても、ツールが変わる分入力負荷や使いずらさが増すだけSales Cloudのデータ構造を考慮せずに設計されてしまうため集計の工数が増える​入力の負荷が高いなどの理由から運用開始後に再度、Sales Cloudを構築し直す判断が必要な場合も少なくありません。可視化・分析した情報は何なのか？目的に応じて必要最低限な入力項目に絞って実装することが重要です。実装におけるステップと、実装時の工夫・アイデア実装における推奨のステップは以下の通りです。​次に、実施ステップに沿って標準機能を使った実装時のアイデアをご紹介します。​1．最低限必要な項目を絞り込む○必要な項目だけを表示する必要最低限の項目として「ダッシュボードでの計測に使う予定の項目」や「業務上必要な項目」などに厳選して画面表示設定をしましょう。​2．画面レイアウトを整える○画面レイアウトに補足説明を加える各項目の言葉の定義などをヘルプテキストやページレイアウトの設定で補足説明をすることができます。​​○不要なアクションを非表示にする画面レイアウトをシンプルにする方法として自社で使う機能だけを表示する方法もあります。ヘルプ記事：ページレイアウト​​3．負荷の少ない入力/管理方法を選択する○デフォルト値項目値にデフォルトの入力フォーマットを指定することで、ユーザーが手入力しなければならない情報の一貫性向上と入力負荷の軽減が期待できます。ヘルプ記事：デフォルト項目値​○クイックアクション特定のタイミングで更新が必要なレコードについて、編集が必要な項目を一まとめにし入力工数を減らす工夫ができます。ヘルプ記事：クイックアクション​○リストビュー編集したい項目をまとめて編集することができます。ヘルプ記事：リストビューの作成​○モバイル活用モバイルの活用が可能な場合は、外出先からでも活動入力ができるように設定を行いましょう。ヘルプ記事：Salesforce モバイルアプリケーション​​4．入力規則により抜け漏れ・ミスを防止する○入力規則項目の入力必須設定を行うことで、抜け漏れや入力ミスを未然に防ぐことが可能です。ヘルプ記事：入力規則​条件に合致したときだけ特定の項目を入力必須にする​以上、自社の運用に取り入れることができそうな実装の工夫・アイデアはありましたでしょうか？本章の内容も踏まえて、[Sales Cloud]初期設定チェックリストに沿った初期設定を進めていきましょう！学習ツールより詳しく知りたい方は、エキスパートコーチングのオンデマンド動画をご視聴ください。Premier Success Planをご契約のお客様は、動画視聴後1対1のフォローアップセッションや個別セッションにお申し込みいただけます。項目の作成や、ページレイアウトに関するエキスパートコーチング：はじめよう：Sales Cloud アドミン基礎 （※個別セッションのみ）Sales Cloud 簡単設定支援プログラム （※オンライン集合研修/全3回）モバイルの設定に関するエキスパートコーチング：はじめよう：モバイル・クイックスタート（※個別セッションのみ）まとめ活用推進・定着に向けた実装時の注意点・工夫の仕方について理解できましたでしょうか？​ご不明点やエラーの解消が必要な場合は、弊社テクニカルサポートにお問合せください。弊社サポートエンジニアが貴社のSalesforce環境を確認の上、具体的な手順をご案内いたします。ナレッジ記事：Salesforce カスタマーサポートへの問い合わせ実装時の注意点を理解できたら、次はデータの取り込み方法を学びましょう！次の記事：データの取り込みを行いましょう​「活用7ステップ」全体に戻りたい場合はこちら