入力規則のススメ~ユーザのライセンス種別で制限してみよう~

はじめに

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

今回は入力規則について書いていこうと思います。
プロファイル・ユーザ・ロールの入力規則例は公式ヘルプに紹介されているので、ユーザのライセンス種別で制限する方法を紹介します。
こんなやり方もあるんだ~と参考になれば幸いです。

実際あった入力規則の盲点

入力規則を作成する際、プロファイルで制限する方法をよく見かけるため、最初はプロファイルで入力規則を作成していました。

その後、カスタムプロファイルを増やすために、影響調査を行う過程で「プロファイルを増やす=既存の入力規則の確認・修正・再テストが必要」なことに気づきました。

また、私が扱っている環境では複数のユーザライセンスが混在しおり、プロファイルではなくユーザのライセンス種別で入力規則を作成できるのではないかと気づきました。

今回紹介するユーザのライセンス種別で制限する入力規則は、単一のライセンスのみを使用している環境では利用機会がないかもしれないです。。。

ライセンス種別で入力規則を作るには

プロファイルで制限する場合、よく見かけるのがプロファイルの名前である「Profile.Name」を使用する例です。
ライセンス種別で制限する場合は、「UserType」を使用します。

ライセンス種別は、ユーザに割り当てられたライセンス種別を意味する「User.UserType」、ユーザに割り当てたプロファイルで指定しているライセンス種別を意味する「Profile.UserType」二つありますが、今回は「User.UserType」を使用する方法を紹介します。

「User.UserType」を「項目の挿入」を使用して入力する場合は、図1のように選択します。

図1 項目の挿入
図1 項目の挿入

SFDCでは様々なユーザライセンスがあるので、ライセンス種別に関して説明は割愛しますが、今回使用するライセンス種別と「UserType」名は以下です。

ライセンス種別 の名称UserType の名称
標準ユーザStandard

他の「UserType」について詳しく知りたい方はこちらを参考にしてください。

ライセンスで制限する入力規則を作ってみた

ライセンスで制限する入力規則を実際に作成してみようと思います。
環境はTrailhead、オブジェクトは「取引先」を使用し、入力規則の作成やレコードの新規登録は「標準ユーザ」ライセンスを持つユーザで行います!

まずは、以下のような2つの入力規則を作ってみます。

  • 項目「評価」を未選択で保存するとエラーが発生し、項目「評価」にエラーメッセージを表示
  • 項目「会社形態」を未選択で保存するとエラーが発生し、項目「会社形態」にエラーメッセージを表示

エラー条件数式は以下です。
「[数式 サンプル] 入力規則により項目の入力を必須とする数式」で紹介されているサンプル数式を活用しました)

ISPICKVAL(Rating , '')
ISPICKVAL(Ownership , '')

その他の設定については図2を参照してください。
エラー条件式とエラー表示場所以外は項目「会社形態」の設定も同様なので割愛します。

この入力規則を有効化して、取引先を新規登録しようとすると図3のようなエラーが表示されます。
(必須項目が未入力状態だと入力規則の判定はされないので、必須項目に適当な文字列を入力しています)

図2 項目「評価」の入力規則
図2 項目「評価」の入力規則
図3 入力規則で項目「評価」「会社形態」でエラー発生
図3 入力規則で項目「評価」「会社形態」でエラー発生

先ほど作成した入力規則の確認ができたところで、項目「評価」の入力規則を以下のように変更してみようと思います。

  • ライセンス種別が「標準ユーザ」以外のユーザが項目「評価」を未選択で保存するとエラーが発生し、項目「評価」にエラーメッセージを表示

変更後のエラー条件式は以下です。

AND(
ISPICKVAL(Rating , '') ,
NOT(ISPICKVAL( $User.UserType , 'Standard'))
)

「UserType」のデータ型は選択リスト型である点は注意が必要です。
「Profile.Name」のデータ型はテキスト型なので、演算子での比較が可能ですが、「UserType」のデータ型は選択リスト型なのでこのままでは比較ができず「ISPICKVAL()」関数を使用してデータを比較する必要があります。
「ISPICKVAL()」の詳細はこちらを参照してください。

図4が項目「評価」の入力規則変更後です。

入力規則を変更後、取引先を新規登録しようとすると図5のようなエラーが表示されます。

ライセンス種別が「標準ユーザ」のユーザは、項目「評価」を未入力でも入力規則にひっかからないことが分かります。

無事にライセンス種別で制限する入力規則ができました!!

図4 ライセンス種別で制限した入力規則例
図4 ライセンス種別で制限した入力規則例
図5 入力規則で「会社形態」のみエラー
図5 入力規則で「会社形態」のみエラー

あとがき

Salesforceではライセンス種別がたくさん用意されているので、お使いの環境下でどんなライセンス種別があるか知っておくといいかもしれません!

また、入力規則を作成する際はライセンスで制限をかける場合もプロファイルで制限をかける場合も、作りたい入力規則が誰に対して制限したいものなのかを明確にしておくといいと思います。

今回はユーザのライセンス種別での制限方法を紹介しましたが、ロールを使用する方法などを含め、プロファイル以外で制限をする方法も知っておくといいと思います。

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

外部メール送信をフローでやってみた

はじめに

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

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

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

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

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

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

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

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

