SOEのひとりごと

Salesforce管理者兼エンジニアのSOEがつぶやいてます

【Salesforce業務ネタ】数式のCase文は、Enum的に使うとめっちゃ役立つよ

数式は項目でもレポートでも作れる

Salesforceでは、オブジェクトの項目追加で「数式」を選択することで、行レベルでの数式処理を専用項目として追加することができます。

しかし、わざわざ専用項目を追加することを、設計からして抵抗がある方もいらっしゃるかもしれません!

そういった方には、レポート自体で「行レベルの数式」を作成することをお勧めします!
※ただし、1つしか作れません。

Help And Training Community help.salesforce.com  

レポートの数式の使用例

例えば、次のimg1のレポートを確認してください。
※freeeへのインポート形式を参考にダミーを作成

img1

一見、きれいに作成されているように見えますが、もし商品についても順番通りに並び替えたものが欲しいと言われたばあい、どのように対応するでしょうか?

例えば、「プラン→グループ→API→エージェント→サポート→キックバック」の順番としましょう。
※上記のimg1では、順番はバラバラです。

わざわざ項目を作るでしょうか?

そんなことをしなくても、直接レポートに整列用の数式項目を追加することで対応可能です。

img2

img2では数式の項目をレポート側に作成して、特定の商品名の場合には特定の数字をユニークな番号に連結して作成しています。

下記は数式の設定例です。

Invoice__c.BranchNumber__c
+
CASE(Invoice__c.OrderItem__c, 
    'ライトプラン','-11',
    'スタンダードプラン','-12',
    'エンタープライズプラン','-13',
    'API機能','-22',
    'グループ機能','-21',
    'エージェント機能','-41',
    'サポート','-51',
    'キックバック','-91',
    '-0'
)

おわりに

過去に紹介したデータソートの方法記事もありますので、よければこちらもどうぞです。

Salesforceのレポートで、行レベルの数式だと1つしか作れないっす

タイトルの通りで、Salesforceのレポートは集計や行レベルで数式をオブジェクトの項目に追加することなく設定することができます。

 

⬇️公式ページのヘルプはこちら

help.salesforce.com

 

ただし、行レベルの数式は1つのみしか作成できないようです。

ideas.salesforce.com

【Salesforceの業務効率化】データ分析をあんまりする機会のない方に捧げるレポートとダッシュボードの活用

はじめに

本記事を読んでいるということは、Salesforceに業務などで関わりのあるユーザであると推測します。(何様)

そして、おそらくタイトルにある通り、Salesforceのレポートやダッシュボードの活用や、データ分析というものにあまり馴染みがないものとお見受けします。(だから何様)

そんなあなたに捧げます。

データ分析の一般論

ほい。まずはここからですね!
現在データ利活用に躍起になっている様々な業界では、データベース周りを下記のような構造で整備していることが多いです。
※企業によって多少違いはあります。

画像
img1.データ分析基盤の基本

「おい。なんだこれ。」と思われるかもしれませんが、落ち着いてください。誰もが通る道です。

img1についてですが、まず様々なデータソースを集め、それをデータレイクに格納します。次にデータ分析などに利用しやすいよう格納したデータを綺麗にした上で、データウェアハウスに格納します。そのデータウェアハウスから、必要な分析をするためのデータを切り出して加工したものとしてデータマートというものを作ります。その後、可視化が必要であるなら、データマートの中身をBIツールで可視化することになります。

そして、この構造はクラウド活用を推進しているような大多数の企業でも一般化している基本中の基本となっております。

現代はマシンスペックが年々強くなってきたことで、とりあえず生データを蓄積していくといった「は!?」という使い方が容易に安価にできるようになっています。

データウェアハウスやデータレイクをもっと詳細に知りたい方は下記リンクが読みやすいので、参考までにどうぞです。

Salesforceでの分析

ではSalesforceのレポートとダッシュボードとの向き合い方は何か?
これは簡単です。
レポートはデータマート、ダッシュボードをBIツールとみてください。
構造化された整理データはオブジェクトです。
※あくまで私の感想です

画像
img2. Salesforceのレポートとダッシュボード

そうすることで、「レポートを乱立して作るのとか悪でしかない」という考えに新たな視点を生み出せそうですね。要は無駄なものを作らなければいいだけなんです!

