タグ: やってみた

はじめに

こんにちは！株式会社オプトプランニングです。
Salesforce（Salesforce.com／セールスフォース・ドットコム、略してSFDC）であれこれやってみたことを書いていきます。

Apexを使った簡単なメール送信方法は以前ご紹介しましたが、今回はフローを使ったメール送信方法について書いていきたいと思います！！

今回はTrailheadでフローを作成しています。

外部メール送信をフローの新規作成からやってみた

設定からフローの新規作成をしてみよう

早速、フローを作っていきたいと思います。

まず、設定のホーム左上にある検索に「フロー」または「flow」と入力し、「プロセスの自動化」の配下にある「フロー」をクリックします。
（検索は、実は英語名でヒットするものもあります。今回の「フロー」と「flow」の検索結果の違いなど、気になった方は試してみて下さい。画像は「flow」で検索しました）

フローの一覧が表示され、右上に「新規フロー」というボタンがあるので、クリックします。

フローの起動条件を選んでみよう

新規フロー画面が立ち上がるので、フローの起動条件を選び、右下の「作成」をクリックします。

今回は、「画面フロー」で作ってみようと思います！

フロー要素を追加してみよう

起動条件を選んだら、メール送信の要素を追加します。
要素の追加は「＋」をクリックします。

「＋」をクリックすると、どの要素にするか選択画面になるので、「アクション」をクリックします。

要素「アクション」のヘルプテキストに

フローの外部のアクション（メールの送信や承認申請など）を実行します。

と書いてあるのでわかりやすいですね！
（少し前までこのようなヘルプテキストはなかったように思います。最近のフロー移行の流れから、よりわかりやすいフロー作成のためかもしれないですね）

もし、フローを作成しようとしている環境でメールアラートを設定している場合は、要素の内容に「メールアラートを送信」というものがあるので、間違えて選択しないようにしましょう。

アクションを選んでみよう

要素で「アクション」を選んだら、次はアクション内容の選択を行います。

新規アクション選択画面が表示されるので、真ん中の検索に「メール」と入力します。

すると、「メールを送信（emailSimple-emailSimple）」という項目が検索窓の下に表示されるのでクリックします。

外部に送信するメールの設定をしよう

アクションで「メール送信」を選んだら、外部へ送信するメールの設定画面が表示されます。

この時、入力必須のものは

• アクションの表示ラベル
• アクションのAPI参照名
• メールの件名
• メールの本文

です。
それ以外は任意項目となっており、任意項目は項目横のトグルボタンをクリックすると入力欄が出現します。

必要事項の入力が出来たら「完了」をクリックします。

これで外部メール送信が完成しました！！

フローを保存しよう

このままブラウザを閉じてしまうとせっかく作成したフローがなくなってしまうので、右上の「保存」ボタンを押して、フローの保存を行います。

保存しようとすると、フローの表示ラベル、API参照名の入力画面が表示されるので、それぞれ入力して保存しましょう。

おわりに

ざっとではありますが、フローで外部メール送信を作ってみました。

今回は説明できなかったですが、フローの起動条件をレコードトリガフローにしてみたり、メールテンプレートを作成してみたりすると件名や本文を動的なテキストにすることができるので幅が広がります。

テンプレートについても近いうちにやってみたで紹介できればと思います。

それでは、またお会いしましょう！！

はじめに

こんにちは！株式会社オプトプランニングです。
Salesforce（Salesforce.com／セールスフォース・ドットコム、略してSFDC）であれこれやってみたことを書いていきます。

レポートを作成していると「過去の月ごとの商談件数が知りたい」や「月ごと・週ごとの金額の合計がわかればいいな」など、データを期間ごとに集計したい場面は多いと思います。

そんな時に使うのが、「期間集計」です。

これは、データ型が「日付」「日付/時間」項目の場合、簡単な設定で任意の期間で集計をすることができるものです。

今回はLightning Experienceでの期間集計の方法や、やってみて分かったこと、他の方法などを書いていきたいと思います。

※2023/1/30　訂正・追記あり

日付項目を年月（YYYY年MM月）で期間集計してみた

早速、期間集計をやってみようと思います！

今回使用するレポートは、以前のブログでも使用したTrailheadのモジュールをダウンロードした時に入っていた図１のレポートです。
（どのモジュールだったかは前回から思い出せておりませんのであしからず）

まずは、右上の「編集」をクリックしてレポートの編集画面を表示させます。