図1 フロー新規作成
図1 フロー新規作成

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

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

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


図2 新規フローの起動条件選択
図2 新規フローの起動条件選択

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

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

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

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

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

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

図3 要素の追加「+」部分
図3 要素の追加「+」部分
図4 要素の「アクション」
図4 要素の「アクション」

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

図5 メールアラート設定済みの場合
図5 メールアラート設定済みの場合

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

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

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

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

図6 アクション「メールを送信」
図6 アクション「メールを送信」

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

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

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

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

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

図7 メール送信に必須項目
図7 メール送信に必須項目
図8 任意項目の入力欄
図8 任意項目の入力欄

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

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

図9 外部メール送信フロー完成
図9 外部メール送信フロー完成

フローを保存しよう

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

図10 フローの保存
図10 フローの保存

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

おわりに

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

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

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

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

レポートの期間集計やってみた

はじめに

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

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

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

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

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

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

日付項目を年月(YYYYMM月)で期間集計してみた

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

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

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

図1 使用レポートの編集
図1 使用レポートの編集

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

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

図2 「完了予定日」グループ化前
図2 「完了予定日」グループ化前

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

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

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

図3 「完了予定日」グループ化後
図3 「完了予定日」グループ化後

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

図4 「完了予定日」を「年月」単位で期間集計
図4 「完了予定日」を「年月」単位で期間集計

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

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

図5 期間集計前
図5 期間集計前
図6 期間集計後
図6 期間集計後

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図7 期間集計前後のレポートのエクスポート結果(フォーマット済みレポートの場合)
図7 期間集計前後のレポートのエクスポート結果(フォーマット済みレポートの場合)

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

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

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

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

図8 期間集計前後のレポートのエクスポート結果(詳細のみの場合)
図8 期間集計前後のレポートのエクスポート結果(詳細のみの場合)

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

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

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

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

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

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

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

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

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

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

図9 行レベルの数式を追加
図9 行レベルの数式を追加

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

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

列の名前完了予定年月
数式出力種別テキスト
数式MID(TEXT(CLOSE_DATE),1,4) & ‘年’ & MID(TEXT(CLOSE_DATE),6,2) & ‘月’

この数式は「完了予定日」の年月部分だけをテキスト形式で表示させるものになります。
※2023/1/30数式訂正。詳細は追記を参照

図10 行レベルの数式列の編集画面

適用をクリックすると行レベルの数式が作成されているので、作成した数式でグルーピングを行います。
同時に、期間集計に使用していた「完了予定日」は列の方に戻してみます。

図11 数式をグルーピング
図11 数式でグルーピング
図12 数式で集計したレポートの表示
図12 数式で集計したレポート

すると、「完了予定日」の「年月」で集計しつつ、「完了予定日」の内容をレポート上に表示できるようになりました!!

ついでにエクスポートもしてみた

行レベルの数式があるレポートを「詳細のみ」でエクスポートしてみるとどうなるか試してみました。

すると…

図13 数式で集計したレポートのエクスポート結果
図13 数式で集計したレポートのエクスポート結果

行レベルの数式も項目としてデータをエクスポートできることが分かりました!!!

これだと、エクスポート後のデータの活用に幅が広がるかもしれませんね~

おわりに

期間集計ですが、実務の方では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) & ‘月’ 】の「完了予定年月」の表示を忘備録として載せておきます。

追記1 当初の数式
追記1 当初の数式
追記2 訂正後の数式
追記2 訂正後の数式

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

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

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

このやり方知ってる?レポートのドリルダウン

はじめに

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

今回はLightning Experienceでのレポートのドリルダウン(ドリルイン)機能についてあれこれやってみたことを書いていきます。

ドリルダウンのやり方~公式編~

レポートのドリルダウンについては公式ヘルプにやり方が載っていますので、そちらを確認してください。

レポートへのドリルダウンによる詳細の確認

ドリルダウンのやり方~非公式編~

こんなやり方もあります。
(2022年9月時点、公式ヘルプを探しても見つかりませんでしたので、非公式と名付けます。)

それは、グラフからドリルダウンする方法です。

ちなみに、SFDCのレポートでグラフを表示できるのは

  • サマリー形式
  • マトリックス形式

のレポートですので、表形式のレポートは公式の方法同様、対象外となるのでご了承ください。

グラフからのドリルダウンその1

グラフからドリルダウンする方法は2つあります。
1つ目は、表示されているグラフから直接行う方法です。

グラフの種類がドーナツの場合、下図のような赤枠で囲んだ部分を使用します。

図1 レポートグラフ
図1 レポートグラフ

グラフのうち、ドリルダウンしたい色の部分をクリックします。
今回は、フェーズの中から一番多い水色部分の「Closed Won」にあたる部分をクリックしてみます。

すると、以下のようになります。

図2 グラフからのドリルダウンした時のグラフ変化
図2 グラフからのドリルダウンした時のグラフ変化
図3 グラフからドリルダウンした時の表
図3 グラフからドリルダウンした時の表

Closed Wonでドリルインできたことが表からも確認できます。

編集しているわけではないので、もう一度水色部分をクリックしたり、レポートを表示し直すとドリルダウンは解除されます。

グラフからのドリルダウンその2

