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

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でいろいろやってみた中での「ちょっとした気づき」を書いていこうと思います。

Salesforceの削除は、基本的に物理削除ではなく論理削除です。
このことについては多くの先輩方が詳しく説明して下さっているので私からの説明は割愛させていただきます。
論理削除ということで、レコード・カスタム項目・カスタムオブジェクトについて削除した後のデータについて気づいたことを書いていこうと思います。

また、普段Lightning Experienceを利用している場合の内容です。

レコードの削除後

削除後のレコードの行方は?

レコードの削除後、削除したレコードはどこにいくか知っていますか??
削除したレコードは一定期間「ごみ箱」にいます。

間違って削除した!!という時は「ごみ箱」を見てみましょう。

ごみ箱の場所は?

ごみ箱はアプリケーションランチャー内にあります。

左上にあるカラフルな9つの「・」をクリックすると表示されるポップアップの一番下にある「すべて表示」をクリックします。

図1 9つの「・」をクリック後に出現するポップアップ
図1 9つの「・」をクリック後に出現するポップアップ

アプリケーションランチャーが開くので、「すべての項目」を見てみましょう。
「ごみ箱」を見つけることができました。

図2 アプリケーションランチャー内にあるごみ箱
図2 アプリケーションランチャー内にあるごみ箱

削除したレコードはすべてこの「ごみ箱」の中に一定期間保管されています。
間違って削除したレコードはここから復元することができますし、完全に削除することもできます。

図3 ごみ箱の一覧
図3 ごみ箱の一覧

カスタム項目の削除後

削除後のカスタム項目の行方は?

カスタム項目の削除後、削除したカスタム項目はどこに行くか知っていますか??
削除したカスタム項目は一定期間「削除済みの項目」にいます。

間違って削除した!!という時は「削除済みの項目」を見てみましょう。

削除済みの項目の場所は?

削除済みの項目は各オブジェクトの「項目とリレーション」の右上にあります。

削除したカスタム項目は、カスタム項目を作成したオブジェクト詳細の「削除済みの項目」からでしか見ることができないことに注意してください。
レコードとは違い、削除後一か所に集約されているわけではありません。

図4 項目とリレーション右上にある「削除済みの項目」
図4 項目とリレーション右上にある「削除済みの項目」

間違って削除したカスタム項目はここから復元することができますし、完全に削除することもできます。

図5 削除済みの項目の一覧
図5 削除済みの項目の一覧

カスタムオブジェクトの削除後

削除後のカスタムオブジェクトの行方は?

カスタムオブジェクトの削除後、削除したカスタムオブジェクトはどこに行くか知っていますか??
削除したカスタムオブジェクトは一定期間「削除済みオブジェクトリスト」にいます。

間違って削除した!!という時は「削除済みオブジェクトリスト」を見てみましょう。

削除済みオブジェクトリストの場所は?

この「削除済みオブジェクトリスト」ですが、レコードやカスタム項目と違いLightning Experienceでは表示することができません。

ではどうすれば表示できるかというと…

Salesforce Classicだと表示できます!!!

長い道のり

まず、Salesforce Classicに切り替えましょう。

切り替えはプロファイルを参照すると表示される「オプション」内にある「Salesforce Classicに切り替え」をクリックするとできます。

図6 プロファイルからSalesforce Classicに切り替え
図6 プロファイルからSalesforce Classicに切り替え

Salesforce Classicに切り替えるとホーム画面が表示されます。

画面上部にある「設定」をクリックすると、

図7 Salesforce Classicホーム画面
図7 Salesforce Classicホーム画面

次のような設定画面に変わります。

この画面を下にスクロールしていくと左の赤枠部分に「ビルド」が出てくるので、その中の「作成」内に「オブジェクト」があるのでクリックします。

図8 Salesforce Classic設定画面
図8 Salesforce Classic設定画面
図9 「作成」内の「オブジェクト」
図9 「作成」内の「オブジェクト」

