Chatterフィードからのレコード承認機能の投稿テンプレート設定を試してみました。
承認申請をChatter上で行う機能がありますが、Chatter投稿時に表示したい項目を指定できる仕組みとなっています。
この機能を利用するにはChatter設定で有効化が必要です。
機能が有効化されている場合にのみ、承認プロセス設定の「ステップ 4. 通知テンプレートの選択」で投稿テンプレートを指定できます。
Chatter経由の承認についてはこちら。
↧
SFDC：Chatterフィードからのレコード承認機能の投稿テンプレート設定を試してみました
↧
SFDC：セキュリティアラートのゲストユーザの組織の共有設定と共有モデルの保護設定を試してみました
セキュリティアラートのゲストユーザの組織の共有設定と共有モデルの保護設定を試してみました。
「ゲストユーザの組織の共有設定と共有モデルの保護」はForce.comサイトのゲストユーザに影響がある設定です。
変更内容
外部組織の共有設定: この更新により、外部組織の共有設定が 2 つのカテゴリに分割されます。外部組織の共有設定は、外部ライセンスを使用するポータルまたはコミュニティにログインするユーザにのみ適用されるようになりました。新しいゲスト組織の共有設定は、ログインせずにポータルまたはコミュニティにアクセスするゲストユーザに適用されます。このセキュリティの更新は、新規および既存のゲストプロファイルのすべてのオブジェクトに非公開の組織の共有設定を適用します。
ゲストユーザ共有ルール: ゲストユーザ専用の共有ルールを作成して、ゲストユーザに CRM データに対する「参照のみ」アクセス権を付与します。
制限: ゲストユーザは公開グループまたはキューのメンバーになることはできなくなり、共有の直接設定および Apex による共有管理を使用できなくなります。
影響箇所
次のいずれかのシナリオに該当する組織は、Salesforce がこのセキュリティの更新を適用したときに影響を受ける可能性があります
データへのアクセス権をゲストユーザに付与するために、組織は外部組織の共有設定が公開に設定されていることが必要である。
組織に公開グループまたはキューに属するゲストユーザーがいる。
組織は共有の直接設定または Apex による共有管理を使用してゲストユーザにデータへのアクセス権を付与しています。
ざっくりいうと共有設定でサイトゲストユーザを公開グループに追加して権限を付与する方法が使えなくなるとのことです。
この機能を有効化するには共有設定の「[ゲストユーザのレコードアクセス権を保護」設定をONにします。
チェックをONにすると公開グループへゲストユーザを含めることができなくなります。また共有設定に「条件に基づくゲストユーザアクセス」の選択肢が追加されます。
例えばユーザオブジェクトの共有設定の場合はステップ3で共有対象として含めるユーザレコードの条件を指定します。ステップ4で共有先のゲストユーザを選択します。
ステップ5では付与するアクセス権限を指定できますが、参照のみしか選択できませんでした。
ちなみに今までの公開グループの場合は参照・更新のみが選択できました。
ゲストユーザへの権限設定はオブジェクトごとに設定内容が異なるのも注意が必要です。取引先オブジェクトの共有設定の場合で公開グループの場合は、契約/商談/ケースと関連オブジェクトの設定が可能でした。
ですが、条件に基づくゲストユーザアクセスの場合は「デフォルトの取引先、契約のアクセス権」の選択のみしかできません。
ステップ3で指定するのも「取引先」項目の条件指定となります。
「ゲストユーザの組織の共有設定と共有モデルの保護」では、公開グループが条件に指定できなくなるだけでなく、更新権限が付与できなくなったり、条件指定の方法が異なったりと変更が大きい感じでした。サイトゲストユーザを利用している場合は要チェックだと思います。
その他参考サイト
何か情報は無いかなと検索したところこちらが参考になるかもしれないと思いました。
ヘルプはこちら。
↧
↧
SFDC：セキュリティアラートのコミュニティおよびポータルが有効になっている組織のユーザレコードの特定の項目をブロックを試してみました
セキュリティアラートのコミュニティおよびポータルが有効になっている組織のユーザレコードの特定の項目をブロックを試してみました。ToDoの有効期限は1月6日だったのでもう自動適用されてる設定かもしれません。
セキュリティアラートのページでは作業手順が載っているだけで実際の設定は別ページで行います。変更内容の確認や設定後には完了ボタンをクリックするとどこまでチェックしたかを記録できる仕組みとなっています。
今回のセキュリティアラートはCommunity Cloudを利用している組織用です。利用していなければざっくり確認して適用してしまって大丈夫かなと思います。
設定の有効化は設定メニューにあるユーザ管理設定ページの「個人情報を非表示」の有効化が適用できます。
機能を有効化後にコミュニティユーザで検証して問題ないことを確認できたらアラートを確認でチェックをつけて完了です。
これで確認済みのログを残すことができます。
↧
SFDC：セキュリティアラートのセルフ登録およびユーザの作成での標準外部プロファイルの使用禁止を試してみました
セキュリティアラートのセルフ登録およびユーザの作成での標準外部プロファイルの使用禁止を試してみました。
こちらも期限を過ぎているのですでに自動適用されているかもしれません。またCommunity Cloudを運用していてセルフ登録の機能を利用している場合に関係する変更です。
確認すべき設定はコミュニティのワークスペースの設定ページのログイン&登録にある登録ページ設定です。標準プロファイルをつかっていないことを確認します。
もう一つはコミュニティ設定の「セルフ登録およびユーザ作成で標準外部プロファイルの使用を許可」のチェックをONにする必要があります。
この変更後にコミュニティユーザの利用に問題が起きなければ検証完了だと思います。
↧
SFDC：セキュリティアラートのゲストユーザプロファイルからの「すべてのユーザの参照」権限の削除を試してみました
セキュリティアラートのゲストユーザプロファイルからの「すべてのユーザの参照」権限の削除を試してみました。
プロファイルでシステム権限を付与している場合はやめましょうという感じの変更です。参照権限は共有設定等で管理できます。
ひとつはサイトのプロファイル設定です。サイト詳細ページの公開アクセス設定ボタンから権限設定できます。
もう一つはコミュニティのワークスペース設定の管理→詳細にある「ゲストユーザがこのコミュニティの他のメンバーを表示できるようにする」をONにすると権限付与が可能です。
変更適用後に支障がなければ検証完了です。
↧
↧
SFDC：セキュリティアラートのゲストユーザによって作成されたレコードのデフォルトの所有者への割り当てを試してみました
セキュリティアラートのゲストユーザによって作成されたレコードのデフォルトの所有者への割り当てを試してみました。
機能の適用はコミュニティ設定からとのことです。
「ゲストユーザによって作成された新規レコードをデフォルトの所有者に再割割り当て」にチェックをつければ良いのですが、そのラベルは見当たりませんでした。代わりにあったのは「Reassign new records created by guest users to the default owner」のチェック項目。これをONにすればいいと思います。
続いてコミュニティのワークスペース設定へ。管理→詳細のページでデフォルトの所有者を指定できます。
サイトのページにも一応用意されています。
こんな感じで指定可能です。
設定変更はこんな感じです。
↧
SFDC：セキュリティアラートのゲストユーザ向けのセキュアオブジェクト権限を試してみました
セキュリティアラートのゲストユーザ向けのセキュアオブジェクト権限を試してみました。
変更箇所はこんな感じ。影響範囲が大きい..？って思ったけど元々不特定多数の利用者として扱われるサイトゲストユーザが編集したり削除したりするようなオブジェクトでは無いかなと思います。
サイトゲストユーザに対してシステム管理者が、契約、注文、アンケートへの回答の各オブジェクトで「更新」、「削除」、「すべてのデータの編集」、「すべてのデータの参照」アクセスを割り当てられなくなります
修正箇所としてはゲストユーザのプロファイル編集です。
あとは動作確認とかです。
プロファイル設定で権限を修正後にゲストユーザで問題なく操作可能か確認できたらこのアラートへの対応は完了です。
↧
SFDC：セキュリティアラートのコミュニティニックネームのデフォルトでの有効化と新しいニックネーム生成アルゴリズムを試してみました
セキュリティアラートのコミュニティニックネームのデフォルトでの有効化と新しいニックネーム生成アルゴリズムを試してみました。
変更箇所はこちら。
[ニックネームを表示] 設定は、すべての新しいコミュニティでデフォルトで有効になります。Winter '20 より前に作成されたコミュニティは影響を受けません。
ニックネーム生成アルゴリズムが変更され、デフォルトのニックネームはユーザ名に基づかなくなります。
コミュニティユーザ作成時にニックネームが自動生成の文字列がセットされるそうです。ニックネームの値を条件に処理を開発している場合以外では既存の仕組みが動かなくなる変更ではないのでサクッと有効化しても大丈夫そうに思いました。
変更の反映はコミュニティのワークスペース設定からです。
下記のとおりにニックネームを表示のチェックONにすると姓と名の代わりにニックネームが表示されるようになります。
各コミュニティで [ワークスペース] > [管理] > [詳細] に移動し、そのコミュニティの [ニックネームを表示] 設定が適切に設定されていることを確認します。この設定が有効になっている場合、ユーザ名の代わりにニックネームが表示されます。
今まではユーザ名の値をベースにニックネームが生成されていましたが、今度からは自動生成された値がセットされることをユーザに通知します。初期値は自動生成値ですが、ログイン後に任意の値に更新するのは可能です。
ニックネームの生成方法の変更をコミュニティメンバーに通知するかどうかを決定します。メンバーに通知し、必要に応じてニックネームを変更できる方法を伝えることをお勧めします。ニックネーム項目がユーザプロファイルのページレイアウトにある場合、ユーザプロファイルページに移動して [編集] をクリックすると、デフォルトのニックネームを変更できます。
コミュニティ内に名前等を共有するのをユーザ側で管理できるようになる仕組みだと思います。コミュニティユーザのテストデータは準備していなかったので、詳細については未確認ですが、こんな感じでアラート対応完了します。
↧
SFDC：セキュリティアラートのSpring '20 リリースでの権限およびアクセス権の変更を確認を試してみました
セキュリティアラートのSpring '20 リリースでの権限およびアクセス権の変更を確認を試してみました。
・・・といっても設定変更等のアクションが必要というわけではなく、リリースノートなどで確認してねという内容でした。
Spring'20のリリースノートは下記リンクから確認できます。
↧
↧
SFDC：セキュリティアラートのユーザプロファイルに基づくゲストユーザとポータルユーザの @ AuraEnabled Apex メソッドへのアクセスの制限を試してみました
セキュリティアラートのユーザプロファイルに基づくゲストユーザとポータルユーザの @AuraEnabled Apex メソッドへのアクセスの制限を試してみました。
変更箇所はこちら。・・・長い。
現在のところ、ゲストユーザ、ポータルユーザ、またはコミュニティユーザには @AuraEnabled メソッドが含まれる Apex クラスにアクセスするための権限が必要ありません。 「デフォルトでセキュア」なアプローチに従い、ユーザのポータルで Apex クラスへのアクセスが許可されている場合のみゲストユーザ、ポータルユーザ、コミュニティユーザが @AuraEnabled Apex メソッドにアクセスできるように重要な更新を追加しました。
Summer '20 では、すべての組織で重要な更新を自動的に有効化します。 この重要な更新では Aura および Lightning Web コンポーネントによって使用される Apex クラスのユーザプロファイル制限が適用されます。ゲストユーザ、ポータルユーザ、コミュニティユーザが Apex クラスにアクセスするには、プロファイル内に権限または権限セットが必要です。この Apex クラスに含まれる @AuraEnabled メソッドをコールする Aura または Lightning Web コンポーネントは、正常に読み込むことができないまたは動作できない場合があります。
とりあえずLightning WebコンポーネントとAuraコンポーネントの開発している場合に影響があるみたいです。@AuraEnabled メソッドをコールするときの実装方法が変わるようです。
変更の適用は重要な更新の「ユーザプロファイルに基づくゲストユーザとポータルユーザの @AuraEnabled Apex メソッドへのアクセスの制限」から行います。
影響のあるApexクラスを抽出します。一覧抽出ツールのリンクも用意されていました。(他のセキュリティアラートでも同じリンクが用意されていましたが。)
リンク先はこちら。
ゲストユーザやコミュニティユーザに権限を付与して動作確認ができれば対応完了です。
Force.comサイトでLightningコンポーネントを使用している話はあまり聞かない気がしますが、Community Cloudではけっこう使われてる事例話を聞いたのでそうした組織では要チェックのアップデートだと思います。
↧
SFDC：セキュリティアラートのユーザプロファイルに基づく認証済みユーザの @ AuraEnabled Apex メソッドへのアクセスの制限を試してみました
セキュリティアラートのユーザプロファイルに基づく認証済みユーザの @AuraEnabled Apex メソッドへのアクセスの制限を試してみました。
変更箇所はこちら。
現在のところ、認証済みユーザには @AuraEnabled メソッドが含まれる Apex クラスにアクセスするための権限が必要ありません。 「デフォルトでセキュア」なアプローチに従い、ユーザのポータルで Apex クラスへのアクセスが許可されている場合のみ認証済みユーザが @AuraEnabled Apex メソッドにアクセスできるように重要な更新を追加しました。 Summer ‘20 では、すべての組織で重要な更新を自動的に有効化します。 この重要な更新では Aura および Lightning Web コンポーネントによって使用される Apex クラスのユーザプロファイル制限が適用されます。認証済みユーザが Apex クラスにアクセスするには、プロファイルの権限または権限セットが必要です。こうした Apex クラスに含まれる @AuraEnabled メソッドをコールする Aura または Lightning Web コンポーネントは読み込みに失敗する場合もあれば正常に動作する場合もあります。
下記のセキュリティアラートの社内ユーザ版と思います。
設定方法は重要な更新から。
有効化後に動作確認して問題なければ対応完了の流れです。
↧
SFDC：Spring'20の重要な更新を試してみました
Spring'20の重要な更新を試してみました。一部のセキュリティアラートでも重要な更新から有効化してくださいというものがありましたが、基本的には随時有効化して早めに対応しておくと良いと思います。
Spring'20で追加されたのは下記のとおりです。(一部前のバージョンのものも含まれているかもしれません。)
新しい Salesforce モバイルアプリケーションを有効化
モバイルアプリに新しいUIを適用する更新です。これは期限も過ぎていて自動適用されていると思います。
プロセスおよびフロー数式での null のレコード変数または参照関係項目の null 値の確認
プロセスビルダーとフローに影響がある更新です。基本的には既存の処理に影響はないと思います。(有効化前には要検証)
プロセスビルダーで元のレコード値に基づく条件を評価
プロセスビルダーに影響がある更新。場合によっては既存の処理に影響があるとのことです。
[レコードに指定の変更が行われた場合にのみアクションを実行しますか?] オプションが選択されているプロセスがある場合、または条件で ISCHANGED() 関数を使用する場合、この更新によってプロセスが異なって動作する可能性があります。
呼び出し可能なアクションの部分的な保存の有効化
ちょっとよくわからなかったのですが、バグの修正っぽいです。(たぶん影響受けたこと無い。)
呼び出し可能なアクション要求の部分的な保存機能は適切に動作しませんでした。トランザクション内の呼び出し可能なアクション要求の 1 つが失敗しても、そのトランザクション内の別の要求が正常に実行される可能性がありました。この 2 番目の呼び出し可能なアクション要求は期待どおりにロールバックされませんでした。
フローから呼び出された Apex クラスへのユーザアクセスを要求
フローを実装している場合に影響があります。・・・フローは使ってないので現時点では関係なかった。
フローでの従来の Apex アクションのアクセス修飾子の考慮
同じくフロー関係の更新です。
フロー数式でデータアクセス権を適用
フローの更新。
Lightning コンソールアプリケーションでタブがフォーカスされたダイアログを有効化
Lightnignコンソールに関する更新。操作性が向上するようなので有効化しておくと良さそうです。
暗黙的な共有のある @AuraEnabled Apex コントローラで with sharing を使用
これは過去に廃止された重要な更新をONにしている組織に影響があるものとのことです。ただ、通常はwith sharingを宣言していると思うので大きな影響は無いと思います。
・
・
・
確認してみたら結構ありました。後日追記します。
↧
SFDC：Spring'20のレポート新機能 - レポートプレビューの自動更新を試してみました
Spring'20のレポート新機能 - レポートプレビューの自動更新を試してみました。
レポートに自動的にプレビューを更新機能が追加されました。
追加されたというよりは、今までは変更時に自動でプレビューに反映されていましたが、自動反映のON/OFFが選択できるようになったという感じです。
OFFの場合は条件変更後に画面がグレーアウトされた状態となります。グレーアウト時には更新リンクが表示され、そちらをクリックするとプレビューに反映されます。
この機能のメリットとしてはレポートの条件カスタマイズの際にプレビュー反映の待ち時間が発生しないのでサクサクと作業を進められるようになります。
↧
↧
SFDC：Spring'20のレポート新機能 - 項目間の検索条件を使用した項目の比較によるレポートの絞り込みを試してみました
Spring'20のレポート新機能 - 項目間の検索条件を使用した項目の比較によるレポートの絞り込みを試してみました。
レポートの条件指定で項目間の比較が可能になりました。例えば金額項目と期待収益項目の値を比較して条件に一致する商談を抽出するといった使い方ができたりします。
数値や金額以外にも日付型の判定が可能でした。作成日や最終更新日との比較もできたのでいろいろ使い方がありそうです。
すべてのデータ型で項目間の比較ができるわけではないみたいで、テキスト型や選択リスト型は利用不可でした。
↧
SFDC： Spring'20のレポート新機能 - レポート結果での値のユニーク数を試してみました
Spring'20のレポート新機能 - レポート結果での値のユニーク数を試してみました。
レポートの項目メニューのところにユニークカウントを表示を選択できるようになっています。
このような感じで列のユニークな値の件数を集計できます。
何種類の値があるかをチェックするのに便利そうです。
↧
SFDC：Spring'20のレポート新機能 - その他の新機能について
Spring'20のレポート新機能 - その他についてです。
下記の機能が追加されているみたいです。
- フォーマット済みレポートのエクスポートからの社外秘情報免責事項の除外
- 右から左へ記述される言語でのレポートおよびダッシュボードの操作 (正式リリース)
必要になったときに便利だと思います。
↧
SFDC：Spring'20の新アプリケーションランチャーを試してみました
Spring'20の新アプリケーションランチャーを試してみました。
今までは大きめのポップアップでアプリケーション一覧とタブ一覧が表示されていましたが、Spring'20の更新で小さめのポップアップにアプリケーションのみが表示されるようになりました。
この変更により、アプリケーションランチャーの表示が短縮された気がします。また、便利な点として検索ボックスでアプリケーションとタブを両方検索できる仕組みがあります。
すべて表示のリンクをクリックすると今までのポップアップも表示できます。
アプリケーションランチャーの本来の目的だったアプリケーション切り替え機能に特化したアップデートかなと思います。個人的にはタブ検索機能が使いやすくて助かりました。
↧
↧
SFDC：Lightningメールの旧字体漢字の文字化けとユーザ設定の文字エンコードについて
Lightningメールの旧字体漢字の文字化けとユーザ設定の文字エンコードについてです。
ユーザ名に旧字体の漢字が含まれている場合、Lightningメールで正しく表示されない場合があります。
例: 「祥」という文字の旧字体「祥」(サンプル探してたらちょうど良く紹介されていたので)
Macのメーラー
Gmail
上記のように「？」表示されます。ちなみにSalesforce上は正しく表示されます。
旧字体の表示はユーザのメールの文字コード項目にUTF-8を指定することで解決できると思います。
変更後はこんな感じ。
Macメーラー
Gmail
旧字体の漢字を含むメールを送付する際に文字化けで困ったら試してみると良いと思います。
↧
SFDC：Spring'20のChatter新機能 - ケースフィード項目の日時スタンプの形式の設定を試してみました
Spring'20のChatter新機能 - ケースフィード項目の日時スタンプの形式の設定を試してみました。
この機能はChatter設定のページで有効化することで利用できます。チェックオンで今までの相対表示です。オフにすることで新しくできるようになった絶対表示が可能になるんだと思います。
・・・この機能便利かもと思ったのですが、チェックオンでもオフでも相対表示されていてどこに変更があったのかわかりませんでした。
↓チェック・オフにしてもオンにしても1分前という風に表示される。
時刻リンクをクリックして詳細ページに表示してマウスを当てると一応絶対時刻が表示されました。
マウスを当てての表示のことを指しているとすればここまでしてチェックする人はいない気はします。。(チェックオンでもオフでも挙動は変わらなかったのでここじゃない可能性もありますが..)
ケースフィード項目の日時スタンプの形式の設定を試してみましたが、ちょっと良くわかりませんでした。
↧
SFDC：Spring'20のごみ箱新機能を試してみました
Spring'20のごみ箱新機能を試してみました。
チェックボックスをつかった複数レコードの一括削除が可能になっています。
またWinter'20ではアクセスできなかったレポートとダッシュボードもサポートされたみたいです。
ちょっと便利になっていました。
↧