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

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 アップロード後の変更セット詳細画面

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

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

が挙げられます。

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

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

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

あとがき

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

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

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

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

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

AWS CLIで情報を出力しようEC2編(Linux版-その1)

1. AWS CLIを利用すると色々なリソース情報が見れます!

AWS EC2をコンソールから作成し、管理するサーバが多くなったら、一覧が欲しいですよね。
コンソールでは、分かり難いし、一覧を管理したい。そこで、AWS CLIコマンドを利用すると
EC2のリソース情報を取得し、且つ、必要な情報に絞って出力するように出来ます。
今回はEC2の情報を出力してみます。

2. まずはAWS CLIをインストールしよう!

Linuxのコンソール画面で以下のコマンドを実行してインストールします

$curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o "awscliv2.zip"
$unzip awscliv2.zip
$sudo ./aws/install

3. AWS CLIを使ってみよう!

3.1 AWS CLI のバージョンを確認する!

aws --version
aws-cli/2.4.15 Python/3.8.8
 
最新でなかった場合はバージョンアップしましょう
バージョンアップ方法は以下です

3.2 AWS CLIのバージョンアップ方法!

curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install --update 
aws --version
aws-cli/2.4.29 Python/3.8.8

2022/03/28時点で最新バージョンです
詳しくは、以下を参照 AWS CLI 最新バージョンをインストールまたは更新する https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html

3.3 利用中のリージョンでec2 インスタンスの情報をすべて出力してみよう!

利用中のリージョンに存在するEC2インスタンスのすべての情報を出力するには以下のように記述します SQLの  select * from ec2 みたいなものです

aws ec2 describe-instances

画像A 出力結果
                 画像A 出力結果

Json形式で どばーっと出力されます

3.2 出力する情報を絞りこんでみよう!

上記コマンドでは沢山の情報が出力されるのでqueryオプションを使用して情報を絞り込みます
Sqlの select name,OS from EC2 みたいなものです。EC2名とOSに絞り込みます

aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[{OS:PlatformDetails,Name:Tags[0].Value}]" \
--out table 

画像B 2項目出力
                画像B2項目出力

queryオプションの設定は以下のようになります
Json形式で出力されるので、これを踏まえて絞り込む内容を記述します
まず、Reservations[*].Instances[*]   (画像C 階層) トップレベルがReservations
一つ下の階層がInstances これがリスト[]になっているので、
すべてを対象にする為に、Reservations[*].Instances[*] と指定します
更に下の階層(画像D PlatformDetails項目)の値と、
同じ階層にある(画像E Name項目)Tags:[0]リストの最初の項目Value値 を指定します
.[{OS:PlatformDetails,Name:Tags[0].Value}]
{key1:value,key2:value}のdict形式にフォーマットして、項目名と値を出力するようにする
--out table テーブル形式にすることで見た目が分かり易すくなります

画像C 階層
                  画像C 階層
画像D PlatformDetails項目
              画像D PlatformDetails項目
画像E Name項目
                 画像E Name項目

2.3 出力項目を増やしてみよう!(インスタンスタイプ)

aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[{OS:PlatformDetails,Name:Tags[0].Value,Type:InstanceType}]" \
--out table

画像F 3項目出力
                 画像F 3項目出力

追加したqueryオプションの設定は以下のようになります
[{OS:PlatformDetails,Name:Tags[0].Value,Type:InstanceType}]"
下の階層の (画像G Instancetype項目) の値を追加して、出力するようにする

画像G InstanceType項目
               画像G InstanceType項目

2.5 出力形式をTEXTに変更してみよう!

aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[{OS:PlatformDetails,Name:Tags[0].Value,Type:InstanceType}]" \
--out text

画像H Text形式
                 画像H text形式

Text形式で出力して、情報を加工し易くすることが可能になります

4 応用してみよう!

利用可能なインスタンスタイプ、アーキテクチャ、仮想化、プロセッサー、Hypervisorを
出力しよう。インスタンスタイプの変更可否(互換性)を確認したい場合に重宝します。

aws ec2 describe-instance-types \
--query "InstanceTypes[*].[{InstanceType:InstanceType,Hypervisor:Hypervisor, \
CPU:ProcessorInfo.SupportedArchitectures[0], \
Clock_Ghz:ProcessorInfo.SustainedClockSpeedInGhz}]" \
--out table

                 画像I 出力結果

5 感想

query を利用することで、必要な項目を絞ることができました。 jqを利用しても可能ですが、こちらを利用しても、同様のことができそうです。最初は書き方に悩みましたが、pythonのlist[],dict{}を連想すると、分かり易いです。次回はRDSの情報出力についてです。