このように、Salesforce版データマートとしてレポートを作成することで、ダッシュボードで複数レポートからのグラフやリストを表示する有用性が生まれるんです!

こう考えることで、Salesforce上でも高度なことを求めなければ分析できそうじゃないですか!?
本来であればimg1のような環境ですと、基本的にSQLなどでクエリを書いたり、データ転送や切り出しのためにプログラミングスキルが必要になったりします。しかし、img2のように、Salesforceの中でのみ必要な作業であるなら基本ノーコードですので不要となるのです。

Salesforceがあれば分析は完璧ってか?

いやそうでもないです。

Salesforceでできる分析は、あくまで”営業情報を中心としたビジネス分析”という範囲となります。

この情報に、他のデータソースとのクロスした分析、より複雑で高度な分析を行い、それをSalesforceに戻すリバースETLといわれる操作が必要な場合には、img1のような構造を整備する必要があります。

その時はもちろん、Salesforceは1データソースという役割になります。

おわりに

Salesforceいいっすよね。

インボイス制度をよく知らない方へ。たぶん怖くないよ。

 

はじめに

大丈夫。落ち着いて。

世間ではインボイス制度のせいで私たちフリーランスの生活が危うい!」というニュースをよく見ますよね?

でも、実際には何がどうなるのかなんて、よくわかってない方の方が多いのではないでしょうか?

 

私もそうです笑

 

ということで、今回はインボイス制度について調べてみましたので、「ぶっちゃけこんな感じじゃん」というラフな感じで共有いたします。

 

内容に誤りがあればご指摘いただけますと幸いです!!

 

インボイス制度って?

2023年10月1日から導入される消費税に関する仕入税額控除の方式です。

そう、、、消費税が対象です。

※正式な文言は国税庁サイトをご確認ください。

www.nta.go.jp

 

さて、それでは何が変わるのでしょうか?

 

従来は、仕入元の課税事業者が仕入税額控除を受けるためには、仕入先から受け取った請求書に記載されたもので控除することができました。

しかし、インボイス制度により、仕入先が発行する「適格請求書(インボイス)」に記載された税額のみが控除の対象となるそうです。

 

ここまでの説明を聞く感じ「え?そんな騒ぐことか?」や「わたし経理ですが、発行手続きだるいっすわぁ」とかの感想を抱くのではないでしょうか?

 

ここからがインボイスなんです!!!

従来、仕入先となる事業者は課税売上高が1000万円に満たない場合、この消費税の納付を免除されてきました。

 

 

 


例えば税込10%で300万円を売上た場合、30万円は課税事業者なら納付しますが、免税事業者なら納付を免除することができました。

それが、10月1日より「適格請求書(インボイス)」が始まると、取引先が発行してくれないと、仕入税額控除ができず、自分のところへ負担が増えてしまうようになってしまうのです。。。

 

ということは、仕入元はこれまで取引していた免税事業者との関係について、課税事業者なりになってもらえない場合は「自社負担が増えても取引する」または「新しい取引先を探す」ということになるんでしょうかね。。。

 

そして、これまで免税事業者だった方は、納付が必要となるため、消費税の分だけ収益が減ってしまうことで、最終的に利益が下がっちゃうのです。

 

うーん、、、きっつい、、、

 

免税事業者は課税事業者になるしかない?

これは業種や自社のビジネスのあり方によるんじゃないでしょうか?

インボイスへの参加は任意ですし、取引先が減るリスクをとるとかも自由です。

※ただし、課税事業者となった日から2年間は、免税事業者に戻れません。

 

 

さらに調べてみるとこちらのサイトでこのような情報を見つけました。

仮に免税事業者を継続した場合、税方式を外税か内税のどちらかを取引先がインボイス対応が必要かどうかで使い分ける方法などもあるようです。

例えばインボイス対応が必要なら内税にして、実質消費税は受け取らないようにしておき、不要なら外税にして受け取っておくなどです。
※素人な私には、これどうなんだろうなとは思いますが、、、

 

そういえば法改正あったのご存知?

令和5年度(2023年です)の税制改正において、免税事業者が課税事業者になり、インボイス発行事業者になったら、納税負担の軽減措置が追加されています。

 

これにより、「売上等で受け取った消費税の2割を納付したらおっけ!」ってのが、期間限定で実施されます。
※2023/10/01 〜 2026/09/30 までの課税期間が対象