今回は、レポート内にある「完了予定日」を期間集計してみたいと思います。
日付項目を期間集計するには、対象の項目がグループ化された行または列に存在する必要があります。

列にある項目「完了予定日」を期間集計しようとしてみても、以下のように期間集計できる項目が出てきません。

そこで、「完了予定日」を行グループに移動して期間集計しようとすると…
「集計期間単位」という項目が出てきました！

期間集計は、この「集計期間単位」で任意の単位を選択することで設定します。

今回は「年月」で集計しようと思うので単位に「年月」を選択します。
（図３のようにデフォルトでは「日付」が選択されていますが「年月」をクリックすると選択できます）

すると、日にちまで表示されていた「完了予定日」が年月のみの表示に変わりました！

編集時は表示されるデータが少ないため、期間集計で何が変化するのかわかりにくいですが、期間集計する前後のレポートを見比べてみると以下のようになります。

左図が「完了予定日」を期間集計する前、右図が「完了予定日」を期間集計した後です。
（わかりやすくするため、基準とグラフ種類を変更しています。）

期間集計前は日ごとに集計されていたのが、「年月」で期間集計したことで月ごとに集計されるようになりました。

オブジェクトの項目を増やしたりすることなくこのような集計が行えるのはとても便利ですね！

実際にやってみてわかったことや気をつけたいこと

期間集計はあくまで集計するための機能

期間集計を行う場合、対象の項目がグループ化されていなければなりません。
期間集計が表示されない場合は、対象の項目をグループ化しているかどうか確認してみましょう。

あくまで「集計」機能なので、データの表示形式を変更するためのものではないということを念頭に入れておきましょう。

また、期間集計を行う項目はグループ化しなければならないため、表形式のレポートでは使用できません。

期間集計を行った項目の表示内容

期間集計を行った項目は、期間集計で選択した単位でしか表示されなくなります。

今回やってみた期間集計を例にすると、「完了予定日」を「年月」で期間集計したレポートは、完了予定日の年月だけ表示され、完了予定日の日付は表示されません。

集計は「年月」で行いたいけど、日付や時間などの表示もレポートに表示したいのに…という時は気をつけたい部分です。

データ内容は変わらないので、表示されていない情報（例で言えば「完了予定日」の日付）はレコードを参照すればいいのですが、いちいちレコードを参照するのも面倒に感じてしまいます。
期間集計を行う項目は、期間集計後の表示でいいかの判断が必要かもしれません。

エクスポートをやってみてわかったこと

エクスポートをしてみると期間集計を行った項目に関して影響が出る場合があります。

「フォーマット済みレポート」の場合、期間集計を行う前後でエクスポートされるデータ内容が変わります。

先ほどの期間集計した前後のレポートをエクスポートして比較すると以下のようになります。

「フォーマット済みレポート」でエクスポートした時、期間集計した項目はレポートで表示された内容のままエクスポートされます。

期間集計を「年月」で行ったレポートをエクスポートすると、エクスポートしたファイルでは「完了予定日」の日付は分からなくなってしまいます。

「詳細のみ」でエクスポートした場合は、期間集計を行う前後でデータ内容は変わりません。

期間集計する前後のレポートをエクスポートした比較は以下です。

「詳細のみ」でエクスポートした時、期間集計した項目はレコードデータに基づいた内容でエクスポートされます。

期間集計を「年月」で行ったレポートでも、エクスポートしたファイルから「完了予定日」の日付がわかります。

期間集計を行いたいけど、項目の表示形式は変更したくない！！

行レベルの数式を使ってみよう

年月などの期間集計はやりたいけど、対象項目の表示形式はそのままにしておきたいという場合もあると思います。

また、エクスポートの結果からレポートの期間集計は使いにくいということもあるでしょう。

そんな時に私が思いついたのは、期間集計を行いたい項目を利用して「行レベルの数式」を作成し、その数式を集計項目に利用する方法です。

行レベルの数式を作ってみた

行レベルの数式もレポート編集画面から簡単に作成できます。

レポート編集画面を開いたら「列」の右にある「▼」をクリックすると「行レベルの数式を追加」があるのでクリックします。

「行レベルの数式列を編集」画面が開くので、以下のように設定します。

「列の名前」はレポートに表示される項目名になるので、必要があれば「説明」に数式の内容を書いておくといいと思います。

この数式は「完了予定日」の年月部分だけをテキスト形式で表示させるものになります。
※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) & ‘月’ 】の「完了予定年月」の表示を忘備録として載せておきます。