カスタムオブジェクトの一覧が表示され、最下部に「削除済みオブジェクト」というのが確認できます。
この「削除済みオブジェクト」ですが、削除したカスタムオブジェクトがない場合、表示されません。

図10 カスタムオブジェクトリスト
図10 カスタムオブジェクトリスト

こちらが探していた「削除済みオブジェクトリスト」です。
やっと見つかりました…!

削除したカスタムオブジェクトはすべてこの「削除済みオブジェクトリスト」の中に一定期間保管されています。
間違って削除したカスタムオブジェクトはここから復元することができますし、完全に削除することもできます。

図11 削除済みオブジェクトリスト
図11 削除済みオブジェクトリスト

おまけ

15日間以上削除されない…?

カスタム項目やカスタムオブジェクトを削除する前、注意事項がかかれたポップアップが出現すると思います。
以下はカスタム項目を削除する前に表示されるものです。

図12 カスタム項目削除時の注意事項
図12 カスタム項目削除時の注意事項

15日を過ぎると、自動的に項目とそのすべてのデータが完全に削除されます。

とありますが…
15日経過後も残っていました~

2021年12月1日に削除した項目が、2022年2月7日の時点で残っていることが確認できます。
約二か月経過していますね!

図13 削除後15日以降も残っていた削除済み項目
図13 削除後15日以降も残っていた削除済み項目

「15日を過ぎると」とありますが、「15日後」ではないのです。
もちろん、15日経過後はいつまでデータが残っているかはわかりませんので、あくまで「こんな事例もあったよ」という参考までに。

もし、15日以上経過後に削除したものを復元したい場合は念のため削除後の各データ保存場所を確認してみたほうがいいかもしれません。

また、15日以上経過していても完全削除されているとは限らない、という点は留意しておいたほうがいいと思います。

念のため復元できるか試したところ、復元できました!!

図14 削除済み項目復元
図14 削除済み項目復元

あとがき

今回きっかけとなったのは、削除したものの復元のためではなく、削除したものの完全削除のためでした。

データが残っている状態だと作業が進まず、完全削除を行おうにも「削除済みオブジェクトリスト」がみつからなかったのです。
私がSalesforceに携わった時には既にLightning Experienceが存在したので、Classicはあまりなじみがないのも原因ですぐに見つけることができませんでした。

プロファイルの設定を行っても一部権限が付与されている場合はSalesforce Classicに切り替えるスイッチャを非表示にできません。
今まで何故だろう?と思っていましたが、まだLightning Experienceで使用できない機能があるからなのだと身をもって体験でき、いい勉強になりました。

カスタムオブジェクトやカスタム項目の作成は近いうちに「やってみた」で書いていこうと思います。

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

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)

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

Salesforceでやってみた

はじめに

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

今回は、Salesforceの開発環境であるSandboxを作成してみようと思います!!

Sandboxを作ってみた

設定から「Sandbox」へ

本番組織にログインし、設定からクイック検索に「Sandbox」と入力し、「Sandbox」を選択します。

左の設定メニュー内にある「環境」の下に「Sandbox」があるので、検索して見つからない場合は「環境」の中を見てみるといいかもしれません。

「環境」を見ても見つからない場合は…こちらを見たら解決するかもしれません。

図1 設定のSandbox
図1 設定のSandbox

作成するSandbox情報の入力

表示される画面に「新規Sandbox」があるのでクリックします。
すると、「Sandboxの作成」画面に変わるので、これから作成するSandbox情報として名前や説明などを入力していきます。

今回作成するSandbox名前は「T_Sandbox」にしてみました。(「T」は「test」の頭文字です、安直ですね)
説明にはどんなSandboxであるかが自分以外の人が見てもわかるような内容を簡単に入れておきます。

Sandboxの名前や説明は作成後に変更できないので、スペルミス・説明の書き忘れがないようにしましょう。
(Sandboxの名前は後々、使用することになるので特に注意)

