広島で(1)AI活用講座（経営者様向け、社内推進者様向け、活用基礎等）、(2)クラウドサービス（AWS・Azure・GCP）の提供、(3)Webシステム・スマホアプリ開発をおこなう、オプトプランニングのブログです。
あけましておめでとうございます。
本年もどうぞよろしくお願いいたします！
社内 野の花画伯から、新年の絵が届きました。
万年青（おもと）です。
花言葉は「長寿」、「長命」が代表的です。
理由は、一年中葉が緑で、冬も枯れず、何十年も育つのでこの花言葉がついたそうですよ！
昔から非常に縁起が良いものとされていますね。
邪気を払い、運気が開けるとも言われています。
お祝いのシチュエーションでは、「お祝い万年青」としても重宝されます。
開院、開業、結婚、お正月などの慶事に良く飾られています。
お正月に赤い実がなり、葉である母が子である実を守るように育つため、
母性の愛など崇高な精神と子孫繁栄も象徴されます。
徳川家康が江戸城に入る時、3鉢の万年青を贈られたという話も有名ですね！
その後、徳川家は300年も栄えたことから、大変縁起が良いとされています。
こんにちは！株式会社オプトプランニングです。
Salesforce（Salesforce.com／セールスフォース・ドットコム、略してSFDC）であれこれやってみたことを書いていきます。
レポートを作成していると「過去の月ごとの商談件数が知りたい」や「月ごと・週ごとの金額の合計がわかればいいな」など、データを期間ごとに集計したい場面は多いと思います。
そんな時に使うのが、「期間集計」です。
これは、データ型が「日付」「日付/時間」項目の場合、簡単な設定で任意の期間で集計をすることができるものです。
今回はLightning Experienceでの期間集計の方法や、やってみて分かったこと、他の方法などを書いていきたいと思います。
※2023/1/30 訂正・追記あり
早速、期間集計をやってみようと思います！
今回使用するレポートは、以前のブログでも使用したTrailheadのモジュールをダウンロードした時に入っていた図１のレポートです。
（どのモジュールだったかは前回から思い出せておりませんのであしからず）
まずは、右上の「編集」をクリックしてレポートの編集画面を表示させます。
今回は、レポート内にある「完了予定日」を期間集計してみたいと思います。
日付項目を期間集計するには、対象の項目がグループ化された行または列に存在する必要があります。
列にある項目「完了予定日」を期間集計しようとしてみても、以下のように期間集計できる項目が出てきません。
そこで、「完了予定日」を行グループに移動して期間集計しようとすると…
「集計期間単位」という項目が出てきました！
期間集計は、この「集計期間単位」で任意の単位を選択することで設定します。
今回は「年月」で集計しようと思うので単位に「年月」を選択します。
（図３のようにデフォルトでは「日付」が選択されていますが「年月」をクリックすると選択できます）
すると、日にちまで表示されていた「完了予定日」が年月のみの表示に変わりました！
編集時は表示されるデータが少ないため、期間集計で何が変化するのかわかりにくいですが、期間集計する前後のレポートを見比べてみると以下のようになります。
左図が「完了予定日」を期間集計する前、右図が「完了予定日」を期間集計した後です。
（わかりやすくするため、基準とグラフ種類を変更しています。）
期間集計前は日ごとに集計されていたのが、「年月」で期間集計したことで月ごとに集計されるようになりました。
オブジェクトの項目を増やしたりすることなくこのような集計が行えるのはとても便利ですね！
期間集計を行う場合、対象の項目がグループ化されていなければなりません。
期間集計が表示されない場合は、対象の項目をグループ化しているかどうか確認してみましょう。
あくまで「集計」機能なので、データの表示形式を変更するためのものではないということを念頭に入れておきましょう。
また、期間集計を行う項目はグループ化しなければならないため、表形式のレポートでは使用できません。
期間集計を行った項目は、期間集計で選択した単位でしか表示されなくなります。
今回やってみた期間集計を例にすると、「完了予定日」を「年月」で期間集計したレポートは、完了予定日の年月だけ表示され、完了予定日の日付は表示されません。
集計は「年月」で行いたいけど、日付や時間などの表示もレポートに表示したいのに…という時は気をつけたい部分です。
データ内容は変わらないので、表示されていない情報（例で言えば「完了予定日」の日付）はレコードを参照すればいいのですが、いちいちレコードを参照するのも面倒に感じてしまいます。
期間集計を行う項目は、期間集計後の表示でいいかの判断が必要かもしれません。
エクスポートをしてみると期間集計を行った項目に関して影響が出る場合があります。
「フォーマット済みレポート」の場合、期間集計を行う前後でエクスポートされるデータ内容が変わります。
先ほどの期間集計した前後のレポートをエクスポートして比較すると以下のようになります。
「フォーマット済みレポート」でエクスポートした時、期間集計した項目はレポートで表示された内容のままエクスポートされます。
期間集計を「年月」で行ったレポートをエクスポートすると、エクスポートしたファイルでは「完了予定日」の日付は分からなくなってしまいます。
「詳細のみ」でエクスポートした場合は、期間集計を行う前後でデータ内容は変わりません。
期間集計する前後のレポートをエクスポートした比較は以下です。
「詳細のみ」でエクスポートした時、期間集計した項目はレコードデータに基づいた内容でエクスポートされます。
期間集計を「年月」で行ったレポートでも、エクスポートしたファイルから「完了予定日」の日付がわかります。
年月などの期間集計はやりたいけど、対象項目の表示形式はそのままにしておきたいという場合もあると思います。
また、エクスポートの結果からレポートの期間集計は使いにくいということもあるでしょう。
そんな時に私が思いついたのは、期間集計を行いたい項目を利用して「行レベルの数式」を作成し、その数式を集計項目に利用する方法です。
行レベルの数式もレポート編集画面から簡単に作成できます。
レポート編集画面を開いたら「列」の右にある「▼」をクリックすると「行レベルの数式を追加」があるのでクリックします。
「行レベルの数式列を編集」画面が開くので、以下のように設定します。
「列の名前」はレポートに表示される項目名になるので、必要があれば「説明」に数式の内容を書いておくといいと思います。
| 列の名前 | 完了予定年月 |
| 数式出力種別 | テキスト |
| 数式 | MID(TEXT(CLOSE_DATE),1,4) & ‘年’ & MID(TEXT(CLOSE_DATE),6,2) & ‘月’ |
この数式は「完了予定日」の年月部分だけをテキスト形式で表示させるものになります。
※2023/1/30数式訂正。詳細は追記を参照
適用をクリックすると行レベルの数式が作成されているので、作成した数式でグルーピングを行います。
同時に、期間集計に使用していた「完了予定日」は列の方に戻してみます。
すると、「完了予定日」の「年月」で集計しつつ、「完了予定日」の内容をレポート上に表示できるようになりました！！
行レベルの数式があるレポートを「詳細のみ」でエクスポートしてみるとどうなるか試してみました。
すると…
行レベルの数式も項目としてデータをエクスポートできることが分かりました！！！
これだと、エクスポート後のデータの活用に幅が広がるかもしれませんね～
期間集計ですが、実務の方ではLightning Experienceでの期間集計方法がわからず、苦肉の策として編み出したのが行レベルの数式を作成して集計をしてみることでした。
行レベルの数式を作成した後に期間集計の方法が分かったのですが、期間集計した項目の表示だと私が作成したいレポートでは表示内容が不十分なことが多く、そのまま行レベルの数式で集計を行うレポートもありました。
今回書くにあたって、エクスポートについてもいろいろ試してみてより理解が深まったので、この気づきを生かして利用者が使いやすいレポート作成を心掛けていきたいと思います！
それでは、またお会いしましょう！！
2023/1/30、完了月が正しく並び替えできないという問題があるため数式を訂正しました。（初歩的なミスですみません）
当初の数式【 TEXT(YEAR(CLOSE_DATE)) & ‘年’ & TEXT(MONTH(CLOSE_DATE)) & ‘月’) 】と訂正後の数式【 MID(TEXT(CLOSE_DATE),1,4) & ‘年’ & MID(TEXT(CLOSE_DATE),6,2) & ‘月’ 】の「完了予定年月」の表示を忘備録として載せておきます。
訂正後の「完了予定年月」は正しく並び替えできています。
今回、参考にした数式は公式ヘルプに紹介されていました。
$curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o "awscliv2.zip"
$unzip awscliv2.zip
$sudo ./aws/insstall --update
$aws --version
aws-cli/2.9.10 Python/3.9.11 Linux/5.10.157-139.675.amzn2.x86_64 exe/x86_64.amzn.2 prompt/off
2022/12/27 時点で最新バージョンです 詳しくは、以下を参照 AWS CLI 最新バージョンをインストールまたは更新する
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html
InternetGWの情報を必要な項目のみ出力してみよう
$aws ec2 describe-internet-gateways \
--query "InternetGateways[].[{VPC_id:Attachments[0].VpcId,Name:Tags[0].Value}]" --out table
AWSが保持しているグルーバルアドレスのCIDRが公開されています。(json形式）その内容から東京リージョンのIPレンジのみを出力します。
$curl https://ip-ranges.amazonaws.com/ip-ranges.json | \
jq -r '.prefixes[] | select(.region=="ap-northeast-1") | .ip_prefix'
curl コマンドでjsonファイルを取ってきます。 jp コマンドでリストになっているprefix[]からreginがap-northeast-1(東京)のもので、ip_prefix項目のみ出力させます
jq コマンドは以下でインストールしてみてください
$sudo yum install jq
東京リージョンでEC2のIPレンジのみを出力します。
$curl https://ip-ranges.amazonaws.com/ip-ranges.json | \
jq -r '.prefixes[] | select(.service=="EC2" and .region=="ap-northeast-1") | .ip
_prefix'
curlコマンドでjsonファイルを取ってきます。jpコマンドでリストになっているprefix[]からreginがap-northeast-1(東京)かつ serviceがEC2のip_prefixのみを出力させます
HealthイベントをEventBridge経由で監視するイベントルールの対象を特定のサービスとする場合に、対象のサービス名は、”A2I”、”SSM”と選択可能である、これがなんのサービスかわかりたい
$aws health describe-event-types
Health イベントで使用されるサービス名の一覧は、aws health describe-event-types コマンドで出力できます。json形式で出力されます。沢山出力されるのである程度絞り込みを行います。
$aws health describe-event-types | \
jq -r '.eventTypes[] | select(.service=="SSM" or .service=="A2I") | .code'
Health イベントで使用されるサービス名の一覧は、aws health describe-event-types コマンドで出力できます。これでは、沢山出力されるので、対象を絞ります。 jqコマンドのselectを利用して SSMとA2Iに絞ります。そして、codeの部分のみを出力します。A2IはAmazon Augmented AI(AmazonA2I)のことだそうです。「A2I aws」で検索するとヒットします。
Windows-serverのAMIはどのような物があるか、質問が良くあります。AWS CLIコマンドを使って出力できます。(Windows-server2019の例です）
$aws ec2 describe-images \
--owners amazon \
--filters "Name=name,Values=Windows_Server-2019-*" \
--query "sort_by(Images,&Name)[].[Name,ImageId]" \
--out table
imageは、aws ec2 describe-imageコマンドで出力します。filterオプションで windows_Server-2019-*のみを対象にします。更に、queryで ImagesNameとImageIdをsortして出力します。
publicサブネットかどうかは、routeテーブルを見ないとわかりません。ルートテーブルの(0.0.0.0/0)があるかどうかで判断できます。
$aws ec2 describe-route-tables \
--query "RouteTables[].{Sub:Associations[].SubnetId,Id:RouteTableId,rou:join('<->',Routes[].DestinationCidrBlock),INgw:Routes[].GatewayId}"\
--out text
routeテーブルを出力します。queryで出力項目を絞り込みます。Associations[].SubnetIdとRouteTableId,join(‘<->’)で文字列を加え、Routes[].DestinationCidrBlock,Routes[].GatewayIdを出力します。<->0.0.0.0/0があるサブネットがpublicサブネットです。
Linux版その１ EC2の情報出力 https://opt-p.co.jp/blog/aws/post-1633/
Linux版その２ RDSの情報出力 https://opt-p.co.jp/blog/aws/post-1718/
Linux版その３ VPCの情報出力 https://opt-p.co.jp/blog/aws/post-2080/
Salesforceでバッチ処理を作成する方法としてはフロー処理の中の「スケジュールトリガーフロー」を使ってフロー処理として記述することが可能ですが、フローを動作させる頻度が「１回のみ、毎日、毎週」しかなく、1時間ごとに動作させるような設定ができません。
今回は、10分ごとに処理を行うための実装をApexを使って行います。
スケジュールの開始はスケジュールクラスを継承したクラスで実施し、この中からバッチクラスを呼び出し、バッチを実行します。
バッチクラスを実装するためにはバッチクラスをインプリメントする必要があります。
public class xxxxBatch implements Database.Batchable<sObject>,Database.Stateful { ....
また以下のメソッドを実装する必要があります。
/* バッチ処理開始時に最初に呼び出される。バッチ処理対象となるレコードを返却するQueryLocatorを返す。*/
public Database.QueryLocator start(Database.BatchableContext bc) {
処理
return Database.getQueryLocator(xxxxx);
}
/* バッチサイズで指定されたレコード数の単位で、呼び出される。*/
public void execute(Database.BatchableContext bc,List<sObject> executeRecords) {
処理
}
/* バッチ処理の終了時に呼び出される。終了処理があれば実装する */
public void finish(Database.BatchableContext bc) {
処理
}
それぞれのメソッドの記述内容は以下の様になります。
startメソッドでは、DBの情報を取得するためのQueryを作成しそれを返却します。
public Database.QueryLocator start(Database.BachableContext bc) {
string query = 'select XXXX from YYYY'; return Database.getQuery(query);
} startメソッドの終了後、executeメソッドが呼び出されます。その際startの返却値であるQueryが実行され、その結果がexecuteメソッドの第二引数に渡され、executeメソッドが呼び出されます。
executeメソッドでは主たる処理を記述します。
public void execute(Database.BatchableContext bc,List(sObject> executeRecords) {
......
for(hoge xx : executeRecords) {
.........
}
.......
} executeメソッドに引き渡されたQeryの実行結果を順に取り出して処理を実施します。
executeメソッドでExceptionが発生した場合、このトランザクションで実行されたものがロールバックされてしまいます。そのため、この処理の中でメール送信などを行っている場合にはメールを送信する処理もトランザクションの一部となるためメールが送信されないことになります。
そのためtry～catch()を使用してExceptionを捕まえて処理することが必要となります。
最後にfinishメソッドが実行されます。今回はこのfinishメソッド中で次のスケジュールを設定します。
public void finish(Database.BatchableContext bc) {
DateTime nextSchedTime = DateTime.now().addMinutes(10);
xxxxBatchSchedule cls = new xxxxBactchSchedule();
String nextJobName = 'xxxBatchSchedule_'+nextSchedTime.format('yyyyNNddHHmm');
String schd = nextSchedTime.format('0 m H d M ? yyyy');
System.schedule(nextJobName,schd,cls);
}スケジュール設定について簡単な説明を以下に記載します。
DateTime nextSchedTime = DateTime.now().addMinutes(10);
次にバッチを起動する時間を設定しています。10分毎にバッチ処理を実施するため、現在時間にaddMinutes()メソッドをつかって10分を加算し、次にバッチ処理を起動する時間を算出しています。
xxxxBatchSchedule cls = new xxxxBactchSchedule();
次節で説明するスケジューラクラスをインスタンス化しています。
String nextJobName = 'xxxBatchSchedule_'+nextSchedTime.format('yyyyNNddHHmm');
String schd = nextSchedTime.format('0 m H d M ? yyyy');System.scheduleメソッドに渡すための、スケジュール名と、スケジュール設定する時間を作成しています。スケジュール名は一意でないといけないので、スケジュール時間を付加しています。
System.schedule(nextJobName,schd,cls);
スケジュール設定を行っています。
スケジュールクラスでは、Schedulableをimprementします。またスケジュール済のパスが同時に処理できるレコードの数を指定します。デフォルトおよび最大値は200となっています。
バッチサイズについては分単位、バッチ処理、および制限の強化によるスケジュール済みパスのパワーアップを参照してください。
public class xxxxBactchSchedule imprements Schedulable{
private final Intefer BATCH_SIZE = 100;
public xxxxBatchSchedule() {
}
public void execute(SchedulableContext sc) {
xxxxBatch bt = new xxxxBatch();
Database.executeBatch(bt,BATCH_SIZE);
}
} Schedulableクラスのinprementsではexecuteメソッドを実装する必要があります。このexecuteメソッドはglobalまたはpublicで宣言する必要があります。
executeメソッドの中でインスタンス化されているのは前節で定義したバッチクラスです。
作成したスケジューラを起動するために、Apexスケジューラを設定します。
(1)Apexをスケジュール
1.ホームタブをクリックし、検索窓からApexを検索します。
2.検索結果のカスタムコードのApexクラスをクリックします。
3.「Apexをスケジュール」をクリックする
(2)スケジュールを設定
1.ジョブ名：スケジュールジョブ名を設定
2.Apexクラス：上記で作成したスケジュールクラス(xxxxBatchSchedule)を指定
3.頻度、開始日時、終了日時、希望開始時刻を設定する
注意事項
1.頻度は、「毎週」または「毎月」しか選択できません。終了日までは指定した頻度でスケジュールが実行されます。上記のスケジュールクラスで設定した時刻とは異なるタイミングでバッチが起動される場合があります。そのため、スケジュールが重複設定されないように、頻度、終了日の設定を行う必要があります。
2.ジョブキューの状況によっては、指定した日時時刻でのジョブ起動がされない場合があります。
バッチクラス(xxxxBatch)で設定したスケジュールは、「設定」→「スケジュール済みジョブ」で確認することができます。
アクションに「Manage」と表示されている場合、これをクリックすると起点となったスケジュールの詳細を見ることができます。
スケジュールを停止する場合には最新のスケジュールの削除アクションをクリックしてスケジュールを削除する必要があります。あわせて、起点となったスケジュールが定期的に実行されるように設定されているためこれも削除する必要があります。
SFDCのスケジュールに関してはApex スケジューラを参照してください。
こんにちは！株式会社オプトプランニングです。
久しぶりに「日々のあれこれ」コーナーを更新します。
最近、社内に増えつつあるサボテンの1つが本日開花しました！
これは、白星と言います。
サボテン科 マミラリア属のサボテンです。
朝はつぼみでしたが、日中の気温が上がり、、
お昼の社内清掃の時には開花していました！
こちらの魅力は、何といっても痛くない棘です。
ふわふわのタンポポの綿毛のような、柔らかい羽毛のような
「もふもふ」でぎっしりと覆われています。
小動物を触っている感じで癒されますよ。。
白い花が咲く品種もあるそうですが、この株は薄いピンク色でした！
比較的育てやすいそうですが、冬場の根腐れには注意とのことです。
お世話係、気を付けてまいります！
こんにちは！株式会社オプトプランニングです。
Salesforce（Salesforce.com／セールスフォース・ドットコム、略してSFDC）での気づきを書いていきます。
今回はデータローダ（dataloader）について、インストール後にデータローダの起動ができず困った体験とその解決法をちょっとした気づきとして書いていきます。
私の場合、公式に従いインストール完了後、ホームに作成されたデータローダのアイコンをダブルクリックしても、コマンドプロンプトが一瞬立ち上がりすぐに強制終了するため、データローダは起動しない・エラー内容も見れない、という状態でした。。。
データローダはSalesforceからインストールできます。
方法は公式ヘルプに動画付きで詳しく説明されているので以下をご覧ください。
データローダのインストール手順
データローダの再インストール、OpenJDKのインストールのやり直し（Azul Zulu以外のインストール含む）、PATHの設定確認、JAVA_HOMEの設定変更etc…
何をやってもデータローダが起動しない時は、forcedotcom/dataloader: Salesforce Data Loader – GitHubでインストールしたデータローダが最新かどうか確認してみてください。
上記リンク先では、図１のように最新のデータローダのバージョンが確認できます。
私の場合、何を試しても上手く行かず、途方に暮れていた時にこちらを発見しました。
（今回は割愛しますが、コマンドプロンプトが強制終了しないようにプログラムを書き換えて、エラー内容を確認しつつ冒頭の設定の見直しなど行いましたが解消できず…）
バージョンの確認をしたところ、Salesforceの設定からダウンロードしたものよりも新しいバージョンのものが配布されており、ダメ元で既にインストールした旧バージョンを全て削除・アンインストールの上、最新版をインストールしたところ普通に起動しました…
手順通りにやっているはずなのに上手く行かないとお困りの方の助けになれば幸いです。
このブログを書いていて気づいたのですが、データローダのダウンロード画面が変わったようです。（2022年10月31日現在）
しかし、新しい画面でもデータローダをダウンロードする時に気づかずに旧バージョンを選択する可能性があるかもしれません。
Salesforceの設定からデータローダのダウンロードをしようとすると図２から図３のようなサイトに遷移します。（2022年10月31日現在）
ダウンロードの選択は２つあり（赤枠部分）、左が最新バージョンです。
Windows版、MacOS版の選択はダウンロードボタンの上部にあるそれぞれのアイコンで選択します。
図３をよく見ると、選択されていないMacOS版の方はグレーアウトしているのが分かると思います。
（私の場合、デフォルトではWindows版が選択されていました）
ここで赤枠右側のダウンロードボタンを選択すると旧バージョンのダウンロードが行われてしまいます。
内容を確認せずに、なんとなく左がMacOS版、右がWindows版と思いこんで右側をクリックしてたりするかもしれませんね…
今回紹介したforcedotcom/dataloader: Salesforce Data Loader – GitHubは、既にデータローダを使用していて最新版を再インストールしたい方々の参考にもなるかと思います。
また、どうしても旧バージョンをインストールしたい場合はforcedotcom/dataloader: Salesforce Data Loader – GitHubからしかインストールすることができないようです。
Salesforceの設定から行うデータローダのダウンロードですが、2022年9月に行った際は公式の動画のようにリンクではなく直接ダウンロードだったと思います。
直近のリリースで変更されたのかもしれませんね！
今回は実際に困ったので起動エラーについて書きましたが、近いうちにデータローダの使い方も紹介していければと思います。
それでは、またお会いしましょう！！
こんにちは！株式会社オプトプランニングです。
Salesforce（Salesforce.com／セールスフォース・ドットコム、略してSFDC）であれこれやってみたことを書いていきます。
今回はLightning Experienceでのレポートのドリルダウン（ドリルイン）機能についてあれこれやってみたことを書いていきます。
レポートのドリルダウンについては公式ヘルプにやり方が載っていますので、そちらを確認してください。
こんなやり方もあります。
（2022年9月時点、公式ヘルプを探しても見つかりませんでしたので、非公式と名付けます。）
それは、グラフからドリルダウンする方法です。
ちなみに、SFDCのレポートでグラフを表示できるのは
のレポートですので、表形式のレポートは公式の方法同様、対象外となるのでご了承ください。
グラフからドリルダウンする方法は２つあります。
１つ目は、表示されているグラフから直接行う方法です。
グラフの種類がドーナツの場合、下図のような赤枠で囲んだ部分を使用します。
グラフのうち、ドリルダウンしたい色の部分をクリックします。
今回は、フェーズの中から一番多い水色部分の「Closed Won」にあたる部分をクリックしてみます。
すると、以下のようになります。
Closed Wonでドリルインできたことが表からも確認できます。
編集しているわけではないので、もう一度水色部分をクリックしたり、レポートを表示し直すとドリルダウンは解除されます。
２つ目は、グラフの凡例から行う方法です。
赤枠部分に凡例が表示されていますが、こちらを使用します。
（凡例は表示させる位置を変更できるので、必ずこの位置にあるとは限りません）
凡例からドリルダウンする場合も、グラフからの時と同様にドリルダウンしたい凡例をクリックします。
今回は一番下にある「その他」をクリックしてみます。
すると、以下のようになります。
グラフから行った時と同様にドリルインできました。
公式のドリルダウン方法とグラフからのドリルダウン方法それぞれでエクスポートを行ってみるとどうなるかやってみましたが、どちらも同じ内容をエクスポートすることができました。
（エクスポートはどちらも「フォーマット済みレポート」を「Excel形式(.xlsx)」で行いました）
どちらも同じ内容ですが、参考までにエクスポート結果を載せておきます。
左が公式のドリルダウン方法でエクスポートを行った場合、右がグラフからのドリルダウン方法で行った場合です。
どちらも「グラフからのドリルダウン１」で行った「Closed Won」でドリルダウンを行い、エクスポートしています。
検索条件の内容を見てみると、どちらも同じ内容になっていることが確認できます。
これにより、グラフからのドリルダウンも全く同じ絞り込みが行えていることがわかりました。
公式に載っていませんが、もしかするとレポートを頻繁に見る機会のある方は感覚的・直観的に使っている機能かもしれません。
グラフからドリルダウンを行う場合、メリットとしてはレポートの再表示を行わなくてもドリルダウン前のレポートに戻せる点です。
デメリットとしては、グラフからドリルダウンする場合は複数の項目値を選択することができない点です。
複数の値でドリルダウンを行いたい場合は公式のやり方で行ってください。
今回、説明のために使用したレポートは、Trailheadで勉強した時にインストールしたものに付属していた商談レポートです。
（どのハンズオンChallengeでインストールしたパッケージだったか忘れてしまいました…）
Trailheadを利用したことがある方は、同じレポートがあるかもしれないので、ご自身のハンズオン組織で確認することができると思います。
（もちろん、同じレポートでなくても確認できますよ！）
それでは、またお会いしましょう！！
こんにちは、株式会社オプトプランニングです。
先日、きょうかいけんぽ広島支部様より、
令和4年度のヘルスケア通信簿 速報版が届きました！
まだ、速報値の段階ではありますが、当社が取り組んでいる
健康経営の結果が現れています。
例えば、
○従業員1人あたりの年間平均医療費が下がっている
○従業員の受診率は現段階で90.0％を超えている
○特定保健指導実施率は、なんと100％！
この調子で、年度末まで行きますよ！
「健康づくりの好循環」をさらに拡大させていきたいと思います。
こんにちは！株式会社オプトプランニングです。
Salesforce（Salesforce.com／セールスフォース・ドットコム、略してSFDC）で気づいたことを書いていきます。
今回は、たまたまデータ型が数式のカスタム項目を削除した後に復元しなければいけないことがあり、初めて遭遇した画面だったので書いてみます。
実は、以前書いた削除後のデータについての気づきで数式項目を復元したことはあります。
その時は、「復元できるかどうか」しか着目していなかったため、今回の内容に気づけませんでした…
数式項目を削除した後に復元し、オブジェクトマネージャから対象の項目の詳細情報を確認してみると、数式オプション部分に以下のような文面が表示されます。
この数式は、項目が削除されたときに無効になりました。もう一度有効にするには、編集して保存してください。
復元した数式項目を有効にするには、数式オプションに書かれているように「編集して保存」するひと手間が必要になります。
やり方はいたって簡単。
文面通り「編集」ボタンを押して「保存」するだけです。
編集画面を開いても特にエラーは出ず、何かする必要もありませんので「保存」をクリックします。
（もちろん、何か編集しても構いません）
保存後は項目詳細画面に戻ります。
数式オプションを見てみると先ほどの文面が消えているのが確認できます。
これで有効化の完了です！！
項目を削除する時の表示内容について、削除後のデータについての気づきではどんな画面が表示されるか載せただけだったので、内容について見ておきたいと思います。
この表示は数式項目だけでなく、どのデータ型のカスタム項目を削除しても表示される内容です。
まずは、削除する際の内容です。
項目を削除しようとすると、このようなポップアップが出ます。
連動項目や制御項目、割り当てルールやエスカレーションルールに削除予定の項目が使用されていないか把握しておく必要があることが分かります。
次に、項目の復元時に表示される内容です。
削除時と同様、どのデータ型のカスタム項目を復元しても表示されます。
実は、ここに数式について言及があります！！
また、手動で変更を戻す必要があることも記載があります。
他にも、
などがありますので、注意が必要です。
ページレイアウトに関しては復元後すぐに気づいて対応しそうですが、レポートに関しては作成しているものがない場合、削除されたままになっていることに気づかず、修正しないまま後から困りそうな部分です。
また、すでにレポートを作成している場合で、削除予定の項目をレポートで使用していてもエラーが出ることなく削除できてしまう点は注意が必要です。
しかも、列や行での使用だけでなく絞り込み条件として項目を使用している場合でもエラーが出ることなく削除できてしまいます。
対処法としては、削除前に項目の使用場所を確認しておくぐらいしかないと思います。
項目の復元時に表示される内容のうち、
という部分について、少し言及したいと思います。
API参照名（項目名）は、削除した時に「×××_del」に自動で変更されます。
このことは、項目を削除した後に「削除済み項目」の一覧を見ると分かります。
復元したときにAPI参照名が変わるというよりは、削除したときに変更されたAPI参照名「×××_del」のまま復元される、といった方が正しいような気がしますが、復元前後でAPI参照名が変わってしまうことに注意してください。
もちろん、項目を削除してから復元するまでの間に同じAPI参照名の項目を作成していない場合は、復元後に編集する（「_del」部分を消す）ことで、削除前と同じAPI参照名に戻すことができます。
フローやApexなどで使用している項目は、削除しようとしてもエラーが出て削除ができませんが、レポートの場合、エラーが出ることなく削除できてしまいます。
そのため、削除項目を復元後にレポートやダッシュボードの動作がおかしい場合は復元した項目を該当レポートで使用していないかの確認を行った方がいいと思います。
また、復元した項目をレポートで使用したいのに見つからない場合は、レポートタイプ設定から項目を再設定する必要があることにも注意が必要です。
やはり、復元が簡単にできるからといっても万能なわけではないので（削除時点でAPI参照名は変わってしまうし）安易に削除・復元しないことが一番よさそうだな、というのが個人的な感想です。
それでは、またお会いしましょう！！
関連記事
削除後のデータについての気づき
こんにちは、株式会社オプトプランニングです。
2022年8月12日付で、当社は協会けんぽ広島支部様より、
「ひろしま企業健康宣言 健康づくり優良事業所」に認定されました！
昨年に続き、2年連続 5つ星です！！
当社の令和3年度（令和3年4月～令和4年3月）の取組みですが、
基本はもちろん、身近に出来ることから力をいれてきました！
まずは、特定保健指導を社員全員に実施しました。
全員の健康診断後、直接対面で行ったり、WEB面談でお願いもしました。
昨年度好評で、既に定着しつつある社内運動大会も継続して開催、
新しい取り組みとしては、朝のストレッチもやってみました。
広く認識を深めるために、認知症サポーターの講座も受講しています。
当社の健康経営に関する取り組みは、
コーポレートサイトの「健康経営のページ」をご覧ください！
https://www.opt-p.co.jp/initiatives/#link_sec_02
これからも、従業員のみなさんの健康づくりを支えてきたいと思います！