訂正後の「完了予定年月」は正しく並び替えできています。

今回、参考にした数式は公式ヘルプに紹介されていました。

[数式 サンプル] 日付型項目から年・月を抽出する数式

はじめに

こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。

今回は、リリースをやってみようと思います！！

前回までのおさらいと気づき

今までのやってみたこと

前々回 は変更セットの作成を行いました。

そして 前回 は変更セットのアップロードを行い、送信変更セットのアップロード前後の違いを確認しました。

使用環境やリリースの内容については 利用環境と内容 を見てください。

前回のブログアップ後に気づいたこと

今回の本題であるリリースを行う前に、前回のブログアップ後に気づいたことを書いていきたいと思います。

前回、変更セットのアップロード前後の比較・確認を行うために画像を載せていました。
この部分に、前回は全く気づかなかったちょっとした違いがありました。

どこかわかりますか…？？

なんと、変更セットコンポーネントの「名前」が違うのです…！！！！！

リリース作業は実務でも行いましたが、アップロード後にコンポーネントの名前が変わることは気づいていませんでした…！！

なので、全てのコンポーネントの名前が変わるのか、特定の種別のコンポーネントだけなのかなどについても不明です…

今回に関しては、アップロード前はAPI参照名が表示されており、アップロード後は表示ラベルが表示されているようです。
（ちなみに、受信変更セットでは表示ラベルが表示されているようです。）

どうしてこのような動作になるか不明ですが、今まで一貫して以下の権限セット１つをコンポーネントに追加して作成した変更セットを使用しています。

この件については、なぜこのようなことが起こるのか・他の種類のコンポーネントの時はどうなるのかなど、詳細がわかり次第ブログでご紹介できるように調査を続けていきたいと思います。
（もしかしたら、プロファイル関係の変更セットだったからかな…？と思ったり…）

今回のブログでもコンポーネント名が入った画像が出てきますが、名前が違っても間違いなく同じ変更セットを使用していますので、特に注意書きなどありませんがそのように読み進めていただければと思います。

受信変更セットを確認してみた

初っ端から脱線してしまいましたが、話を戻してリリース作業を再開していきます！！

開発環境で作成した「送信変更セット」はアップロードすることによりリリース環境で「受信変更セット」として受け入れているはずです。

前回は送信変更セットのアップロード完了までの確認を行いましたので、まずはリリース環境の方で受信変更セットの確認から行っていこうと思います！

最初に、リリース環境である「T2Sandbox」にログインし、設定の検索ボックスに「変更セット」と入力して「受信変更セット」を開きます。

受信変更セットを開いた時、「リリースの情報」という画面に変わった場合は、下へスクロールして最下部にある「次へ」をクリックしましょう。

受信変更セットの一覧が表示されます。

「リリース待ちの変更セット」に前回アップロードした変更セットを確認することができます！！

これで、リリース環境に変更セットのアップロードが無事に行われていることの確認ができました。

変更セット名の部分がリンクになっているので、クリックしてしてみましょう。

すると、変更セットの詳細画面が表示されます。

送信変更セットと違う点として、「ソース組織」があります。
（先ほどの受信変更セット一覧の画面でも確認することができます）
ここでどの環境からアップロードされた変更セットなのかを確認することができます。

また、「有効期限」もあります。
受信変更セットには有効期限が設けられています。
有効期限はアップロード後６か月です。

変更セットをアップロードして半年後にリリースを行うことはないと思いますが…

有効期限が切れると、変更セットは永久に削除されます。

引用：送信変更セットのアップロード（Salesforceヘルプより）

と書かれていますので、後から内容を確認したい時に確認ができない…！ということにならないように気を付ける必要はありそうです。

リリースしてみた

受信変更セットを使用してのリリース

受信変更セットの確認も終わりましたので、遂にリリースを行います…！！
ここまで長かった…！！

リリースは受信変更セットから行います。

受信変更セットの一覧を表示させ、先ほど確認した「リリース待ちの変更セット」のアクション欄にある「リリース」をクリックします。

すると、「変更セットのリリース」画面に移動します。

「テストオプションの選択」にいくつか選択できる項目がありますが、今回は「デフォルト」を選択し、「リリース」をクリックします。

このようなポップアップが立ち上がるので、「OK」をクリックします。

リリースが開始され、画面はリリースを行った変更セットの詳細画面に移ります。

変更セットの詳細の上部にさっきまで無かった「開始されたリリース」という強調表示があります。
この表示が、対象の変更セットが現在リリース中であることを表しています。