www.nta.go.jp

 

言い方を変えれば「それまでにビッグな課税事業者になってくれよな!」というメッセージのようにも見えますね!

なので、現在免税事業者の方は、すぐに課税事業者になればしばらくはなんとかなりそうなので、その間に今後のことについてもっと考えるのが良いかもしれません。

 

他にも支援措置があるそうなので、興味のある方は下記の財務省サイトをご確認ください。

www.mof.go.jp

 

Salesforceのダッシュボード作りは好き?

はじめに

最近思うのです、、、せっかくSalesforceを導入しているのに、なぜGoogle BigQueryなどにデータを転送して、やたらとLooker studioで可視化してしまうのだろうと、、、確かにきちんと分析をするなら外部BIツールでやるべきではあるものの、Salesforce内で完結できる程度のことを外に出す必要ってあるのでしょうか?もしかして使い方がよくわからないとかですかね?

おふざけはここまでにします!

今回はSalesforceダッシュボード作りについて、機能というより素人視点での使いやすさについて思ったことを書いてます!※お得なやつはないかも、、、

もし良ければ、どっちが好きかも教えていただけますと幸いです!

Salesforceダッシュボードの手軽さ

我らがSalesforceダッシュボード 様です!これの最大の特徴は「クエリなんて知らねぇ」と言わんばかりに、ダッシュボードでの可視化をするまでの間に、クエリを使わないことです!

一般的には「オブジェクト」から「レポート」を作成し、複数のレポートの結果を1つの「ダッシュボード 」で見れるようにします。この間、クエリは使いません。※使う方法があれば教えてください、、、

レポートの操作性も、ほぼほぼエクセルやスプレッドシートのように扱えるため、ITに詳しくない方でも容易に利用できるものとなっています!※ただし、列による並び替えは1つしかできない。※ソートライクな使い方でグループなどに設定などが代替案

しかし、ダッシュボード上で操作できることはほとんどなく、何かしらのグラフを表示したり、グラフ名を入力、フィルタ値を作るようなことのみ可能となっており、枠線を引いたり文章を記述するような操作はできません。※あと、ダッシュボードの表示がなんか重い

そして、基本的にSalesforceのデータベース(オブジェクト)から直接データを取り込んで作成するため、データソースはSalesforce内のデータオンリーとなります!

使いどころ

Salesforce内でしか見れないデータで、複雑な分析が必要とかでないのであれば、こちらを使うべきです!メンテナンスも容易で、どこのデータを表示しているのかが楽なのです!

【Salesforce業務効率化】フロー実行結果のメールをSlackに通知して結果をみんなで見れるようにしちゃう

はじめに

Salesforceでフローをリリースする前はデバッグをフローインタビューで容易に見ることができるが、リリース後の本番運用ではエラーを確認するには、メールで確認したり、フローで障害発生時の内容をオブジェクトに集約するといった手間が必要となります。

メールの場合は、受診履歴として残せますが確認がわずらわしくなりますし、オブジェクトに集約する場合は、データ分析に利用するのであれば良いですが、シンプルな管理業務を行う上では不要な設計となります。

そこで、今回はメールで受信した内容をSlackに通知して、情報拠点として集約を実現させることにしました!

SlackとGmaiの連携でできること

SlackとGmailの連携でできること、どうするのかは割愛いたしますので、下記の記事を参考にしてください!

soe-irony.hateblo.jp

 

 

実現方法

お手軽にZapierベース

注)Zapierはフリープランで検証するため、有料プラン契約の方とは完成系が異なる場合がございますので、ご注意ください。

まずすべきはメッセージの受信元の整理です!

Zapierのトリガーで使用するラベルをGmail側に作成しました。
フローで発生したエラーのメール通知については、このようにラベル付することで容易にまとめられます。(いや当たり前か)

画像
img.Gmailのラベル

次にZapierでタスクの設定をしましょう!
今回は下記のように消費タスクは1となるシンプルなものを作成しました。

画像
img.Zapierの設定

設定としては、トリガーでメールを受信した際に、設定したラベルを付けられた場合起動し、内容をSlackに転送するものとなります!

起動すると、下記画像のように通知されます。
※見づらいのは投稿者のセンスの問題です。

画像
img.Slackで確認できるZapierからの結果