2つ目は、グラフの凡例から行う方法です。

赤枠部分に凡例が表示されていますが、こちらを使用します。
(凡例は表示させる位置を変更できるので、必ずこの位置にあるとは限りません)

図4 グラフの凡例
図4 グラフの凡例

凡例からドリルダウンする場合も、グラフからの時と同様にドリルダウンしたい凡例をクリックします。
今回は一番下にある「その他」をクリックしてみます。

すると、以下のようになります。

図5 凡例からドリルダウンした時のグラフ変化
図5 凡例からドリルダウンした時のグラフ変化
図6 凡例からドリルダウンした時の表
図6 凡例からドリルダウンした時の表

グラフから行った時と同様にドリルインできました。

エクスポートについて

公式のドリルダウン方法とグラフからのドリルダウン方法それぞれでエクスポートを行ってみるとどうなるかやってみましたが、どちらも同じ内容をエクスポートすることができました。
(エクスポートはどちらも「フォーマット済みレポート」を「Excel形式(.xlsx)」で行いました)

どちらも同じ内容ですが、参考までにエクスポート結果を載せておきます。

図7 左が公式、右がグラフからドリルダウンした時のエクスポート結果
図7 左が公式、右がグラフからドリルダウンした時のエクスポート結果

左が公式のドリルダウン方法でエクスポートを行った場合、右がグラフからのドリルダウン方法で行った場合です。

どちらも「グラフからのドリルダウン1」で行った「Closed Won」でドリルダウンを行い、エクスポートしています。
検索条件の内容を見てみると、どちらも同じ内容になっていることが確認できます。

これにより、グラフからのドリルダウンも全く同じ絞り込みが行えていることがわかりました。

あとがき

公式に載っていませんが、もしかするとレポートを頻繁に見る機会のある方は感覚的・直観的に使っている機能かもしれません。

グラフからドリルダウンを行う場合、メリットとしてはレポートの再表示を行わなくてもドリルダウン前のレポートに戻せる点です。

デメリットとしては、グラフからドリルダウンする場合は複数の項目値を選択することができない点です。
複数の値でドリルダウンを行いたい場合は公式のやり方で行ってください。

今回、説明のために使用したレポートは、Trailheadで勉強した時にインストールしたものに付属していた商談レポートです。
(どのハンズオンChallengeでインストールしたパッケージだったか忘れてしまいました…)
Trailheadを利用したことがある方は、同じレポートがあるかもしれないので、ご自身のハンズオン組織で確認することができると思います。
(もちろん、同じレポートでなくても確認できますよ!)

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

【実践&検証】Sandboxの更新

はじめに

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

先日、Sandboxの更新を初めて行いました。
その際、テスト用に作成していたレコードがSandbox更新後になくなってしまいました…(泣)

そこで今回はSandboxの更新について、更新前後でどのような変化が起こるのか、検証を交えてやってみようと思います。

今回やってみること

「Sandboxの更新」って何??

Sandboxの更新については、公式ヘルプで以下のように記載があります。

Sandbox を更新すると、ソース組織のメタデータが更新されます。Sandbox がコピーであるか、Sandbox で Sandbox テンプレートが使用されている場合は、更新プロセスにより、そのメタデータと組織のデータが更新されます。

Sandboxの更新

本番組織を元に作成したSandboxの更新については情報があったのですが、Sandboxを元に作成したSandbox(SandboxのコピーSandbox)の更新についてはあまり情報がなかったため、今回は後者について書いていきます。

SandboxのコピーSandboxの更新をやってみる

今回更新をやってみる環境は、以前作成したSandbox「T2Sandbox」です。(詳しくはこちらをご覧ください)
この「T2Sandbox」は、「TSandbox」というSandboxを元に作成したSandbox(コピーSandbox)です。

コピーSandboxを更新するとコピー元と比べて中のデータがどうなるのか、更新前後でSandboxにどんな変化があるのかを検証を交えて確認していきたいと思います。

イメージは以下の図になります。

図1 内容概要(イメージ)
図1 内容概要(イメージ)

検証用のデータ作成をやってみた

その1:カスタムオブジェクトの作成

Sandboxの更新をやってみる前に、更新前後で比較するための検証用データをコピー元のSandbox(TSandbox)とコピーSandbox(T2Sandbox)にそれぞれ作成していきます。

まず、TSandboxとT2Sandboxにそれぞれの以下のようなカスタムオブジェクトを作成しました。

Sandbox名カスタムオブジェクトの表示ラベルAPI参照名
TSandbox顧客カスタム(Tsandbox作成)Tsandbox__c
T2Sandbox関係者の同意カスタム(T2sandbox作成)T2sandbox__c
図2 TSandboxで作成したオブジェクト
図2 TSandboxで作成したオブジェクト
図3 T2Sandboxkで作成したオブジェクト
図3 T2Sandboxkで作成したオブジェクト

その2:レコードの作成

次に、レコードを作成します。
違いを分かりやすくするため、以下の標準オブジェクトにそれぞれ1つのレコードを作成しました。

レコード名などは画像を参照してください。