強調表示部分の「リリース状況」と書かれた部分はリンクになっており、リンク先では対象の変更セットの詳しいリリース状況を確認することができます。

クリックしてみるとリリース状況の画面に移動しました。

今回は変更セットのコンポーネントが少ないため、リリース状況をみるとすでに「成功」の一覧に表示されていました。

これでリリースは無事に完了です！！！

もしここでなんらかの理由でリリースができなかった場合、「失敗」の一覧に変更セット名が表示され、アクション欄の「詳細を表示」でエラー内容を確認することができます。

また、コンポーネントの数が多かったりApexやVFPがたくさん入っていると検証に時間がかかりますので、その時は気長に待ってみましょう。

リリースの確認

では、今回行ったリリースがちゃんと反映されているか確認してみます。

コンポーネントとして含めた権限セットを確認するため、設定の検索ボックスに「権限セット」と入力して「権限セット」を開きます。

表示される権限セットの一覧に、今回コンポーネントとして含めた「ユーザのMFA認証」が追加されていることが確認でき、ちゃんと変更セットでのリリースができていることがわかりました！！

リリース後の受信変更セットを確認してみた

受信変更セット一覧

リリースは無事に終わりましたが、リリース後の受信変更セットについても確認しておこうと思います。

まずは受信変更セット一覧の画面です。

リリースが成功すると、対象の変更セットは「リリース済みの変更セット」の欄に移動します。
また、「アップロード日」ではなく「リリース日」が表示されるようになります。

受信変更セット詳細画面

次に、リリース後の受信変更セットの詳細画面を確認してみます。

リリース中にあった強調表示がなくなる代わりに、「リリース履歴」が追加されています。

この部分、エラーでリリースが失敗した場合も履歴として追加されていきます。
エラーの場合、「アクション」の「詳細を表示」でエラー内容の詳細を確認することができます。

また、今回は行っていませんが「検証」を行った場合もこの履歴が追加されていきます。

「リリース待ちの変更セット」欄に表示されている変更セットで、この「リリース履歴」にエラーがある場合はリリースを行う前に内容を確認しておく方がいいでしょう。

リリース履歴には開始時刻と終了時刻が表示されているので、どのぐらいの時間でリリースが完了したか確認することもできます。
（今回のリリースは全く時間がかかっていないことが分かります。）

あとがき

リリースはあっけなく終わってしまいましたが、これで無事に変更セットを使用したリリースを完了することができました。

確認作業は別として、実際のリリースも変更セットの作成が一番比重の大きい作業だと思います。

今回は１つのコンポーネントでしたが、リリースするコンポーネントが増えるにつれエラーも起きやすいので、リリースでエラーがでたら変更セットの作り直し＆アップロードの繰り返し…を行っていくことになると思います。

変更セットの作り直しやアップロードのやり直し、使いまわしについて、実際にやってみてこのような使い方をすれば効率がいいかも…？と感じたことがいくつかあるので、近いうちにまとめをブログでアップできればと思います。

では、またお会いしましょう！！

関連記事
リリースしてみた＜変更セット作成編＞
リリースしてみた＜アップロード編＞

はじめに

こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。

今回は、リリースに向けて変更セットのアップロードをやってみようと思います！！

前回までのおさらい

前回 は送信変更セットを作成しました。

無事に作成できたのでアップロードを行おうとしたところ、このような画面が出てしまいました。

リリースするためには変更セットを作成するだけではできない…！！

ということに気づいたのが前回の変更セット作成編でした。

アップロードの準備をやってみた

アップロードに必要な設定とは

変更セットをアップロードするには、アップロード先の環境（変更セットを受け取る環境）でリリース接続の設定を行う必要があります。

デフォルトの状態では、本番組織・Sandbox問わず全環境で変更セットのアップロードを受け付けていない状態となっています。
そこで、どの環境からの変更セットを受け付けるか受け取る側の環境で設定する必要があります。

変更セットの作成はアップロード先の環境があってもなくてもできますし、リリース接続の設定は変更セットを作成する前に行っても後に行っても問題ありません。

リリース接続の設定を行う

今回は先に変更セットの作成を行ったので、次にアップロード先の「T2Sandbox」でリリース接続の設定を行います。（使用環境などは 前回の使用環境と内容 を参照）

変更セットの作成は「TSandbox」で行っていたので、現在のログインしている環境は「TSandbox」です。
まずは「T2Sandbox」に環境を変えるためログインし直します。
ログイン出来たら、設定の検索ボックスに「リリース」と入力して「リリース設定」を開きます。