おわりに

いかがでしょうか?
可能な限り低コストで、もっと作り込みたいならSlackBotベースでやるのが良いですが、Slackはフリープランで、Zapierもほとんど使わずにフリープランが良いなら今回の方法でも良いですし、使用頻度が増えてもZapierだけ有料にすることで問題ないかと思います。

書き上げてから思いましたが、結局Slackの有料プランで「チャンネルにメールを送信」を使えるのが一番良いような気もします。。。

SlackとGmailを連携して、情報集約楽にしちゃえるらしいで。

チャチャッと紹介します!

SlackとGmailを連携し、メッセージとして送信するためにはいくつか方法があります!
方法自体はSlackの公式ヘルプページにまとめがあり、それによると3つの方法のみとなるそうです。

slack.com

下記は公式ページからスクショしたものです🙇‍♂️

画像

1番の方法をフリープランで本当に使えないのかも念のため確認しましたが、当然の如くダメでしたw

画像

てことで、Slackを有料プランにしているなら1番の方法が最も楽です!
個人事業でSlack有料がいやで、Zapierだけで頑張りたい、またはBotでコストカットなど作り込み希望なら3番!

2番は、メール見るのが苦ではない民がするものですね!

2023年10月以降、建物の解体工事にはアスベストの「有資格者」による事前調査が義務化されるらしい

 

2023年の10月以降は義務化する話

最近、建造物の解体工事をそこかしこで目にしませんか?

 

実は2023年の10月以降は、解体する際にはアスベストの調査をした上で国に報告する義務が発生するらしく、それにより年末の道路工事並みに急ぎで始めているところがあるそうです。

 ※令和5年9月30日以前着工の工事についても、有資格者による調査を行うことが望ましいとはありますが、、、

 

詳細については下記、厚労省の公式ページからご確認ください。

jsite.mhlw.go.jp

 

アスベストを知らない方のために

石綿」と呼ばれる鉱物で、保温断熱材の用途で利用され、使用時も吹き付けるように使用できることから2006年以前までの建築物では多く使われておりました。

 

しかし、2006年以降の建物では使用を禁止されています。

なぜでしょうか?

 

勘の良い方はお気づきでしょう。

そう、健康被害があるからです。

 

このアスベストは繊維状で使用されるため、空気中に浮遊している状態が有害とされており、吸い込んでしまうことで肺に繊維が溜まり、肺ガンなどの発症リスクがあるとされているのです。

※すぐに発症するとかはないらしいですが、それでも不安はもちろんあります、、

 

より詳細を確認したい場合は、下記の厚労省の公式ページからご確認ください。

※個人ブログなんぞよりよっぽど信用できます。

www.mhlw.go.jp

 

 

外部のサイトとなりますが、健康被害がある場合、下記のように相談ができるとか何とからしいです。

www.adire.jp

 

給付金制度

もしアスベストのあるような建設現場で働かれていた場合、2022年1月19日より国から建設アスベスト給付金」という制度が施行されていますので、健康被害があった方は一度相談してみるのが良いかと思います。

 

より詳細を確認したい場合は、下記の厚労省の公式ページからご確認ください。

www.mhlw.go.jp

【Salesforce業務効率化】フローのガバナ制限は“画面要素”で応急処置できるんだぜ?

はじめに

今回は、実際に私がフローを作成したときに稼働を止めないために行った応急処置的なやり方の紹介となります🙇‍♂️

現状、SalesforceはIT経験が少なくても扱える良ツールではあるものの、ガバナ制限のチェックだったりはユーザ側で考えておかないと後々面倒なことになるのです。

本記事は、私同様に初歩的なミスをしたアドミンや、駆け出しアドミンに向けた内容となりますが、何かしら助けになれば幸いです。

フローのガバナ制限とは?

ユーザみんなが使えるように、サーバ側リソースが独占されないようにしている利用制限のことです!

制限は使用する要素や実行時間などが対象で、これはトランザクション単位で行われており、フロー上で制限対象となるような要素を組み込んだループ処理を実行した場合、実行数が多かったり時間がかかる場合は大体エラーで終わってしまいます。
※実行時間は10秒ほどが限界です。

また、トランザクションがガバナ制限に引っかかると、障害コネクタパスが定義されていてもトランザクション全体をロールバックします。