Sandbox名レコードを作成したオブジェクト
TSandboxリード
T2Sandbox取引先
図4 TSandboxのリード(レコードあり)
図4 TSandboxのリード(レコードあり)
図5 T2Sandboxのリード(レコードなし)
図5 T2Sandboxのリード(レコードなし)
図6 TSandboxの取引先(レコードなし)
図6 TSandboxの取引先(レコードなし)
図7 T2Sandboxの取引先(レコードあり)
図7 T2Sandboxの取引先(レコードあり)

Sandboxの更新方法と手順

まずは本番環境へ

Sandbox作成の時もそうでしたが、Sandboxの更新も本番環境からでしか行うことはできません。

本番環境へログインし、設定のクイック検索で「Sandbox」と入力し「環境」の配下にある「Sandbox」をクリックします。

さっそく更新

Sandboxの一覧が表示されたら、対象のSandboxの左にある「更新」をクリックします。

図8 Sandboxの一覧画面
図8 Sandboxの一覧画面

「更新」をクリックすると「Sandboxの更新」が表示されます。
(なんだか見覚えのあるような画面ですね~)

「Sandboxの情報」には既に「T2Sandbox」の情報が入っていましたが、変更することもできるようです。

また、「作成元」は「TSandbox」になっていますが、こちらも変更することができるようです。

今回は、更新前後の違いが分かるように「説明」に更新年月を追加し、名前や作成元はそのままで「次へ」をクリックします。(検証を行ったのは2022年6月でした)

図9 Sandboxの更新画面
図9 Sandboxの更新画面

次に表示されるのは「Sandboxオプション」でした。
こちらは空白のまま「作成」をクリックします。

図10 Sandboxオプション
図10 Sandboxオプション

後は待つだけ

「作成」をクリック後、Sandboxの一覧に戻ってきました。

先ほど更新を行った「T2Sandbox」の「状況」は「待機中」になっており、「説明」が変わっていることが確認できます。
また、「アクション」、「場所」、「完了日」は空白になりました。

更新元である「TSandbox」の方は「アクション」のうち「削除」と「更新」が消えました。

図11 Sandboxの一覧画面
図11 Sandboxの一覧画面

ここまできたらSandboxの作成の時と同じように更新が完了するのを待つだけのはずです!!

いつまで経っても更新が完了しない…

有効化待機中について

Sandboxの一覧画面を時々リロードして見ていたものの、いつまで経っても更新が完了しませんでした。(Sandbox作成の時はすんなりできた記憶があるので、おかしいなと思いつつ他の作業を行っていました。)

半日ほど経過し、流石に時間がかかりすぎでは?と思い、Sandbox一覧画面をよくよく確認してみると…

図12 有効化待機中で表示されるアクション「有効化」と「破棄」
図12 有効化待機中で表示されるアクション「有効化」と「破棄」

更新を行ったT2Sandboxの「状況」が「有効化待機中」になっており、「アクション」に「有効化」と「破棄」が追加されていました…!

そうです、Sandboxの更新では有効化ができるようになったら(状況が有効化待機中に変わった段階で)手動で「有効化」しなければならないのです!!
待つだけではダメでした…(泣)

このことはしっかり公式ヘルプにも載っていましたので気になる方は公式ヘルプも参考にしてください…

Sandbox の更新
更新された Sandbox の有効化

通常だと、有効化する準備ができるとSFDCからメールが送られてくるようです。(私の場合、システムメールを送信しない設定にしていたために気づくのが遅くなりました)

Sandboxの作成と更新は手順や画面が似ているので、気を付けましょう!

有効化する前に破棄を試してみた

気を取り直して、有効化を行おうと思ったのですが、その前に「破棄」をクリックするとどうなるかやってみました。

図13 ポップアップ「更新を破棄」
図13 ポップアップ「更新を破棄」

このようなポップアップが出現しました。

この後、「キャンセル」ボタンを押し、破棄は行いませんでしたが、「破棄」クリック後は確認のポップアップが出るのですぐに破棄されるわけではない、ということが分かりました。

更新の有効化をやってみた

いつも通り脱線してしまいましたが、更新の有効化をやってみます!
「有効化」をクリックすると…

図14 ポップアップ「有効化」
図14 ポップアップ「有効化」
図15 有効化ボタンがアクティブ状態
図15 有効化ボタンがアクティブ状態

破棄の時と同じようにポップアップが出現しました。

このままではポップアップ内の「有効化」ボタンがグレーアウトして押せないので、チェックボックスにチェックをつけます。

すると、「有効化」ボタンがアクティブになるのでクリックします。

図16 有効化中に変化
図16 有効化中に変化

「有効化待機中」から「有効化中」に状況が変化し、「アクション」は空白になりました。

あとは「完了」になるのを待つだけです!!

更新前後のSandboxの比較をやってみた

Sandbox自体の比較をしてみた

まず、更新前後で組織IDが変化し、インスタンス(場所)も変わります。

図17 更新前後のSandbox情報比較
図17 更新前後のSandbox情報比較

そして…先日必須となったMFA認証についてですが、設定は初期化されていました。
そのため、再度設定が必要です。

Sandboxの中身(データ)を比較してみた

冒頭で作成した検証用のデータについて、更新したSandbox(T2Sandbox)は更新前と比較してどうなったか見てみます。

まずは、カスタムオブジェクトを見てみます。