図2 Sandbox情報の入力
図2 Sandbox情報の入力

Sandboxライセンスの選択

名前と説明を入力後、下にスクロールしていくとSandboxライセンスの選択があります。
作成できないSandboxライセンスには「次へ」が表示されないようです。

今回はDeveloperで作成したいので、一番左にある「次へ」をクリックします。

図3 Sandboxライセンスの選択
図3 Sandboxライセンスの選択

まさかのエラー?!

ここで早速エラーが出ました(泣)
Sandboxの名前は「英数字のみ」しか使用できないようです。
「_(アンダーバー)」が使用できない点は注意が必要ですね。API参照名などでは 「_(アンダーバー)」 が使用できるので、Sandbox名でも使用できるものだと思ってしまいました。

気を取り直して、名前を「TSandbox」に変更し「次へ」をクリックし直すと無事次の画面に遷移することができました!

図4 名前欄エラー表示
図4 名前欄エラー表示

Sandboxオプション

画面遷移先はSandboxオプションでした。
今回はSandboxオプションは空白のままで「作成」をクリックします。

Sandboxを有効化後にApexクラスを実行したい場合はApexクラス名を入力しておくといいみたいです。

図5 Sandboxオブション
図5 Sandboxオブション

作成完了!!

これでSandboxの作成は終了です。初めての作成でしたが、思っていたより簡単にできました!!
「作成」をクリックした後は設定の「Sandbox」に戻ってきましたが、一番下に先ほど作成した「TSandbox」を確認することができました。

作成直後は状況が「待機中」ですが…

図6 Sandbox作成:待機中
図6 Sandbox作成:待機中

少し時間をおいて再度、設定の「Sandbox」見てみると状況が「処理中」に変わっており…

図7 Sandbox作成:処理中
図7 Sandbox作成:処理中

最終的に、状況が「完了」になりました。
完了になると左に「ログイン」が表示されるようになったので、ここから新しく作成したSandboxにログインすることができます。
無事に作成できてよかった~

今回のSandbox作成では、「待機中」から「完了」に至るまで10分ほどでした。
しかし、作成時間は作成元のデータ量や作成するSandboxライセンスの種類により数分から数日まで変動するようです。
「処理中」からなかなか進まない時は別作業を行いつつ気長に待ってみましょう。

今回は画面で「完了」までを確認しましたが、通知メールも送られてきますので画面とにらめっこしなくても大丈夫ですよ!

 図8 Sandbox作成:完了
図8 Sandbox作成:完了

作成したSandboxにログインしてみた

ログインしてみた

早速、先ほどの画面に表示されている「ログイン」をクリックして、作成したばかりの「TSandbox」にログインしてみようと思います。

ログイン画面のユーザ名は「本番組織のユーザ名」+「.[サンドボックス名]」になっています。
大文字小文字は区別されないようで、今回は「 [本番組織のユーザ名] .tsandbox」になっていました。

図9 TSandboxログイン画面
図9 TSandboxログイン画面

認証を済ませると、ついに先ほど作成したSandboxへログインできました!!
画面上部に本番組織にはなかった「Sandbox: TSandbox」という表示が確認できます。

本番環境もSandboxも基本的に表示内容は同じなので、画面上部の表示があるかないか、あるとしたら名称は何か、で現在ログイン中の環境を判断することになると思います。
Salesforceで本番環境や複数のSandboxをいったりきたりするとたまに自分が今どの環境にいるかわからなくなるので、そんな時は落ち着いて画面上部を確認してみましょう。

図10 Tsandboxログイン後
図10 Tsandboxログイン後

あとがき

今回はSandboxを作成してみましたが、Sandboxの名前に記号が使えないなど気づきや学びがありました。
些細なことですが、こつこつ知識を積み重ねていきたいと思います。

また、無事に作成したSandboxにログインできたので、ちゃんと作成されていた確認もとれて一安心しました。

次回はSalesforceでSandboxを作ってみた(2)でお会いしましょう!!!