参考URL AWS CLI の query による絞り込み
https://qiita.com/draco/items/fa09ae0c2f51de9de449

Linux版その2 RDSの情報出力  https://opt-p.co.jp/blog/aws/post-1718/

Linux版その3 VPCの情報出力  https://opt-p.co.jp/blog/aws/post-2080/

Linux版その4 色々な情報出力 https://opt-p.co.jp/blog/aws/post-2421/

健康保険委員研修会

こんにちは!株式会社オプトプランニングです。

2022年3月11日金曜日、協会けんぽ広島支部様主催、令和3年度の健康保険委員の研修会があり、
当社も委員全員が受講しました。

コロナ禍ということもあり、2年ぶりの開催で、オンラインでの講座となりました。
オンライン会議は、どこでも、もうすっかりおなじみですね。

さて内容は、

①実務研修
②運動講座「かんたん美姿勢YOGA教室」
③メンタルヘルス講座「睡眠のチカラ」

の三部構成で全部で2時間の内容でした。

実務研修の中で筆者の印象に残ったことは、広島県の女性の健康寿命が低く、全国の47都道府県の中で44位で、かなり低いということです。

健康寿命を延ばすには、運動、栄養、早めの受診が必須とのことですが、
何かないと受診をしない県民性が反映しているとのこと。
まずは、個人からですが、何か不調があれば早めの受診を心がけようと感じました。
軽い症状のうちに受診したほうが、治療期間も短く、結果、医療費も抑えられることに繋がるとのことです。

運動講座のヨガ教室では、簡単にできる姿勢に挑戦!
思った以上に体が硬い!先生のポーズには驚きの連続でした!

最後に、メンタルヘルスですが、良質な睡眠は摂取する栄養にも関連するとのこと。
栄養、運動、メンタル、すべてが健康維持に重要な要素ですね。

今回受講した内容は社内報に掲載し、情報を共有し、
健康な会社人としての毎日につなげていきたいと思います!

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

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 アップロードエラー画面

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

あとがき

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

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

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

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

認知症サポーター養成講座

こんにちは!株式会社オプトプランニングです。

突然ですが、皆さんは「認知症サポーター」をご存知でしょうか?

先日、当社はこの養成講座を受講しました。
取り組んでいる健康経営の一環として、またシニア採用戦略における予備知識として、
「健康で働ける時間を長く維持したい」、「若年性認知症について正しい認識を持ちたい」という経緯での受講となりました。

コロナ禍ということもあり、オンライン開催となりましたが、当社には大型画面があります。おかげで大変快適な環境で受講することができましたよ。


はじめに、実際の現場でホームヘルパーとして働かれている講師の方から「認知症とは?」というお話から始まり、「認知症」と「物忘れ」の違いや具体的な症状、そして、認知症の人への対応方法について教えていただきました。

認知症の人への対応で大事なことは、『3つの”ない”』ということでした。

①驚かせない
②急がせない
③自尊心を傷つけない


これは認知症の人だけでなく、子供やお年寄りの方へ接する時にも大変効果的なことだそうです。
普段から心掛けたいですね。


後半は、広島市幟町地域包括支援センターの職員の方から、広島市の認知症ガイドブックをもとにお話を伺いました。
実際、家族が認知症になったらどこに相談していいのか、どのような支援があるのか、など具体的なお話を伺うことができ、いざという時に大変役立つものだと感じました。


高齢化社会の中で、長く健康で、生き生きと働くために、自身の努力はもちろんですが、周りのサポートがあればさらにすばらしいですね。社内にとどまらず、家庭や地域の中でも助け合い、重要なことだと思います。

この度は、正しい知識を専門家の皆様から学ぶことができました。
お互いを思いやる気持ち、社内から広げていきたいです!

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

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)でお会いしましょう!!!

来年のカレンダー

こんにちは!株式会社オプトプランニングです。

早いもので、12月も中盤をすぎましたね。
市内でも気温がぐっと下がってきた今日このごろです。

さて今日は、当社の来年のカレンダーを紹介します!

2022年のカレンダーは、卓上型です!
しかも、2ヶ月分表示タイプです。
カラフルでコンパクト、2ヶ月分のスケジュールを見ることができ、
それぞれめくることができますので、大変便利だと思います。

今までの3ヶ月連続カレンダーも、実はかなりご好評いただいていたのですが、
こちらもお配りすると、大変喜んで頂いています。
ちょっと珍しいかもしれませんね。

ぜひ、お手に取っていただきたいと思います!