更新後のT2Sandboxを見てみると、更新前に作成したカスタムオブジェクトはなくなり、更新元のTSandboxで作成したカスタムオブジェクトだけありました。

図18 更新後のT2Sandboxのオブジェクトマネージャ
図18 更新後のT2Sandboxのオブジェクトマネージャ

次にレコードを見てみます。

こちらもカスタムオブジェクトと同様で、T2Sandboxで作成したレコードはなくなり、更新元のTSandboxで作成したレコードだけとなっていました。

図19 更新後の取引先
図19 更新後の取引先
図20 更新後のリード
図20 更新後のリード

比較からわかったこと

組織IDやインスタンスの場所、MFA認証も初期化されることから、Sandboxの更新は更新元のSandboxから新規でコピーSandboxを作成するのと変わりがないように思います。

更新時に「作成元」が変更できるのも、新規でSandboxを作成するのと変わらないからこそできるように思います。

データを見ても、Sandboxを作成した後に作ったカスタムオブジェクトやレコードは更新をすることで消滅してしまいます。

ここで注意したいのは、Sandbox上でなんらかの開発を行った後にSandboxの更新を計画する場合です。
更新を行うと更新元のSandboxと全く同じデータになるので、更新を行うSandbox上で新規作成したデータはすべて消えてしまいます。
Sandboxの更新について、更新元データを付け足してくれるイメージを持たないようにしましょう。

ではどんな時にSanedboxの更新を行うのがいいのか考えてみました。

  • Sandboxの作成上限に達しているが、不要なSandboxがあるため、新規でSandboxを作成したい
  • 複数のSandboxで同時に開発を行い、1つのSandboxに開発内容を集約した後、他のSandbox同士でも開発内容を共有したい

などが挙げられると思います。

一つ目の場合は、不要なSandboxを削除して作成を行うよりも、不要なSandboxを更新する方が手間が省けそうです。

二つ目の場合は、リリースを特定のSandboxのみに行うことで、相互にリリースしなくていいので変更セット作成とリリースの手間が減りそうです。
言葉だと分かりにくいかもしれませんが、イメージとしては以下です。

図21 複数のSandboxで同時に開発する場合
図21 複数のSandboxで同時に開発する場合

この場合、Sandbox①を本番環境へのリリース用とすれば、本番環境リリース後に開発用Sandboxを更新するとでそれぞれの開発用Sandboxは本番環境と同等の環境に揃えることができそうです。

開発用のSandboxはそれぞれ違った環境を元に作成していても、更新時に同じ環境を更新元(作成元)とすればいいだけです。

もちろん、それぞれの開発環境に独自にテストデータを用意していて、今後も継続して使用したい場合は、レコードの場合はデータローダなどでデータを保存しておいたり、オブジェクトの場合は更新元に作成しておいたりしなければなりません。

あとがき

ここまでやってみて、あまりSandboxの更新は需要がないような気がしてきましたが…
更新を行うとどうなるんだろう?と疑問に思われている方の参考になれば幸いです。

今後も、気になったことがあれば検証してみたいと思います。

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

関連記事
SalesforceでSandboxを作ってみた(1)
SalesforceでSandboxを作ってみた(2)

リリースしてみた<リリース編>

Salesforceでやってみた

はじめに

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

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

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

今までのやってみたこと

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

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

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

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

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

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

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

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

図1 送信変更セットアップロード前
図1 送信変更セットアップロード前
図2 送信変更セットアップロード後
図2 送信変更セットアップロード後

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

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

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

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

図3 権限セット:ユーザのMFA認証
図3 権限セット:ユーザのMFA認証

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

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

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

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

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

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

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

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

図4 受信変更セット:リソースの理解1
図4 受信変更セット:リソースの理解1
図5 受信変更セット:リソースの理解2
図5 受信変更セット:リソースの理解2

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

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

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

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

図6 受信変更セットの一覧
図6 受信変更セットの一覧

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

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

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

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

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

引用:送信変更セットのアップロード(Salesforceヘルプより)

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

図7 受信変更セットの詳細画面
図7 受信変更セットの詳細画面

リリースしてみた

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

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

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

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

図8 受信変更セットの一覧
図8 受信変更セットの一覧

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

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

図9 変更セットのリリース
図9 変更セットのリリース

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

図10 「リリース」クリック後のポップアップ
図10 「リリース」クリック後のポップアップ

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

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

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

図11 リリース中の受信変更セット詳細画面
図11 リリース中の受信変更セット詳細画面

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

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

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

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

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

図12 リリース状況:成功
図12 リリース状況:成功

リリースの確認

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

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

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

図13 権限セット一覧
図13 権限セット一覧

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

受信変更セット一覧

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

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

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

図14 受信変更セット一覧:リリース済みの変更セット
図14 受信変更セット一覧:リリース済みの変更セット

受信変更セット詳細画面

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

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

図15 受信変更セット詳細画面:リソース履歴
図15 受信変更セット詳細画面:リソース履歴

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

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

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

図16 リリース履歴:失敗あり
図16 リリース履歴:失敗あり
図17 リリース履歴:リリースと検証成功
図17 リリース履歴:リリースと検証成功

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

あとがき

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

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

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

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

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

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

リリースしてみた<アップロード編>

Salesforceでやってみた

はじめに

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

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