詳しくは下記の公式ヘルプをご確認ください!

ガバナ制限はトランザクション単位

こちらも下記の公式ヘルプからご確認ください!

もし、トランザクションという言葉の意味がよくわからない場合はお手数ですがググっていただくか、下記記事を読んでイメージをつけていただければ!

処置例

前提

それでは本題に入ります。
例えば、下記のimg1のようなフローがあったとします。

画像
img1.フロー

念のため説明です!
上記のフローでは、まず「SaaSアカウントの取得」というレコード取得の要素を実行しています。取得すると110個のレコードが入ったコレクションのため、ループは110回、つまり中のレコード取得は110回実行となります。
これを実行すると、img2、3のようなエラーが表示されます。

画像
img2.エラー
画像
img3.ガバナ制限のエラー

img3のエラーは、ガバナ制限によるもので、100回を超えるSOQLのクエリ実行がある場合に発生します、、、
もし、これが納期直前に考慮漏れとして発覚した場合、考慮した上で処理を変更するのってしんどくないですか?
大規模なデータ処理だった場合とかもう、、、

ってことで、この窮地を脱するために、画面要素を使った一時停止でトランザクションを分ける案が活きてくると思うんです!!!
★公式ヘルプにも書いてるんですがね、、、

対応

それではどのように変更したのかです。
img4をご覧ください。

画像
img4.フローの変更後

ループのレコード取得の要素以降に、割り当て要素、決定要素、画面要素を追加したのがわかるかと思います。

こうすることで、脳筋プレイとなりますが、ループ単位でのSOQLクエリの実行回数以下で、トランザクションを分けられて無事ガバナ制限を回避できます。今回は60回ループで切るように設定しています。

img5、6をご覧ください。

画像
img5.画面要素の表示
画像
img6.実行結果

このように問題なく実行が完了したことがわかります。
もし、画面要素を使う場合は、img5のように状況を表示することで利用者側への多少の精神負荷を減少できると思います。
※それでもだるいことに変わりないが、、、

さいごに

今回紹介した方法は、あくまで応急処置的なものであり、今後も格納データの規模や、処理対象となるデータ量が拡大していくようなフローの場合、手間が増えていく一方のため、恒久的な解決策にはなりません。

しかし、その一方でデータ量が特別多くなく、今後も増えることはない場合は今回の対応以上のことは必要ないと思います。

そのため、他に良い解決策が見つかり次第、対応をしたほうがいいです。

何かしら助けになれましたら幸いです🙇‍♂️

【Salesforce業務改善】Salesforce内のフローを一覧化して、管理を簡単にしよう。

はじめに

注意)すごい役に立つかと言われるとたたない気もします。

なにをしたのか

Salesforce内にあるフローの定義情報の一覧を取得し、それを可視化することでSaesforceアドミンの業務効率化に貢献しようとしています。

やったこと

画像
img0

フローの定義については、上記のように「FlowDefinitionView」というオブジェクトから取得できる。
※実際に取得できるものは下記の公式ヘルプを確認してください。

画像
img1.フローの仕組み

まず、オブジェクトを指定して取得
今回は、取得結果を記録したいので、別途記録ようにカスタムオブジェクトを作成し、リプレイスする形で書き込んでいます。

取得した結果は下記のレポートのようになります。

画像
img2.フロー定義情報を取得したオブジェクトのレポート例

これにより、直接編集ページで見るよりも一覧として見やすくなったかと思います!
さらに、フローは何個あるのかも見えるようになっていますね!

さらにこれをBIツールで可視化し、フロー作りすぎ問題や特定のユーザへの整理依頼をしやすくなります!

今回は、グラフのためにグループ化をするのは避けるため、Looker Studioでちょっとしたダッシュボードを作成します。

作成例は下記のようになります。
可視化目的としては、どのぐらいのフローが有効化されていて、最後に編集されたのはいつか、よく編集するユーザは誰かなどを見えるようにしています。
※編集ユーザにするのは、何かあった時の連絡のため

画像
画像
画像
画像

上記画像のエラーリストについて、こちらは以前紹介した、フローでエラー結果を集計することができるといった記事の内容をBIツールで可視化した例のものになります。

このように、することで、どのフローにどういったエラーが発生しているのかといったノウハウ蓄積や本番稼働時のデバッグ用途に活用できます!

以上!