リリース設定を開いた時、「リリースの情報」という画面に変わった場合は、下へスクロールして最下部にある「次へ」をクリックしましょう。

リリース設定を開くとリリース接続先として組織の一覧が表示されます。
この一覧から、どの環境に対しての変更セットを受け付けるか個別に設定していくことになります。

「TSandbox」からの接続を許可したいので、「TSandbox」の左横にある「編集」をクリックします。

「リリース接続の詳細」画面が開くので、「アップロード認識方向」内の「変更着信を許可」にチェックをつけて「保存」をクリックします。

「保存」をクリックすると「リリース設定」の画面に戻ります。

リリース設定画面を見ると、先ほど設定を行った「TSandbox」の右端にある「アップロード認証方向」が変わっていることがわかります。

このような表示になっていれば、リリース接続の設定は完了です。

これで「TSandbox」から「T2Sandbox」へ変更セットをアップロードできるようになりました！！

送信側のリリースの設定を確認

アップロードを行う前に、送信側の「TSandbox」のリリース設定を確認してみたいと思います。

「TSandbox」にログイン後、先ほどと同様の手順でリリース設定を開くと、「TSandbox」から「T2Sandbox」に向けて矢印がついていることが確認できます。

アップロード認証方向は現在ログインしている環境を基準に表示されるので、「TSandbox」と「T2Sandbox」で表示のされ方が違いますが認証方向に違いはありません。

次に、組織一覧の中の「T2Sandbox」横の「編集」をクリックして詳細を開いてみます。

詳細を開くと、すでに「変更送信を受け入れる」にチェックがついていることが確認できます。

こちら、画像では分かりにくいですが「変更送信を受け入れる」のチェックボックスは操作することができないようになっています。
このチェックボックスは対象組織の「変更着信を許可」と連動しているようです。

他組織の受け入れ設定を変更することはできないので、リリース接続の変更を行うときは先ほど「T2Sandbox」を設定したように設定変更したい組織にログインする必要があります。

ちょっと脱線：相互で変更着信を許可してみた

「TSandbox」のリリース設定の確認ができたところで、相互に「変更着信を許可」するとどうなるかやってみます。

保存をしてリリース設定画面に戻ってくると、「アップロード認証方向」の矢印が両方向に変わっていました。

それぞれ設定すれば相互にアップロードを許可できることがわかりました。（実際に設定するかは別として）

変更着信の設定は対象組織にログインすれば簡単なので、想定と違う組織にアップロードすることを防ぐためにもどの組織でどのように変更を許可しているかの管理は行わなければならないでしょう。

変更セットのアップロード再挑戦してみた

変更セットのアップロード：二回目

少し寄り道してしまいましたが、変更セットのアップロードに再挑戦します。

前回　と同様に「アップロード」をクリックすると、対象組織として「T2Sandbox」が表示されるようになりました。

「T2Sandbox」が選ばれていることを確認して、「アップロード」をクリックします。

今回は無事にアップロードができました！！

アップロードを行うのに少し時間がかかる場合がありますが、完了のメールも送られてきますよ。

アップロード前後の変更セットの違い

アップロード前後で何が変わるのか詳細画面を見比べてみました。

アップロード前後で変わることとして

• 状況の変化
• 「編集」ボタンの有無
• 変更セットアップロード履歴の有無
• 変更セットコンポーネントのアクションの変化

が挙げられます。

状況の変化としては、アップロード前が「オープン」アップロード後が「クローズ」に変化します。

また、アップロードするまではコンポーネントの追加及び削除といった編集を行うことができますが、アップロード後はそれらができなくなり、コンポーネントのアクションが「削除」から「ソースを表示」に変わります。

一番の違いは変更セットアップロード履歴の有無です。
アップロード後はどの組織にいつ誰がアップロードを行ったかという情報が追加されます。

あとがき

リリース接続を行うことで無事にアップロードができました。

後はリリースするだけ…となりましたが、変更セットのアップロードについて掘り下げていたら長くなってしまったので、リリースについては次回に持ち越したいと思います。
また、アップロード関連についてはまだ書き足りないことがあるので近いうちに別で紹介しようと思います。

リリースはあと少しで完了しそうですが、何事もなく進むといいな…

では、またお会いしましょう！！

関連記事
リリースしてみた＜変更セット作成編＞
リリースしてみた＜リリース編＞