前回までのおさらい

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

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

図1 アップロードエラー画面
図1 アップロードエラー画面

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

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

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

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

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

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

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

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

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

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

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

図2 リリース設定のリリースの情報1
図2 リリース設定のリリースの情報1
図3 リリース設定のリリースの情報2
図3 リリース設定のリリースの情報2

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

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

図4 リリース設定画面
図4 リリース設定の組織の一覧

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

図5 リリース接続の詳細
図5 リリース接続の詳細

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

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

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

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

図6 T2Sandbox上でのアップロード認証方向の確認
図6 T2Sandbox上でのアップロード認証方向の確認

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

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

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

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

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

図7 TSandbox上でのアップロード認証方向の確認
図7 TSandbox上でのアップロード認証方向の確認

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

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

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

図8 T2Sandboxのリリース接続の詳細
図8 T2Sandboxのリリース接続の詳細

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

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

図9 T2Sandboxも変更着信を許可
図9 T2Sandboxも変更着信を許可

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

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

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

図10 TSandbox上で相互にアップロード認証を確認
図10 TSandbox上で相互にアップロード認証を確認

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

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

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

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

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

図11 再アップロード
図11 再アップロード

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

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

図12 アップロード成功
図12 アップロード成功

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

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

図13 アップロード前の変更セット詳細画面
図13 アップロード前の変更セット詳細画面
図14 アップロード後の変更セット詳細画面
図14 アップロード後の変更セット詳細画面

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

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

が挙げられます。

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

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

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

あとがき

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

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

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

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

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

リリースしてみた<変更セット作成編>

Salesforceでやってみた

はじめに

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

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

使用環境と内容

今回の使用環境は、先日作成した

  • TSandbox
  • T2Sandbox

以上2つのSandbox環境です。
これらを使用して、Sandbox to Sandbox のリリースを行います。

Salesforceでリリースを行うにはいくつか方法がありますが、今回は変更セットを使用したリリースを行います。

イメージとしてはこんな感じです。

図1 リリースのイメージ図
図1 リリースのイメージ図

内容は、1つの権限セットをリリースするものとなっており、プロファイルは含めません。

変更セットの種類

変更セットには「送信変更セット」と「受信変更セット」の2種類があります。

「送信変更セット」に開発した内容を詰め込んで、リリース組織にアップロードすると、リリース組織上には「受信変更セット」として変更セットがアップロードされます。

少しややこしいですが、送信側と受信側で「変更セット」の名称が変わるのだな、と覚えておけばいいと思います。

図2 リリースのイメージ図2
図2 リリースのイメージ図2

変更セットを作ってみた

送信変更セットの作成

早速変更セットを作成していきます。

TSandbox(開発環境)にログインし、設定の検索ボックスに「変更セット」と入力し、「送信変更セット」をクリックします。

下図のような「リソースの理解」という画面になった場合は下にスクロールして「次へ」をクリックします。

図3 送信変更セット:リソースの理解1
図3 送信変更セット:リソースの理解1
図4 送信変更セット:リソースの理解2
図4 送信変更セット:リソースの理解2

送信変更セットの画面が表示されました。

新規作成したいので「新規」をクリックします。

図5 送信変更セットの画面
図5 送信変更セットの画面

「新規変更セット」が立ち上がるので、ここに変更セットの名前と説明を入力していきます。
(図は2022年2月から必須になった多要素認証(MFA)に関する権限セットをリリースした時のもので、名前や説明欄にはその時の内容を入力しています。)

全て入力ができたら「保存」をクリックします。

図6 新規変更セット編集画面
図6 新規変更セット編集画面

コンポーネントの追加

次は、変更セットにコンポーネントや関係するプロファイルを追加していきます。

名前と説明の保存後、作成した変更セットの詳細画面が表示されるので、「変更セットコンポーネント」にある「追加」をクリックします。

図7 送信変更セット詳細画面
図7 送信変更セット詳細画面

コンポーネント選択画面に移動するので、追加したいコンポーネントの種類を選択します。

今回は権限セットを追加したいので、「コンポーネントの種類」の横にあるボックスをクリックして表示されるリストから「権限セット」を選びます。

図8 コンポーネントの種類クリック前
図8 コンポーネントの種類クリック前
図9 コンポーネントの種類クリック後
図9 コンポーネントの種類クリック後

コンポーネントの種類を選択すると、選択した種類のコンポーネント一覧が表示されます。
先ほど権限セットを選択したので、権限セットのコンポーネント一覧が表示されています。

一覧からリリースしたいコンポーネント名の左にあるボックスにチェックを付けて「変更セットに追加」をクリックします。

図10 コンポネント一覧
図10 コンポネント一覧

これで選択したコンポーネントは追加され、変更セットの詳細画面に戻ります。
ここで戻らない場合(たまに詳細画面に戻らない時がありました)は、左のリストにある「送信変更セット」をクリックしてみて下さい。

変更セットの詳細画面では、無事にコンポーネントが追加されていることが確認できます。

今回のコンポーネントはこの一つだけで関係するプロファイルも無いので、これで変更セットの作成は完了です!!

図11 コンポーネント追加後
図11 コンポーネント追加後

コンポーネント追加時の注意点

