記事一覧

  • 過去動画一覧

    2022年2022年4月分2022年3月分2022年2月分2022年1月分2021年2021年12月分2021年11月分2021年10月分2021年9月分2021年8月分2021年7月分2021年6月分

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

    この記事で学べることSalesforce コア製品に関する重要な技術情報バージョンアップ情報やメンテナンス情報(バージョンアップ以外)、IPアドレスフィルタリングをしている場合に必要なIPアドレス範囲に関する情報、製品廃止情報、リリース更新などの重要情報セキュリティに関する重要なアップデート動画で学ぶhttps://play.vidyard.com/XyqKVu7idyK2892CGsKJPb記事で学ぶ当記事では「Salesforceの運用に関するお知らせ」の中から、特に重要なものを抜粋しご紹介します。前半は技術編、後半はセキュリティ編の構成となっております。利用中の機能について言及があった場合は、当記事や動画をご確認いただき、不明点があれば早めにサポートへご確認をお願いします。まずは、技術編についてのアップデートとなります。今月のトピックはこちらになります。当記事内では、前月との差分である赤字の部分についてご紹介します。その他のトピックは、資料(日本語) よりご確認をお願いします。​Summer ’22 のバージョンアップのスケジュールが公開されました。日本のお客様の本番環境は、2022年6月12日にバージョンアップが行われる予定です。それに先立ちまして、日本時間の5月8日から Sandbox プレビューが始まっております。​関連リンク重要な日付Salesforce Sandbox プレビュー手順Sandbox Preview GuideSpring’22 リリースノートの更新情報です。既存の動作に変更があるもので、特に管理者の皆様に知っていただきたいものを抜粋しておりますのでご確認ください。​関連リンク拡張ドメインの有効化 (リリース更新)連続する API ナビゲーションコールの防止 (リリース更新)ゲストユーザの「フローを実行」の廃止Spring ’22 更新情報一覧​Salesforce の IP アドレスとドメインに関する更新情報です。「Salesforce アプリケーションからのメールを受信できるようにする」という記事が2月4日に更新されました。更新内容としましては、Hyperforce メールリレーセクションに USA/DEU/SGP/BRA/FRA の IP アドレス情報の追加となります。なお、Hyperforce については、サクセスナビ内に情報を整理しておりますのでよろしければこちらもご確認ください。​関連リンクSalesforceのIPアドレスとドメインで許可するHyperforce 上の Salesforce サービスへの中断しないアクセスを維持するSalesforce アプリケーションからのメールを受信できるようにする​​機能の廃止に関する情報です。ここでは新たに追加された2点についてご紹介いたします。Marketing Cloud のマイデータ機能が Summer ’22 で廃止される予定です。Summer ’22 以降、購読者レベルのデータ抽出をする際は、Automation Studio を使用することをお勧めします。Tableau CRM のAdvisor Analyticsアプリケーションが9月1日に廃止予定です。後続機能はClient Segmentation アプリケーションとなりますので、早めの移行をお願いします。​関連リンクMarketing Cloud マイデータ機能の廃止Advisor Analytics アプリケーションの廃止​今後廃止予定の API バージョンについてです。システム連携ができなくなるなどの影響がある場合がございますので、該当のバージョンをご利用中のお客様は必ずご確認をお願いたします。​関連リンクSalesforce Platform API バージョン 7.0 ~ 20.0 の廃止Salesforce Platform API バージョン 21.0 ~ 30.0 の廃止サクセスナビ:Salesforce Platform API バージョン 7.0 ~ 20.0 の廃止 ​技術編の最後になります。Summer’22 で自動有効化予定のリリース更新情報です。前述の API バージョンの廃止以外にも、いくつか更新がございますのでご確認ください。​関連リンクフローおよびプロセスの CPU 時間消費の正確な測定 商品へのゲストユーザアクセス権の保持と制御を行う共有ルールの作成同じコンテキストと同じユーザアクセス権で一時停止中のフローインタビューを再開する Salesforce Platform API バージョン 7.0 ~ 20.0 の廃止注文の新規保存方式の有効化​4月分の技術関連情報は以上となります。​次は、セキュリティに関するアップデートをご紹介します。先月との差分は、MFA 適用に関するロードマップ、そして Spring’22 で導入された「Salesforceメール確認」の機能についてです。​MFA 適用のロードマップについて更新箇所をご紹介します。Marketing Cloud Engagement2022年6月1日から17日にかけて強制適用が実施されます。Marketing Cloud Social Studio特権ユーザの自動有効化が2022年5月9日から 13日に実施され、他のユーザについては、6月から8月の間に自動有効化が実施されます。また強制適用が2022年11月30日に予定されております。Tableau Online特権ユーザの強制適用日が、2022年6月21日となっております。他のユーザにつきましては6月から9月の間に強制適用が行われます。以上がロードマップの更新箇所となっております。最後に、Spring’22で導入された「Salesforceメール確認」の機能についてです。こちらは以前にもご紹介したもので、メールアドレスの検証を終えていないユーザが Salesforce 上でメール送信処理を行った際に、メールアドレス確認を目的とした検証用メールが対象ユーザに対して送信されるというものです。本機能に関する公開ナレッジが更新されており、SSO ユーザが存在する組織では検証用メールが送信されないこと、SSOユーザに関する検証メカニズムは改善を検討中であることが記載されました。詳細につきましては Summer’22 リリースノートや公開ナレッジでご案内させていただきますので、情報のアップデートをお待ちいただければと思います。​関連リンクSalesforce からメールを送信するためのメールアドレスの検証 Spring '22 「 Salesforce メール確認 」という件名の認証メールについて ​4月度分のアップデートは以上となります。最後までご覧いただき、ありがとうございました。

  • Hyperforceの概要と移行について

    [更新・追記履歴]4/5   Hyperforce移行時に注意を必要とするポイント3/3   HyperforceでもメールリレーのIPアドレスは公開されますが、IPアドレスを使用したフィルタリングは非推奨ですこの記事で学べることHyperforceの概要Hyperforceとは何かHyperforceの利点Hyperforceの構成Hyperforce移行時のアクション移行時に確認が必要な内容[セミナー動画] Hyperforceの概要と移行の準備  (51:39)Hyperforceにようこそ!12/14に実施したセミナー動画にてHyperforceを解説いたします。概要と移行時に確認が必要なアクションを学習しましょう。https://play.vidyard.com/xxfZbcxZ7Yq61WsCfZVVix*画面右下の歯車マークより再生スピードが変更可能ですセミナーの配布資料とよくあるQ&Aこちらから参照ください​*動画でご紹介するポイントを以下にまとめています。動画の中でご紹介する各種リンクもこちらからご参照ください。​Hyperforceの概要Hyperforceは新しい製品や機能の名前ではありません。Hyperforceは皆様ご存知のパブリッククラウドパートナーが提供しているインフラ上に開発・構築された、新しいプラットフォームアーキテクチャ、皆様のSalesforce組織が動く基盤です。​新しいHyperforceのアーキテクチャを使うことで、Salesforceは、新しい機能の開発や既存機能の拡張という形で製品のイノベーションと、それをお客様に提供することに注力することができるようになると考えています。それに伴い、私達が最も大切にしているカスタマーサクセス、お客様のビジネスの成功を加速させていけると考えています。​上記スライドが、現在皆様の組織が稼働しているファーストパーティのデータセンター(左)とHyperforce(右)の違いのイメージになります。現在は、皆様がご利用のSales CloudやService Cloud、Experience CloudといったCRM製品は、日本のデータセンターで稼働していますが、Marketing CloudやCommerce Cloudといった一部の製品は海外のデータセンターで稼働しており、APIを使用して統合されています。またファーストパーティと Hyperforce の比較時に注目すべき重要な点は、データセンタープロバイダの進化です。物理インフラストラクチャを独自に実行する必要がなくなり、代わりにパブリッククラウドプロバイダのハードウェア上でサービスを実行します。これにより、独自に制御するレイヤ (プラットフォーム、クラウド、機能) に焦点を絞り、それらの準拠と安全性を確保し、お客様のニーズを満たすことが可能となります。​ご参考ナレッジ記事) Salesforce インスタンスの場所​Hyperforceの利点は、世界で最も信頼されているパブリッククラウドを使用して、あらゆる場所からビジネスを実行できることです。具体的な利点4点は以下の通りです。ハイパースケーラブル (拡張性)AWSなどのサービスを利用することで、お客様のビジネスニーズに合わせて、必要な時に拡張性がある状態で最新のハードウェアを利用いただけます。ハイパーセキュア Hyperforceは、現在のプラットフォームで得たセキュリティに関するベストプラクティスを組み込み、ゼロトラストベースで作成されています。またHyperforceには、現在海外のデータセンターで稼働している製品も統合される予定です。これにより全製品に共通して高いセキュリテイを担保できるので、お客様の大切なデータを安全に保護することが可能となります。ハイパーコンプライアントコンプライアンスについては、Hyperforce でのサービスに対して、現在と同等のセキュリティのコントロールと監査を実施すべく、認定を取得している最中です。最新の認定状況は、「クラウドを対象とするコンプライアンス」のサイトよりご確認いただけます。ハイパーコンパチブル後方互換性により、将来的な変化に対応できます。ご参考ナレッジ記事) Hyperforce について - 一般情報と FAQ​Hyperforceへ移行が決まったお客様については、約3ヶ月前に製品コミュニケーションメールにてシステム管理者様宛に通知致します。通知の中にコンプライアンス認定の状況の記載がありますので、必ずご確認いただけますように、お願いします。​ご参考ページ) クラウドを対象とするコンプライアンス ​上記がシステム管理者様へ届くメールのサンプルになります。​ご参考ナレッジ記事) Salesforce からの組織移行に関する「製品およびサービスに関するお知らせ」​Hyperforceのアーキテクチャを説明するに当たり、まずは、現在のファーストパーティとの違いをご説明します。まず、左側が現在のインスタンスを表し、東京と神戸に、それぞれデータセンターがあります。データセンター内には、インスタンス(例:AP0)があり、お客様の組織はそのいずれかに割り当てられます。このインスタンスは、東京と神戸、両方のデータセンターに存在しており、一方が稼働系(Active)、もう一方が待機系(Ready)の状態になっています。データは、稼働系のデータセンターから待機系のデータセンターへレプリケーション(コピー)されています。​右側がHyperforceを表し、リージョンとAvailability Zone(AZ)という概念があります。リージョンは地域を表し、リージョンの中に、物理的に分離された複数のというものが存在します。そして、Hyperforceはこれら各AZ上に構築されます。また、Hyperforceでは、インスタンス名はJPN1といった名称に変わります。インスタンスはリージョン内の複数AZによってホストされます。AZの中には、それぞれにアプリケーションサーバとデータベースがあります。そして、AZ:Bはアプリケーションサーバが稼働しており、同時にデータベースも稼働しています。(AZ:Bはアプリケーションサーバとデータベース両方が稼働系という状態です)一方、AZ:AとAZ:Cはアプリケーションサーバは稼働していますが、データベースは待機系になります。待機系のデータベースに対しては更新はできませんが、参照はできる仕組みとなり、変更はログレベルで他の AZ の 2 つのデータベースに非同期に複製されます。​上記は3 つの AZ すべてが低遅延ネットワーキングで接続されていることにより、すべてのアプリケーションサーバが最小限の遅延ですべてのデータベースと通信でき、すべてのデータベースがあらゆる変更の最新状態を保持できるため実現可能な構成であり、冗長性と障害回復作業が可能とするために重要な要素になります。例として、AZ:Aが災害で停止した場合、AZ:BとAZ:Cは稼働を継続可能であり、引き続きサービス提供が可能です。AZ:Bが災害等で停止した場合、データベースのノードはAもしくはCが稼働系に切り替わり、引き続きアプリケーションサーバはAZ:AとAZ:Cが動いているので、サービス提供をし続けることが可能です。下記スライドもご確認ください。​ご参考ページ)Hyperforce について - 一般情報と FAQTrust and Compliance Documentation (信頼コンプライアンスに関するドキュメント)こちらの「Reliability, Backup, Business Continuity, and Disaster Recovery」で詳細をご確認いただけます​​Hyperforce移行に向けた準備Hyperforceへの移行に際して お客様にご確認頂きたい内容と推奨事項がございます。必要なアクションは、お客様の設定内容やご利用方法によって異なります。​Hyperforce への移行は組織移行というメンテナンスと同じ手法であり、これまで10年以上の実績のある手法です。また、厳格な対象資格条件があり、条件を満たしていることを社内で確認しています。既知のリスクがある場合、軽度なものであっても合致する可能性がある場合は、その組織の移行時期を延期いたします。このような資格条件とテストのプロセスにより、既に何千もの組織移行を成功させています。さらに、移行中、技術チームは普段と同じようにHyperforce移行前後で、異常がないかを監視し、万が一異常が検出された場合に備えて堅牢なサポートプロセスを構築し迅速に対応できるように技術チームが待機しています。移行に向けたSalesforce側の準備は万全ですので、安心してHyperforceへ移行いただけます。上記スライドは、お客様の組織がHyperforce移行の対象になった後のプロセスを示しています。前述のように、お客様は移行日の約3ヶ月前に最初の通知メールを受け取っていただけます。通知を受信後に準備を始めていただくことも可能ですが、この記事をご覧のお客様におかれましては、すぐに準備を始めていただけますと幸いです。​また、普段メンテナンス情報をTrustサイトにてご確認いただいているお客様もいらっしゃると思いますが、移行対象の組織が、インスタンスのごく一部のお客様のみの場合は、Trustサイトにメンテナンス通知が表示されない場合がございます。反対に、Trustサイトで組織移行のメンテナンスが表示されている場合も、システム管理者様がメールが受信されていない場合は、お客様の組織は移行対象ではないということになります。​なお、たまに「Salesforce製品およびサービスに関するお知らせ」のメールを受け取ったことがないというお客様がいらっしゃいます。ゴミ箱等に振り分けられていないか、合わせてご確認をお願いいたします。​ご参考ナレッジ記事) Trust 通知​​Hyperforceへの移行は、通常の「組織移行」というメンテナンスと同じであるため、組織移行時と同じ準備が必要となります。詳細は以下の参考ページをご参照ください。ハードコード化された参照の更新許可すべきSalesforceのIPアドレスとドメイン優先システムメンテナンスのスケジュール​上記スライドの1〜5に該当している場合、Hyperforce移行後に、不都合が生じる場合がございます。移行対象のお客様については、これら1〜5に合致しているかどうかを後続のスライドを参考の上、必ず確認をお願い致します。※2~4についてはイメージ図がございます。後続の[Hyperforce移行時に注意を必要とするポイント]をご参照ください​​上記スライドに記載のあるHyperforceで利用いただけないサービスをご利用のお客様は、現在Hyperforceへの移行対象から除外されております。​Hyperforceでは、WebブラウザやAPIクライアントは、SNI(サーバ名表示)で指定したホスト固有のHTTPS証明書を使って通信を行うことができるようになっています。SNIでホストを指定しない場合には、あらかじめ用意されているデフォルトの証明書を利用し、証明書の形式は、以下となります。<MyDomain>.my.salesforce.com<MyDomain>--<SandboxName>.sandbox.my.salesforce.com最近のWebブラウザでは特に意識する必要はございませんが、APIクライアントでデフォルト以外のHTTPS証明書を使う場合には、TLSハンドシェーク時のClientHelloメッセージにSNIを含める必要があります。そして、下の枠の中ですが、こちらはExperience CloudサイトやSalesforceサイトをご利用、かつ(www.example.comといった)カスタムドメインを利用し、独自のCDNをご利用されているお客様に関する内容です。「ドメインの外部 HTTPS の有効化」より、設定に関する詳細を参照いただけますので、ご確認をお願いします。該当の設定になっている場合、CDN 側の設定に置いて、SNI による証明書の認証を行わないという設定をして頂く必要がございます。また、ご利用のCDNが利用する証明書の SANs リスト内に*.my.salesforce.com が含まれている事を確認いただく必要があります。​CDN側の設定変更ができない場合は、Salesforceの設定オプションを「Salesforce は Salesforce コンテンツ配信ネットワーク(CDN) パートナーを使用してHTTPS を介してドメインを提供します」に変更します。​上記スライドはIPアドレスを使用したフィルタリング(IPアドレス許可リスト)をされているお客様にご確認をいただきたい事項になります。(Salesforce側の設定ではなく、お客様の会社のファイアウォールや企業ネットワーク、メールフィルターの設定をご確認いただく必要があります)​Hyperfroceでは、IPアドレスは公開されないため、現在IPアドレスを用いたフィルタリングをされている場合は、ナレッジ記事「許可すべきSalesforceのIPアドレスとドメイン」に記載のすべてのIPアドレス範囲に加えて、必須ドメインに含まれるすべてのドメインを許可頂く必要がございます。メールに関しても、Salesforceでは、メールセキュリティにIPアドレスを使用することを推奨していないため、ナレッジ記事「Salesforce アプリケーションからのメールを受信できるようにする」を参照いただきIPアドレスの代わりにTLS、SPF、DKIM、DMARC等の標準メールセキュリティプロトコルを使用を推奨いたします。※メールリレーのIPアドレスは、Hyperforceでも引き続き公開されますが、IPアドレスを使用したフィルタリングは非推奨です。IP アドレスフィルタリングだけに頼ることは、リクエストのソースに基づいて検証するに留まり、実際のリクエストが本物かどうかは検証はできないため、安全性の高いアプローチとは言えません。Salesforce→外部システム方向の連携処理(Apexコールアウトやアウトバウンドメッセージなど)をご利用の際は、IPアドレスフィルタリングではなく、適切な Web サービス認証と承認を行うことを推奨します。外部システム→Salesforce方向の連携処理がある場合は、URL/ドメインを使用したフィルタリングを推奨します。​上記スライドはメール送信に関するIPアドレスのフィルタリングについてです。こちらも、前述の内容と同様にSalesforceでは、メールセキュリティにIPアドレスを使用することを推奨していません。メールのフィルタリングをする際は、一般的に使用されているメールセキュリティメカニズム(TSL、SPF、DKIM、DMARC)といった方法を推奨しています。可能であれば、切り替えのご検討をお願いします。なお、メールリレーについてはHyperforceでも引き続き公開されます。しかし、IPアドレスを使用したフィルタリングは非推奨です。​Marketing Cloud Connectをご利用のお客様はナレッジ記事 「Marketing Cloud Connect でテナント固有の OAuth エンドポイントを有効にする」を参照いただき、TSOEの有効化をお願い致します。​カスタムHTTP証明書を使用するカスタムドメインは、現状Hyperforceで一時的に使用できない機能となっています。既にこの機能をご利用頂いているお客様は、移行対象から除外されていますが、現在未使用で、Hyperforceへ移行後からカスタムHTTPS証明書のご利用を検討されている場合、Hyperforceではこのオプションを使用することはできません。​HTTP1.0についても、現在Hyperforceでのサポート可否は検討中となり、HTTP1.0を既にご利用中のお客様はHyperforce移行対象から除外されておりますが、移行後からご利用になる場合や、稀にしか使わない(四半期に一度、年度に一度しか使わない)という場合には、Hyperforce移行後にご利用の際にエラーが発生しますのでご注意ください。​また、Hyperforceに限った内容ではございませんが、Hyperforceへ移行後に大きなコンテンツファイルのプレビューを表示できない場合がございます。このような事象が発生した場合、コンテンツファイルのプレビューを再作成する手順をナレッジ記事「コンテンツファイルのプレビューの問題」で公開しておりますのでこちらをお試しください。​Hyperforce移行時に注意を必要とするポイント[4/5追記] [お客様の状況]に当てはまる場合は、[対応方法]と[参考資料]をご確認の上、早めの対応をお願いします。※上記図中のリソースは、以下よりダウンロードできますNo.① 参考資料:Hyperforceウェブセミナー資料、Hyperforce 上の Salesforce サービスへの中断しないアクセスを維持するNo.②対応方法:証明書と鍵、Salesforce がサポートする SSL 証明書No.③お客様の状況:Office 365 との Salesforce「メールリレー」参考資料:Salesforce アプリケーションからのメールを受信できるようにするNo.④ 参考資料:Hyperforce における SNI による HTTPS/SSL 接続エラーの解決No.⑨ 対応方法:Marketing Cloud Connect でテナント固有の OAuth エンドポイントを有効にするNo.⑩ 参考資料:Marketing Cloud エンドポイントからテナント固有エンドポイントへの更新: FAQメンテナンス開始時間になったら、移行の準備が開始されます。実際の移行プロセスが始まる約 30 分前に、組織はリードオンリーモードになり、その後実際の移行が始まります。メンテナンス全体の作業時間は約 3 時間となっており、通常はこの時間内に移行が完了します。移行が完了・成功したことが確認されると、再度組織はリードオンリーモードになり、その後Hyperforce上でお客様組織が稼働します​リードオンリーモードの時間帯は参照のみとなります。外部データをSalesforceに取り込むといったような更新作業は実施いただけないため、社内のメンテナンスや作業日程を事前に確認いただくようお願いいたします。また、Hyperforce移行後に、古いインスタンスの Trust Notification の登録を解除し、新しいインスタンスの Trust Notification に再登録をおすすめいたします。​Hyperforceに関する技術的なご質問がございましたら、下記お問い合わせの手順を参考にテクニカルサポートへお問い合わせください。​学習ツール参考資料(英語原典と相違がある場合は、英語原典を最新情報としてご参照ください) Hyperforceのご紹介Hyperforce について - 一般情報と FAQクラウドを対象とするコンプライアンス信頼コンプライアンスに関するドキュメント信頼性、バックアップ、ビジネス継続性Trustユーザガイド製品およびサービスに関するお知らせSalesforce からの組織移行に関する「製品およびサービスに関するお知らせ優先システムメンテナンスのスケジュールSalesforce のメンテナンスとリリースへの準備と対応組織の移行への準備方法 ハードコード化された参照の更新許可すべき Salesforce の IP アドレスとドメインSalesforce アプリケーションからのメールを受信できるようにするメールセキュリティメカニズムドメインの外部 HTTPS の有効化カスタム HTTPS 証明書を使用するカスタムドメインMarketing Cloud Connect のテナント固有の OAuth エンドポイント (TSOE) を有効化リードオンリーモードの概要自分の Salesforce 組織が使用しているインスタンスを表示するSalesforce インスタンスの場所は?Hyperforce 上の Salesforce サービスへの中断しないアクセスを維持する[1/13追記]

  • 拡張ドメインの有効化とその準備

    この記事で学べること拡張ドメインの機能概要拡張ドメインによる変更点お客様による事前準備の内容拡張ドメインに関する参考情報こちらの記事の内容は動画でもご覧いただくことができます。拡張ドメインについて動画でご確認頂く場合はこちらをクリックしてください。拡張ドメインの概要拡張ドメインはWinter '23のリリースにてお客様組織で有効化されます。これによる変更は以下となります。(1)ブランドExperience Cloud サイト、Salesforce サイト、Visualforce ページ、コンテンツファイルの URL を含め、組織のすべての URL に [私のドメイン] の名前が含まれます。また一部のURLではドメインサフィックス ([私のドメイン] の名前の後の部分) も更新されます。(2)安定性お客様組織で使用されているすべてのURLからAP3やAP4などのインスタンス名が削除されます。今後インスタンス名を意識したお客様作業、メンテナンスが不要になります。(3)コンプライアンスお客様にてご利用いただいているブラウザにおける最新の要件(サードパーティ Cookieに対する対応)に準拠します。​上記の通り、本機能にて外部公開しているURLを含め、お客様組織のドメイン(URL)が更新されるため、Winter'23までにSandboxで動作確認/テストを実施いただき、お客様組織での影響度を確認の上で本番組織での有効化を実施することを推奨しています。​▼参考情報Salesforce ヘルプ : Experience Cloud とは?Salesforce ヘルプ : Salesforce サイト拡張ドメイン適用の背景主要なWebブラウザにて、サードパーティ Cookieをブロックすることが既定の動作となることがアナウンスされています。​Cookieとはなにかというと、Webサイトにアクセスしたユーザの情報を一時的にクライアントに保存しておくためにサーバから送信されたファイルです(ページ遷移やWebサイトへの再訪問に、同一ユーザー/ブラウザであることの判別に使用)。​サードパーティ Cookieとは、アクセスしたサイトとは異なるドメインから送られるCookieのことです。プライバシー保護の観点より、サードパーティcookieの利用に関する規制が強くなっている背景があり、各ブラウザでサードパーティ Cookieをブロックすることを既定の動作とする動きがあります。​その制限によりSalesforceのページで、異なるURLからコンテンツを読み込む際に問題が発生する可能性があります。例 : lightning.force.com というURLのページから、documentforce.com というURL を介してコンテンツを読み込む。このようなブラウザの最新要件にSalesforceも対応するため、URLを更新する目的で「拡張ドメイン」の適用を予定しています。拡張ドメイン適用までのロードマップWinter'23のリリースで、拡張ドメインがすべての組織で有効化されます。組織のすべての URL に [私のドメイン] の名前が含まれます。組織のすべてのURLからインスタンス名が除外されます。一部のURLのドメインサフィックスが変更されます。お客様による拡張ドメインの準備/テストSummer’21のリリースから、お客様組織の「リリース更新」には「拡張ドメインを有効化」が表示されています。Hyperforce 組織 または Salesforce Edge Network が有効化された組織で適用することができます。Winter'23までにSandboxでの動作確認/テスト、お客様組織での影響有無確認、本番組織での有効化を推奨します。*1)ほとんどのSandboxにて Salesforce Edge Network が有効化されていなくても拡張ドメインが利用可能になっています。  Spring ’22 Release Notes : Enable Enhanced Domains (Release Update)*2)一部の組織を除き、Salesforce Edge Networkが有効でない本番組織でも拡張ドメインを有効化できるようになりました。 Trailblazer Community : Enhanced Domains Available Everywhere Except Public Cloud​▼補足 : リリース更新の画面​▼補足 : リリース更新「拡張ドメインを有効化」の画面​拡張ドメイン適用による変更点本セクションでは、URLの用途と変更前後のURLをまとめています。本番組織のURL 形式SandboxのURL形式▼参考情報Salesforce ヘルプ : 拡張ドメインを有効にする場合の [私のドメイン] の URL 形式の変更​SaleforceサイトやExperience CloudサイトのURLをみると、変更後のURLには私のドメインが指定されていることが確認できます。このようなかたちで外部に公開しているURLが変更となります。​またVisualforceやコンテンツのURLをみると、すでに私のドメインが含まれているURLも更新されていることが確認できます。このようなかたちで拡張ドメインの適用によりお客様組織のURLが更新されます。お客様によるご準備上記にご説明させていただきましたとおり、拡張ドメインの適用によりお客様組織で使用されているURLが更新されます。これによりURLを直接参照するようなカスタマイズやシステム連携がお客様組織で実装されていると、エラーが発生する可能性があります。想定される影響範囲は以下の通りです。Experience Cloud  / Salesforce サイト、Visualforce ページなどへのアクセス時にエラーが発生する可能性がある。Salesforce の埋め込みコンテンツの一部が表示されなくなる可能性がある。サードパーティアプリケーションからデータへのアクセスができなくなる可能性がある。Sandbox とのシングルサインオンインテグレーションが失敗する可能性がある。*.cloudforce.com や *.database.com を使用する組織とのSSOインテグレーションが失敗する可能性がある。[お客様によるご準備]Winter'23のリリースは2022年10月16日に予定されています(最新情報はTrustサイトをご覧ください)。上記の問題を事前に回避するためにも、Winter'23リリースまでに下記を進めていただくことを推奨します。Sandboxで影響箇所の有無を確認し、影響箇所があった場合の対応方法を検討。Sandboxで確認できた対応方法(インテグレーション/カスタマイズの改修など)を本番組織に適用。URLが更新(時期や変更箇所)されることをユーザへアナウンス(ブックマークの更新等)。お客様公開サイトやマニュアル等に配置されているリンクを変更。関連リソースWinter’22 リリースノート拡張ドメインの有効化 (リリース更新)Summer’22 リリースノートEnable Enhanced Domains (Release Update)Redirect Your Site URLs After You Enable Enhanced DomainsUse Enhanced Domains in New and Refreshed SandboxesSalesforce ヘルプ拡張ドメイン拡張ドメインを使用する理由拡張ドメインに関する考慮事項拡張ドメインを有効にする場合の [私のドメイン] の URL 形式の変更必要なドメインを許可拡張ドメインを使用するデジタルエクスペリエンスのコンテンツ配信ネットワーク公開ナレッジSalesforce ドメイン (「私のドメイン」 と拡張ドメイン) の変更に備えた準備FAQQ1 : 「[私のドメイン] の名前」が外部のURLに使用されることを回避することはできますか。A1 : 「[私のドメイン]の名前」を変更する方法とカスタムドメインを使用する方法があります。「私のドメイン」を変更すると、既存動作に影響を与える可能性もあるため、カスタムドメインを使用することを推奨しております。詳細は「拡張ドメインに関する考慮事項」の「公開 URL の変更」をご覧ください。​Q2 : 拡張ドメインが適用される前のURLにアクセスするとどうなりますか?A2 : 拡張ドメインで変更される URL では、古い URL にアクセスすると、Salesforce が将来そのリダイレクトを停止するまで、新しいホスト名にリダイレクトされます。リダイレクトの終了はリリースノートで事前にこの変更をお知らせする予定です。詳細は「拡張ドメインに関する考慮事項」の「拡張されていない [私のドメイン] の URL のリダイレクト」をご覧ください。またリダイレクトの動作には以下の注意点がございますのでご確認ください。・拡張ドメインが有効になった後に「[私のドメイン] の名前」を変更すると、名前変更前のURLでのアクセスは名前変更後のURLにリダイレクトされますが、拡張ドメイン有効前のURLはリダイレクトされなくなります。(拡張ドメイン有効化以前のURLへリダイレクトが必要な場合には、拡張ドメイン有効化後に「[私のドメイン] の名前」を変更をしないで下さい)・「以前の[私のドメイン]を削除」ボタンを押下すると、リダイレクトはされなくなります。・「以前の [私のドメイン] の URL を現在の[私のドメイン]にリダイレクト」のチェックをOFFにしてテストをする事で、リダイレクトされなくなるので問題が発生する部分を確認する事ができます。​​Q3 : Salesforce Edge Networkが有効になっていることはどこで確認できますか?A3 : [設定] > [クイック検索] >「私のドメイン」と入力し、[私のドメイン]を選択してください。[ルーティング] セクションでご確認いただくことができます。詳細は 「拡張ドメインの前提条件」の「組織が Salesforce Edge Network の対象かどうかの判断」をご覧ください。​Q4 : Experience Cloud サイトや Salesforce サイトを使用していない場合は、影響はありませんか。A4 : 外部向けのURLだけではなく、内部向けのURLが更新されるものもございます(Visualforceなど)。これによりAppExchangeパッケージやお客様のカスタマイズに影響がある可能性もございますので、Experience Cloud サイトや Salesforce サイトを使用していない場合も、Sandboxでの動作確認/テストを推奨します。​Q5 : Salesforce Edge Networkも自動有効化の対象でしょうか。A5 : いいえ。Salesforce Edge Networkは自動有効化の対象ではありません。​Q6 : 現在使用しているカスタムドメインには影響はありますか?A6 : Experience CloudサイトやSalesforceサイトで使用するカスタムドメイン自体には影響はありません。CDN等の外部HTTPSベンダーでカスタムドメインを使用している場合には、外部HTTPSベンダーがSalesforceにアクセスするホスト名を[私のドメイン]のホスト名に変更する必要がある場合があります。​Q7 : API接続には影響があるのでしょうか?A7 : SandboxについてはURLに「sandbox」という文字列が追加されるため、影響がでる可能性があります。​Q8 : 拡張ドメインの有効化後に何かしらの問題が発生した場合にはどのように対応したらよいでしょうか?A8 : 自動有効化の前であれば拡張ドメインは有効化/無効化を実施することが可能です。自動有効の前に拡張ドメインを有効にする事で、何か問題が発生しても拡張ドメインを戻せるため、問題に対応する時間が取れます。もし、何かしらの問題が確認された場合は、弊社サポートにお問合せ下さい。​​​​

  • Salesforce Platform API バージョン 7.0 ~ 20.0 の廃止

    この記事で学べることSummer '22に廃止されるAPIバージョンと種類を知ることができますAPIバージョンの廃止スケジュールを知ることができますお客様にて必要な対応を知ることができますご存知ですか?Summer '22で古いAPIバージョンが廃止されます〜本記事は、Trailblazer Community にて皆様に共有させていただいた、こちらの投稿の内容です〜​Salesforceでは、API の品質およびパフォーマンスを充実させ、改善するために、(最初のリリース日から最低 3 年間サポートしますが)それを超えるバージョンのサポートは停止される場合があります。そのため、定期的にAPIバージョンを更新いただくことを推奨しています。​今回廃止対象のAPIの種類とバージョンは以下のとおりです。SOAP: 7.0、8.0、9.0、10.0、11.0、11.1、12.0、13.0、14.0、15.0、16.0、17.0、18.0、19.0、20.0REST: 20.0Bulk: 16.0、17.0、18.0、19.0、20.0ただし、この廃止には、カスタム Apex REST & SOAP Web Services、Apex クラス、Apex トリガ、Visualforce ページ(※)は含まれません。​※ VisualforceページでAJAX Toolkitを使用しており、そのAPIバージョンが20以下の場合は廃止対象です​AJAX Toolkitは、JavaScriptボタンやSコントロールで使用されることもあります。APIバージョンが20以下の場合は更新が必要です。廃止スケジュールバージョン20以下に続き、バージョン21~30のサポート終了・廃止予定もございますので、計画的にAPIバージョンの更新を行いましょう。​お客様にて必要な対応「そんな急に廃止と言われても・・・」と戸惑っているシステム管理者の方もいらっしゃるかもしれません。Salesforceでは、システム管理者様宛に、月次で、機能廃止ダイジェストメール等でお知らせしています。​メール本文の[廃止名]に「Salesforce Platform API バージョン 7.0 ~ 20.0」が含まれている場合は、APIバージョンの更新が必要です。メールがお手元に届いている場合は、以下を参考にご対応をお願いします。​推奨する対応順序例えば、設計書や実際にデータ連携している箇所を調査する。外部システムやツール(データローダ等)を使って Salesforce へ接続するアプリケーションの有無とバージョンを確認組織内の開発で AJAX Toolkit等を使用した実装有無とバージョンを確認手順1で確認した箇所のAPIバージョンを更新学習ツールSalesforce Platform API バージョン 7.0 ~ 20.0 の廃止(ナレッジ)イベントモニタリング(Trailhead)API合計使用量(開発者ガイド)まとめSalesforceのAPIは、最初のリリース日から3年経過すると廃止になる場合があるので、定期的にバージョンを更新する必要があります機能廃止に関するダイジェストメールが月次で配信されていますので、システム管理者様は必ず確認して下さい

  • 組織の体制変更がある場合の対応のポイント

    この記事で学べることSalesforce稼働後の(自社の)組織体制変更時の対応の流れを知ることができます組織体制変更時に使用するツールについて知ることができます組織体制変更時の対応の流れSalesforceのシステム管理者のみなさまは、普段新入社員のユーザを作成したり、退職するユーザを無効化したり、ユーザ情報の更新(部署やロール、プロファイルの変更)等のユーザ管理業務を行なわれていると思います。※ ユーザの管理については「ユーザ管理の便利機能」も参考にしてください。​今回は、期初や期末にみなさまの会社で行われる事があるであろう、組織の体制変更に伴い、Salesforceにどのような変更を行う必要があるかを考慮点含めて説明します。※人事異動の場合はユーザ情報の更新(ロール項目の変更)になりますが、今回はロール自体を変更する場合の作業の流れになります​一般的に、組織の体制変更がある場合、以下のような変更が行われると思います。それをSalesforceに反映させるための変更箇所は以下のとおりです。組織の変更に伴う変更点Salesforceの設定変更箇所組織の体制変更(新たな部署が設置される/既存の部署が統合されるなど)・ロール(自体)の変更・階層構造の変更既存の部門/部署名の変更・ロール(の名称)変更・ユーザの[部署名]の変更部署のメンバーの変更・ユーザの[ロール]の変更役職名の変更・ユーザの[役職]の変更お客様の担当替え・取引先や商談の[所有者]変更・活動の[任命先]変更注意事項:上記以外にも、例えば[ロール名]を条件にしたレポート、ダッシュボード、数式項目、フロー等の自動化設定がある場合は、それらの変更も忘れずに実施しましょうユーザの[ロール]や[役職]項目以外にも、プロファイル、マネージャーや権限セットの変更が必要な場合は一緒に変更しますSalesforceの設定変更箇所を把握したので、「早めに変更作業をしたい」と思うかもしれませんが、その前に!決めておくべきことがあります。移行ルール変更作業に着手する前に、関連部署のメンバーとあらかじめ以下を決めておくことで、変更作業をスムーズに進めることができます。組織の体制変更後に、Salesforceのデータをどのようなルールで共有するか(データへのアクセス権をどうするか)最終的に、どのようなロール階層にするか共有ルールを使用するか、使用する場合にはどのようなルールにするか誰がどの取引先を担当するか取引先の新旧担当者一覧の作成商談の担当はどうするか例:現在進行中の商談の担当者は変更しない、完了している商談の担当は変更しない(過去の実績を組織の体制変更前の担当で把握する必要がある場合は、担当者を変更しないでください)活動の担当はどうするか例:まだ完了していない活動の任命先を変更するか/しないか注意事項:上記以外のオブジェクトを使用している場合は、オブジェクト毎に担当をどのようにするかを決めておきましょう。​移行ルールが決まったら、次の流れで変更作業を行いますロール・共有ルールの変更ユーザ情報の変更各データの所有者変更1.ロール・共有ルールの変更まずは組織の土台となるロール、およびロールを使用した共有ルール(アクセス権)の設定を行います。ロールや共有ルールは、2.ユーザ情報の変更作業が完了するまでは反映されません。そのため、ユーザ情報変更作業前に、あらかじめ準備をしておきます。​組織の体制変更後の状態に合わせて、ロールを変更します。新たな部署が追加される場合は、[ロールの追加]からロールを作成します部署が統合される場合も、新たな部署を作成します。統合前の部署を残しておくと、退職したユーザのロールを変更する必要がありません​階層構造の変更はなく単なる名称変更の場合は、[表示ラベル]と[レポートに表示するロール名]を変更します階層構造が変わる場合は、[このロールの上位ロール]項目を変更します会社の合併など、大幅な組織体制変更の場合は、新しいロール階層を定義することをお勧めします。​組織の体制変更の前日までは、旧体制のまま業務を行う必要があると思いますので、あらかじめ新組織体制の準備でロールを作成しておき、新組織体制に変わるタイミングでユーザ情報を更新して新しいロール設定を反映させます。​次に、ユーザ情報を変更して、新しい組織体制を反映させましょう。2.ユーザ情報の変更組織の土台となるロールおよび共有ルールの設定が終わったら、ユーザ情報の変更を行います。​ユーザ情報は、以下3種類の方法で変更することができます。ユーザの詳細画面の[ロール]項目を変更するロールの詳細画面から複数ユーザを一括で変更するデータローダを使用する​ユーザの詳細画面の[ロール]項目を変更するロールの詳細画面の[ユーザをロールに割り当て]で、複数ユーザを一括で変更する(具体的な操作手順は、「ユーザへのロールの割り当て」(ヘルプ)をご覧ください)​データローダを使用する​組織の体制変更がある場合、一般的には、ロールを変更するタイミングでプロファイルや部署名、役職名等も変更になることがあると思いますので、それらを一度に変更ができるデータローダを使用することをお勧めします。(データローダの使い方ついては「初めてのデータローダ 〜Update編〜」(サクセスナビ)をご覧ください)​注意点:承認プロセスにマネージャー項目を使用している場合は、マネージャー項目も忘れずに変更しましょう。​ユーザ情報の変更が完了したら、取引先や商談などのデータを変更します。3.各データの所有者変更事前に定義した移行ルールに従い、データの所有者(や任命先)を変更します。​所有者の変更は、画面上から行える「所有権の一括変更」もしくはデータローダをご利用いただけます。どちらのツールが適しているかは、以下をご確認ください。​注意点:「所有者の一括変更」機能を利用できるのは、リード、取引先、カスタムオブジェクトのみです上記フロー以外のデータ(例:現在の所有者が所有している完了している商談など)の扱いについては、オプションで選択をすることができます。​以上で、組織の体制変更があった場合に、システム管理者様にて対応が必要な作業は完了です。学習ツールロールの項目(ヘルプ)ユーザの項目(ヘルプ)データの所有権の移行(ヘルプ)取引先の一括変更で、同時に移行されるデータについて(ナレッジ)まとめ変更作業を始める前に、移行ルールを決めておくことが重要ですデータ変更に使用できるツールは「所有権の一括変更」とデータローダがありますので、要件にあう方を選択しましょう

  • 認証情報の管理におけるベストプラクティス(セッション情報の管理)

    この記事で学べること認証情報の管理の重要性セッションを管理するための設定認証情報の管理の重要性最も基本的な対策はユーザ自身による管理の徹底です。ユーザが認証情報(パスワードやセッション情報など)を適切に管理していない場合、第三者による意図しないアクセスを招く可能性があります。業務を終える際には必ずSalesforceからログアウトすることを徹底するなど、ユーザ自身による日常的な対策もセキュリティの観点で重要です。セッション情報のセキュリティ認証情報に起因するセキュリティリスクを軽減するために、Salesforceには様々な機能が用意されています。このドキュメントでは、認証情報の一つである「セッション情報」のセキュリティを強化するための機能について取り上げます。​セッション設定セッション設定を見直すことで、セッション情報が流出した場合のリスクを軽減することができます。*1)接続アプリケーションのセッションポリシーの管理(ヘルプ)*2)接続アプリケーションの IP 制限の緩和および IP の継続的な適用(ヘルプ)各設定方法およびその他の関連する設定については、「セッションセキュリティ設定の変更」(ヘルプ)をご参照ください。尚、表に記載されている設定が適用される範囲は以下の通りです。​「すべての要求でログイン IP アドレスの制限を適用」は他のいくつかの設定と連動しながら動作します。当設定を有効化する場合は、以下の順序で検討してください。*1)拡張プロファイルユーザインターフェースでのログイン IP アドレスの制限(開発者ドキュメント)*2)セッションセキュリティ設定の変更(ヘルプ)*3)接続アプリケーションの IP 制限の緩和および IP の継続的な適用(ヘルプ)認証情報が流出した場合の対処万が一、セッション情報などの認証情報を第三者に流出させてしまった場合、影響範囲を限定的にするために早期対処が鍵となります。*1)ユーザのパスワードのリセット(ヘルプ)*2)Salesforce 多要素認証に関する FAQ(ナレッジ)*3)ユーザセッション(ヘルプ)*4)現在の OAuth 接続アプリケーションセッションの管理(ヘルプ)参考情報Salesforce セキュリティガイド(開発者ガイド)接続アプリケーションのセッションポリシーの管理(ヘルプ)セキュリティ状態チェック(ヘルプ)

  • MFAによるランサムウェア対策

    IPA(独立行政法人情報処理推進機構)は、その年に発生した社会的に影響が大きかったと考えられる情報セキュリティにおける事案から脅威候補を選出し、情報セキュリティ分野の有識者が審議・投票を行い決定したものを「情報セキュリティ 10大脅威」として公開しています。2021年度、「ランサムウェアによる被害」が昨年5位から1位にランクを上げて注目を浴びています。(出典:IPA(情報処理推進機構) 情報セキュリティ 10大脅威 2021 組織別順位・2021年8月23日)​ランサムウェアとは、マルウェアの一種です。特徴は、ランサムウェアに感染したコンピュータは、利用者のシステムへのアクセスを制限されてしまう。(暗号化、ロックなど)この制限を解除するための身代金を要求すること。身代金を払うことでその制限を解除するという犯罪に利用される。​日本国内でもランサムウェアによる被害が多数報告されています。2021年7月、ランサムウェアによる攻撃を受け、財務/販売管理の基幹システムやファイルサーバ、グループネットワークで運用していた販売管理システムや財務会計システムが暗号化された事例がありました。この事例で特徴的なのは、BCP(事業継続計画)として用意していたバックアップサーバも暗号化されて、業務復旧までに想定以上の時間を要し、四半期決算報告を延期せざるをえない結果となった点です。​同様に、10大脅威の3位にランキングしている「テレワーク等のニューノーマルな働き方を狙った攻撃」、8位の「インターネット上のサービスへの不正ログイン」に関しても、ランサムウェアによる攻撃につながる脅威として対応が求められます。​ランサムウェア対策の一つとして、MFA(多要素認証)を活用してユーザ認証を実施することにより、情報漏洩リスクを低減することが可能です。​コロナウイルス禍の影響で、ニューノーマルと言われる、クラウドシフトした業務システムの利用やリモートワークのような働き方改革が一般的になりました。ただ、企業のセキュリティ対策が、この変化に対応が取れていないのが現状です。従来のセキュリティ対策は、社員がオフィスへ出社し、イントラネットワークからアクセスすることを想定したものでした。ファイアウォールによって社内ネットワークをインターネットから切り離し、社外からのアクセスをチェックしていた境界防御です。ニューノーマルにおいては、境界をまたぐ形で社員からのアクセスや業務システムへの通信が発生し、外と内に分ける考え方では制御しきれない状況となりました。​ランサムウェアによる攻撃の例として、悪意の第三者が社内ネットワークにリモートからVPN接続するために必要なIDとパスワードを詐取した場合、従来型のセキュリティ対策ではプロアクティブに犯行を発見/防止することが困難です。社内ネットワークへ侵入した悪意の第三者は、正規ユーザとして社内の重要な資産にアクセスが可能で、その制御や発見するすべもありません。インターネットサービスの利用に関しては、企業内部からのアクセスを許可するIPアドレス制限をかけていたとしても、社内ネットワーク経由の接続は全て許可され、本人確認のチェックが効きません。詐取されたIDとパスワードを利用し、インターネットサービス上の業務システムから重要情報を取得し、社外へ持ち出されてしまいます。​ランサムウェア対策としてMFAを活用する背景には、ゼロトラストという「誰も信用しない」という考え方に基づき、ユーザを認証して社内外のアクセスをコントロールする必要性があるからです。全てのユーザはMFAという「関所」にアクセスし、認証された結果に応じて適切なアクセス権を付与されます。また、必要なタイミングでアクセス権を確認し、ユーザのコントロールと可視化をMFAは実現できます。​セールスフォース社の場合、全社員がVPN経由で社内ネットワークにアクセスする際、IDとパスワード以外にMFAによる認証が求められます。社内ネットワーク接続後も、重要な社内情報を閲覧する際にもMFAによる認証を求められ、アクセス権を有する社員かどうかをチェックする体制を取っております。​2022年2月1日から、セールスフォース社はサービスログイン時にMFAによる認証を必須とします。この背景には、上述のゼロトラストの思想より、ランサムウェアによる攻撃を防止することにあります。​インターネット上のサービスへの不正アクセスへの対策としてMFAが有効なのは、ゼロトラストの観点から、IDやパスワードでチェックするだけではなく、ユーザ個人が有するデバイスを活用して多面的に認証をかける点にあります。アクセス元のIPアドレスの制御に加えて、アクセスを試みたユーザが本人なのか、接続するたびにチェックをかけることによって、情報漏洩のリスクを軽減することが可能となります。​​

  • ユーザ管理の便利機能

    この記事で学べることユーザ管理に必要な基礎知識を学ぶことができますユーザの管理に使用できる便利な機能を知ることができます知っていますか?Salesforceのユーザを削除することはできませんSalesforceのシステム管理者様の業務で欠かすことができないのものの1つはユーザ管理だと思います。新入社員が入る、長期休暇を取得するユーザがいる、異動するユーザがいる等の様々なイベントに対して、システム管理者様はユーザを作成したり編集したりされていると思います。​さて、ここで質問です。「ユーザが退職するとき」どのように対応しますか?​答えは、「ユーザを無効化する」です。Salesforceのユーザは一旦登録をすると削除をすることはできません。ユーザには様々なデータが紐付いています。例えば、そのユーザが担当(所有していた)取引先や商談、活動、カスタムオブジェクト等があります。そのユーザが退職した後も、そのユーザが勤務していた時の状態でデータを残しておけるように、削除ではなく「無効化」ができるようになっています。そして、無効化をすることで、そのユーザが使用していたライセンスが開放され、他のユーザがライセンスを使用することができるようになります。​ですが、何らかのエラーが発生し、すぐにユーザを無効化できない場合があります。(もちろんあなたは、退職後のユーザにはSalesforceにログインしてほしくありません!)​こんな時に使えるのが「凍結」です。凍結をしておけば、あなたがエラーの原因を確認(必要に応じてサポートへ問い合わせを)している間、そのユーザがSalesforceにログインできないようにすることができます。​注意点:「無効化」と異なり、「凍結」をしてもユーザライセンスは開放されませんので、他のユーザにライセンスを使用することはできませんので、ご注意ください。知っていますか?ユーザにもリストビューを作ることができますSalesforceには、オブジェクト(取引先や商談)毎にデータの一覧を簡単に表示できるように「リストビュー」という機能があります。システム管理者のみなさまは、現場のユーザが業務で使用するリストビューを作成しているかと思いますが、そのリストビューを[ユーザ]オブジェクトに対しても作成することができます。​特にユーザ数が多い組織の場合、全ユーザの一覧画面をスクロールして対象ユーザを探すのは大変だと思います。あらかじめ部署毎、ロール毎、プロファイル毎などの条件でリストビューを作成しておくと管理しやすくなります。(リストビューの作成方法は、「Salesforce Classic でのカスタムリストビューの作成」(ヘルプ)をご覧ください)​知っていますか?プロファイルにもリストビューを作成することができますリストビューつながりで、もう一つ、ユーザのアクセス権管理の便利機能をご紹介します。​※「プロファイルって何だろう?ユーザとどういう関係が?」という方は、「ユーザを登録する」(サクセスナビ)「プロファイルと権限セットを使って、アクセス方法や権限を設定する」(サクセスナビ)をご覧ください​規模の大きな組織では、ユーザに割り当てるプロファイルの数も多くなります。「プロファイル毎にどういう権限が付いているのか見比べたい」「複数のプロファイルの権限を一括で変更したい」という場面もあるかと思います。そんな時におすすめなのが、「プロファイルのリストビュー」です。​※ もし、[編集 | 削除 | 新規ビューの作成]リンクが表示されていない場合は、[拡張プロファイルリストビュー]を有効にします。具体的な手順は、「拡張プロファイルリストビューを有効化」(ヘルプ) をご覧ください。​以下は、プロファイル毎に、取引先のオブジェクト権限の設定を表示するリストビューのサンプルです。(リストビューの作成手順は「プロファイルリストビューの作成と編集」(ヘルプ) をご覧ください)​他のオブジェクト(取引先や商談など)のリストビューと同様に、必要な項目(オブジェクト権限やユーザ権限)を追加して、リスト上でインライン編集したり、複数プロファイルの権限を一度に編集することができます。​また、「特定の権限が付与されているユーザは誰か?」というように権限を条件にユーザやプロファイル、権限セットを検索したい場面もあるかと思います。そんな時には、AppExchangeサイトで公開されている「Permission Helper」アプリケーションをぜひご活用ください。​以下は、[すべてのデータの編集]権限を持つユーザの一覧を表示していますが、特定のオブジェクト権限を持つユーザの一覧を表示することもできます。知っていますか?設定画面で、ユーザを直接検索できますここまで、リストビューを活用したユーザ管理についてご紹介してきましたが、設定画面でも、グローバル検索と同じようにユーザを検索することができます。一人のユーザのパスワードリセットを行う場合などは、リストビューを表示して特定ユーザを探すよりも検索をしたほうがスムーズです。​以下は「標準」の文字列で検索をしていますが、[ユーザ]だけでなく[項目名]なども検索することができます。(あいにく、[プロファイル名]を検索することはできません)注意点:画面左上の[クイック検索]はメニューを検索するものです。ユーザや項目を検索するときは、画面上部の虫眼鏡から検索してください。​学習ツールSalesforce Classic でのカスタムリストビューの作成(ヘルプ)プロファイルリストビューの作成と編集(ヘルプ)Permission Helper(AppExchange)ユーザ管理(Trailhead)まとめSalesforceではユーザを削除することはできません。代わりに[無効化]や[凍結]を行います。ユーザやプロファイルのリストビューを活用することで、スムーズにユーザ管理業務を行うことができます。

  • サンプルデータを削除しましょう

    この記事で学べることサンプル(トライアル)のデータを一括削除する方法を知ることができます“(Sample)“データを効率よく削除する方法Salesforceのトライアル組織には、以下のように“(Sample)”と記載された初期データ(サンプルデータ)が入っています。ご契約前であれば、サンプルデータを削除する機能をご利用いただけます。注意事項:[すべてのデータの一括削除]は、初期データだけでなく、お客様自身が作成したサンプルデータを含めて、組織のすべてのデータを削除します。[すべてのデータの一括削除]を使用して削除されたデータを復元することはできません。お客様自身が作成したサンプルデータは残しつつ、初期データのみ一括削除をしたい場合、もしくは既にご契約をされている場合は、[一括削除]機能を使用することができます。具体的な操作方法は、「新しい Salesforce 組織で事前にロードされたサンプルデータを削除する」(ナレッジ)の「オプション2」をご確認ください。​[一括削除]画面に表示されていないオブジェクトのデータを削除する場合は、データローダを利用します。データローダの操作方法は、「初めてのデータローダ 〜Delete編〜」(サクセスナビ)をご覧ください学習ツールトライアルデータの削除(ヘルプ)組織データのデフォルトへのリセット(ナレッジ)新しい Salesforce 組織で事前にロードされたサンプルデータを削除する(ナレッジ)まとめご契約前のお客様は、サンプルデータを一括削除することができます。ご契約後であったり、自動作成されたサンプルデータのみを削除する場合は、[一括削除]や[データローダ]を使用します。

  • テストのポイント

    この記事で学べること多要素認証 (MFA) のテストをする際のポイントを理解することができますMFA のテスト多要素認証のテストの推奨事項は製品毎に異なっております。​MFA 実装のテスト ​この記事では Salesforce Platform で構築された製品 (Sales Cloud や Service Cloud 等) におけるテストの推奨事項について紹介させて頂きます。その他の製品におけるテスト時の推奨事項は上記ヘルプ記事内の各製品毎のヘルプページへのリンクをご参照頂ければ幸いです。 Salesforce Platform で構築された製品 における MFA のテストテストに利用する環境検証に利用する環境ですが、本番環境で実施する前に Sandbox 環境、もし利用できる Sandbox 環境が無い場合には Developer Edition 組織をサインアップ頂き、そちらの環境でのテスト実施を推奨しております。テストに利用するユーザテストを実施する際には、テストを実施頂くシステム管理者のアカウントについては誤って自身がロックアウトされるのを防ぐため、システム管理者権限の無いテストユーザを作成頂き、テストユーザのアカウントを使用する事を推奨しております。テストで確認することテストで確認頂く事としてはテストユーザとしてログインし、選定頂いた検証方法*での登録フローの実施・完了検証方法登録後、Salesforce に正常にログイン頂けるかを確認エンドユーザーが検証用のデバイスを忘れた場合を想定して、管理者アカウントで仮のコードの発行仮のコードを利用してのログインの流れの確認といった点があげられます。​*Salesforce Authenticator、 3rd party の TOTP アプリケーション、セキュリティキー 等。学習ツールMFA 実装のテストMFA のテスト (Salesforce Platform で構築された製品)仮のコードによる ID の検証 まとめMFA のテストを実施する上ではまず本番環境ではなく、Sandbox や Developer Edition 組織でお試し頂く管理者ユーザがロックアウトされる事を防ぐため、テストユーザを作成しテストに使用するエンドユーザでの実施事項と管理者で実施しなければならない動作をテストでは検証するといった点がポイントとなる旨、紹介させて頂きました。MFA のテスト計画を立てる際の参考となれば幸いです。どうぞよろしくお願いいたします。

  • 体制とロールアウト戦略の検討ポイント

    この記事で学べること多要素認証導入 (MFA) に際しての体制とロールアウト戦略の検討ポイントを把握することができます ロールアウトの計画ロールアウトを成功させるにあたっては、下記の 3 点をプロジェクトの計画の条件に含める事が重要です。ロールアウト戦略変更管理サポートチームロールアウト戦略ロールアウトの戦略を考えていく上では、まずどのユーザに対して MFA を有効化していくかという点を考慮する必要があります。考慮する際には、ユーザが持つ権限が 1 つ考慮する上でのポイントとなります。例えば、“システム管理者権限”を持つユーザは全てのデータへのアクセスや、組織の設定自体も変更可能です。なので、まずはこのような強力な権限を持つユーザに対して優先して MFA を適用頂く事がセキュリティを担保する上で重要となります。​次に、一部のユーザグループから適用を進めるのか、それとも全ユーザに対して同時にロールアウトするのかを検討します。会社の規模等にもよりますが、例えば一部のシステム管理者権限のユーザでパイロットとして開始パイロット後、残りの管理者ユーザや権限が強いユーザで開始最後にその他の一般ユーザーに対して開始といったステップや、部署ごとにロールアウトするといった選択肢が考えられます。​また、ロールアウトのスケジュールを考えるにあたっては、自社内の競合する可能性があるプロジェクトの有無を確認し、同時での稼働開始を避けることもポイントとなります。ロールアウトのプランを計画する際に役に立つ推奨事項とガイドラインについては、下記のヘルプサイトの記事も併せてご参照下さい。​MFA 実装およびテスト計画の定義 変更管理次に変更の管理です。変更の管理の主な目的はエンドユーザーに対して MFA が導入される旨を伝え、実際のリリース日までに告知やトレーニングを通じて MFA の導入に関与してもらい、リリースに備えるという点になります。観点としては、ユーザにどう伝えるのか (コミュニケーションとマーケティング)ユーザをどうトレーニングするのか導入やリリース当日のサポート体制の検討はどうするのかといった事があげられます。サポートチーム3 点目はサポートの体制です。一度 MFA をエンドユーザにロールアウトされますと、例えば認証に使う携帯電話を家に忘れて来てしまった、セキュリティキーを紛失してしまった、といった事が発生する可能性が見込まれます。このような事態に備えて、ポリシーとプロセスを先んじて確立・周知しておくことが重要になります。​また導入にあたってサポートを実施される方に対して、設定やトラブルシューティング、またアクセスの復旧手順を整え、事前にトレーニングを施すことも重要です。​併せて、新しく会社に入社された方が最初から MFA を利用できるような運用(例:入社時の実施必須事項に追加する)も継続的な運用の観点から大切なポイントとなります。学習ツール管理者向け多要素認証クイックガイド多要素認証ロールアウトの計画MFA 実装のサポートの準備 まとめこの記事では、MFA のロールアウトにあたっては、​ロールアウト戦略変更管理サポートチームの 3 つの観点をプロジェクトの計画を立てる際に条件として含める事が重要である旨を紹介させて頂きました。お客様毎にロールアウトの戦略も変わってくるものと想定されます。上記の内容をご参照の上で、ロールアウトの戦略・体制作りの検討をお願い致します。

Salesforceについてもっと学ぶ

Salesforce活用に役立つメルマガ登録

システム管理者のみなさまにおすすめの活用ウェブセミナーや、Salesforceでビジネスを推進いただくために有益なコンテンツを毎月お届けします。

Follow us!

Twitter公式アカウント

Salesforce活用に役立つメルマガ登録(毎月配信)

  • 私は、個人情報保護基本方針プライバシーに関する声明個人情報利用についての通知に同意します。 特に、プライバシーに関する声明で定めるとおり、情報のホスティングと処理を目的として私の個人データをアメリカ合衆国を含む国外に転送することを許可します。詳細私は、海外では日本の法律と同等のデータ保護法が整備されていない可能性があることも理解しています。詳細はこちらでご確認ください

  • 私は、Salesforce の製品、サービス、イベントに関するマーケティング情報の受け取りを希望します。私は、当該マーケティング情報の受け取りを私がいつでも停止できることを理解しています。