無事に変更セットが作成できたところで、私なりのコンポーネント追加時に注意したい点をいくつか挙げていこうと思います。

まず、コンポーネントは複数選択することができますが、一覧が複数ページで構成されていると、別ページに遷移した時点で選択していたコンポーネントは全て選択が解除されます。

コンポーネント一覧が1つのページ内に収まっていれば気にしなくていいです。
しかし、複数ページにまたがっている時は、ページごとに「変更セットに追加」を行う必要があることに注意して下さい。

また、チェックを付けた後にコンポーネントの種類を変更した場合も同様ですので、変更セットの追加はチェックを付けたページごとに行うよう心掛けた方がいいと思います。

もしも間違ったコンポーネントを追加した場合は、アクションにある「削除」でコンポーネントを削除することができますよ。

変更セットをアップロードしてみた

アップロードの実施

少し脱線してしまいましたが、変更セット詳細画面にある「アップロード」をクリックしてアップロードをやってみます。

図12 変更セット詳細のアップロードボタン
図12 変更セット詳細のアップロードボタン

対象組織が…ない?

アップロードをクリックした後、このような画面が出てしまいました。

「アップロード」ボタンはグレーアウトしており、

この組織は、他の組織に変更セットをアップロードする権限がありません。承認については、変更をアップロードする組織のリリース接続管理者にお問い合わせください。

というエラーが表示されています。

図13 アップロードエラー画面
図13 アップロードエラー画面

そうです、リリースは変更セットを作成するだけではできないのです…!

あとがき

送信変更セットを作成することはできましたが、それだけではリリースのためのアップロードができないということがわかりました。

このままではリリースができないため、次回はリリースのための準備を行います…!
(勘のいい方はタイトルで気づかれたかもしれませんね)

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

関連記事
リリースしてみた<アップロード編>
リリースしてみた<リリース編>

本番組織の開発者コンソールは何ができるかやってみた

Salesforceでやってみた

はじめに

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

今回はSalesforce本番組織の開発者コンソールは何ができるのかやってみたいと思います。

開発者コンソールとは

開発者コンソールとは、Salesforceが提供する一連のツールを備えた総合開発環境です。
Webベースの開発環境なのでインストールなどの事前準備が不要で、Salesforce組織のアプリケーションの作成やデバッグ、テストなど様々な事が行えます。

そんな開発者コンソールですが、基本的には開発環境であるSandbox上で使用していると思います。
ですが、本番組織でも開発者コンソールを開くことができます。
本番組織とSandboxでできる事の違いがあるのか、違いがあればどんなところかを実際にやってみたいと思います。

本番組織の開発者コンソール

開発者コンソールを開いてみた

本番組織とSandboxで開発者コンソールの開き方に違いはありません。

「⚙」アイコンをクリックすると表示されるポップアップ内にある「開発者コンソール」をクリックすると開発者コンソールは開きます。

ここで「開発者コンソール」が表示されない場合は必要な権限設定が行われていないからかもしれません。
必要権限としては、システム権限の内

  • APIの有効化
  • すべてのデータの参照

の二つです。
この2つが有効になっていないユーザで操作している場合、開発者コンソールの表示はされないので注意してください。

図1 本番組織「⚙」押下後
図1 本番組織「⚙」押下後
図2 Sandbox「⚙」押下後
図2 Sandbox「⚙」押下後

早速、本番組織で開発者コンソールを開いてみましたが、Sandboxで開いた時と違いはありませんでした。

Salesforceにログインした時、Sandboxだと画面上部にSandbox名が表示されますが、そういったものもありません。
違いがなさ過ぎて、同時に開くとどっちがどっちかわからなくなってしまいそうです。

開発者コンソールは別ブラウザで開くので、別組織のものは同時に開かない方がよさそうですね。

図3 本番組織の開発者コンソール
図4 Sandboxの開発者コンソール

Apexを編集してみた

開発者コンソールを無事に開けたので、次は本番組織内にあるApexのファイルを開いて編集してみようと思います。
この時、システム権限として

  • Apex開発

が有効になっているユーザで操作しています。

そもそもApexのファイルを開けるかですが、こちらは問題なく開けました。

編集もできるか試してみます。
赤枠部分をコメントアウトしてみました。

赤枠部分のコメントアウトをすることができました。

次に、編集した内容をSaveしてみますが…

このようなエラーが出てしまいました…

Deployment Failed
Can’t alter metadata in an active org

何度か「Save」を試してみたところ、最初は「Save」をクリックした後エラーが出ていましたが、「Save」をクリックする前から表示されるようになってしまいました。

本番組織ではApexの編集を保存することはできません。

Apexクラスを変更したい時、Salesforce上だけで完結させるためには、Sandbox環境で編集を行い、本番環境に向けて変更セットをアップロード&リリースするしかなさそうです。

ちょっとした変更も例外なく変更セットを使用しなければならない点は要注意です。

クエリエディタを使ってみた

Apexの保存はできませんでしたが、開発者コンソールを開けるということは何かできるはず…

ということで、次はクエリエディタでSOQLクエリの実行を試してみます。

取引先のIDとNameを検索してみましたが、問題なく実行することができました!
本番組織上のデータの検索を行うことはできそうです。

あとがき

今回は本番環境の開発者コンソールでApexの編集とクエリエディタの使用をやってみました。

開発者コンソールは基本的にSandboxで使用するものという位置づけのようなので、本番環境からの使用はあまり期待しないほうがよさそうです。

他の機能についても、今後やってみたで検証できればと思います。

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

SalesforceでSandboxを作ってみた(2)

Salesforceでやってみた

はじめに

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

前回はSalesforceの開発環境であるSandboxを作成しました。今回も引き続きSandboxを作成していきます!!

SandboxのSandboxを作ってみた

SandboxのSandbox…?

はい。冒頭から混乱しそうなタイトルですみません。

SalesforceのSandboxは本番組織から作成するだけでなく開発環境であるSandboxを元にして作成することもできます。

Sandboxのコピーを作成できるということは、開発やカスタマイズを行ったSandboxを元にテストや検証専用のSandboxをそれぞれ作ることができる、ということです。
開発・テスト・検証などの環境を個別に用意できるので、それぞれ並行しての作業もできそうです。

これから作成する機会も多そうなので、今回は前回作成したSandboxを元にSandboxを作成したいと思います!!

設定の「Sandbox」が…見つからない?!

ログイン中の「TSandbox」の設定で 前回の設定から「Sandbox」へを行ったところ、設定の「Sandbox」が表示されませんでした。

Sandboxの作成は本番組織からしかできないようです。

Sandboxを作成する際は、現在ログイン中の環境がどこかを意識しないといけないですね。

図1 TSandboxの設定で「Sandbox」を検索
図1 TSandboxの設定で「Sandbox」を検索

気を取り直して再度Sandboxの作成に挑戦

本番組織にログインし直して、再度Sandboxの作成に挑戦です。
先ほどと同じように「設定」から「Sandbox」へ移動し「新規Sandbox」をクリックします。

「Sandboxの作成」画面で、作成元をクリックするとすべてのSandbox名が表示されるので、作成元にしたいSandbox名を選択します。
今回は先ほど作成した「TSandbox」を選択します。

図2 作成元にTSandboxを選択
図2 作成元にTSandboxを選択

作成元にSandboxを選択すると、「Sandboxライセンス」が1つだけに変わります。
今回はDeveloperで作成したSandboxを作成元に選択したため、Developerだけが選択できるように変わりました。

SandboxからSandboxを作成する場合は、元となるSandboxライセンスと同じライセンス種別でしか作成できないようです。
作成元のライセンスとSandboxライセンスの残数によっては作成できないことがあるかもしれません。
「新規Sandbox」をクリックする前に「選択可能なSandboxライセンス」の残数も確認した方がいいですね。

図3 選択可能なSandboxライセンスの確認
図3 選択可能なSandboxライセンスの確認

「次へ」をクリックしてからは本番組織からSandboxを作成した時と変わりはなく、同様の手順を踏むことでSandboxのSandboxも無事に作成することができました。

図4 作成元にTSandbox選択後
図4 作成元にTSandbox選択後

しかし、今回のSandbox作成では「待機中」から「完了」まで30分程度時間がかかりました。
作成元のデータ量やライセンスの種類は前回と同じはずですが、それ以外にも作成時間に影響するものがあるのかもしれません。

いずれにせよ、「作成」ボタンを押したあとは気長に待つのが一番です~

もしかしたら…ここでもできそう?

「T2Sandbox」が出来上がるまでの間に、気になっていた「ある」部分を確認してみました。
「TSandbox」の左端にある「コピー」の部分です。

この部分をクリックするとSandboxのコピーができそうだなぁと思っていましたが、どうなるのか気になっていたのでやってみました。

図5 気になる「あの」部分、TSandboxの「コピー」
図5 気になる「あの」部分、TSandboxの「コピー」

クリックすると、「Sandboxの作成」画面に変わりました。
「新規Sandbox」ボタンを押した後との違いは「作成元」の部分です。

作成元はすでに「TSandbox」が選ばれており、Sandboxライセンスも1つのみになっていました。
Sandbox情報を入れればあとはこれまでと同じやり方でSandboxを作ることができそうです。

図6 「コピー」クリック後のSandbox作成画面
図6 「コピー」クリック後のSandbox作成画面

作成元にするSandboxが決まっている場合は「コピー」から作成してもいいかもしれません。
どちらからでも作成できることができるので、好きな方法で作成すればよさそうです。

作成した2つのSandboxを見比べてみる

前回と今回で作成した2つのSandboxをよく見てみると、「T2Sandbox」の右端には「コピー元」の情報として「TSandbox」と書かれていることが確認できます。
「TSandbox」は空白でした。
このことから、何を元に作成したSandboxかわからない時はコピー元を見るとよさそうです。

・「コピー元」が空白 = 本番組織を元に作成されたSandbox
・「コピー元」がサンドボックス名 = 記載のSandbox名を元に作成されたSandbox

図7 作成した2つのSandbox
図7 作成した2つのSandbox

あとがき

前回に引き続いて今回もSandboxの作成でしたが、微妙な違いがあったりで新たな発見がありました。
次回はこれらのSandboxを使用していろいろやってみた様子をお伝えできたらと思いますが、もしかしたら全く違う内容になるかも…?(予定は未定)

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

関連記事
SalesforceでSandboxを作ってみた(1)