2019.05.08

【コーディングなし】Lightning フローでアクセス権を付与してみた

  • このエントリーをはてなブックマークに追加
  • follow us in feedly
gettyimages (10366)

はじめましてこんにちは。お久しぶりです1年ぶり。テラスカイの渕上です。
今回は Admin 向け的な感じですかねー?
このブログを読んでいただく方に、少しでもお役に立つことが伝えられれば幸いです。

さて、

標題の通り Lightning フローで、レコードのアクセス権を拡張する仕組みを作ってみたので、その方法を紹介したいと思います!

その前に、Salesforce のアクセス権の拡張方法には、ロール、共有設定、所有者または条件に基づく共有ルール、外部ユーザの共有セット等、いくつか用意されてますよね?
ちなみに共有セットは、ロールベースのコミュニティライセンス ( Customer Community Plus または Partner Community ) も使用できるようになり、基本設計の幅が広がったことと思います。
なお、ある程度柔軟にアクセス権を拡張出来る共有ルールでも、オブジェクト毎に最大 300 件 (最大 50 件の条件に基づく共有ルールを含む) という制限があるので、動的な細かいアクセス権の付与には不向きです。
また2019年3月現在では、Salesforce Classic インターフェースでのみしか「共有」ボタンの使用ができません。
そんな中、カスタマイズレベルで柔軟にアクセス権が操作出来るのは、まあまあ面白いんじゃないかなーと思った次第です!

そもそも、Lightning フローって?

Trailhead の言葉を引用すると、
・Lightning フローは製品名です。
・プロセスビルダーと Flow Builder はツールの名前です。
・プロセスを作成する場合はプロセスビルダーを、フローを作成する場合は Flow Builder を使用します。
とのこと。
ツールとか製品とかの定義はどうでも良いと思う自分の解釈としては、
・プロセスビルダー=トリガー
・フロー (自動起動フロー) =ハンドラー
と思っとけば良いかなと。
一つのオブジェクトに対し一つのプロセスビルダーというルールにすれば順番も制御出来ますしね。

ちなみにコーディングが出来る方は、ApexTrigger による Share レコード の操作は瞬殺かと思いますが、
・Sandbox 組織が要らない
・テストコードが要らない
といった様なメリットはあるかなーと。
但し、本番環境に直接実装する場合、既存データへの影響が無い形での十分な検証は必要です!!

前置きが長くなってしまいましたが、

どんな感じのものを作ったのか、ざっくり説明させていただきます。
シナリオとしては、
・とある非公開のカスタムオブジェクト [PrivateCustomObject__c] が有る
・そのレコードの所有者ユーザの「マネージャ」項目に設定されたユーザにも編集権限を付与したい
といった要件に応える的なものです。あるかはわかりませんが。

①フロー作ります!

フローと変数名等:変数名は社内の DataSpider の命名規約と同じ様な入出力がわかりやすい形式が良さそうだなと

get_sObjectShare:所有者の共有レコードの更新エラーを出したくない為だけです

check_isOwner:所有者じゃない時だけ後続に続きます

set_sObjectShare:レコード変数を使ってみたかったのでここで値をセット

put_sObjectShare:Share レコードは更新処理を別途用意しなくてもこの作成処理だけでOKでした!

あとは有効化すればお終いですー。

②プロセスビルダー作ります!

isChange_Owner:そのままですね。せめてマネージャの有効位は見ようかと‥

"条件を設定"の切れてる部分の補足です。
1. [PrivateCustomObject__c].OwnerId
2. [PrivateCustomObject__c].Owner.User.ManagerId
3. [PrivateCustomObject__c].Owner.User.Manager.IsActive

flow_SharingPrivateCustomObject:フローとその入力変数への値を設定します

こちらも切れている部分の補足です。
・i_parentIdの値:[PrivateCustomObject__c].Id
・i_userOrGroupIdの値:[PrivateCustomObject__c].Owner.User.ManagerId

こちらもあとは有効化するだけです!

注意点としては、

厳密にやるのであれば、PRIORVALUE 渡すとかして削除も必要かなーと思っていたのですが、動作を見ると、常に入れ替わる動きになってました。
Classic インターフェースから手動で共有しても、フロー動かしたら外れてしまうという‥。
だけどフローのデバッグでの動きは、追加される動きで、結局どちらが製品として正の挙動かは分かりませんでした!

あとおまけで、

今回作ったフローをサブフローとして利用する例です!ロール ID からグル―プ ID 取得して、さっきのフローに渡します

get_groupIdByRoleId:ロール ID からグループ ID を取得します

subFlow_SharingPrivateCustomObject:userOrGroupId に取得したグループ ID を設定します。他は同じ変数名で用意しとけば良いかと

最後に、

なんか後半はキャプチャばっかりになっちゃいましたねー。
まあ、見て貰えばわかるかなという感じなので、あまり補足することも無く、それはそれで致し方ないかなあと。
作り自体に改良の余地もあるだろうし、ログが追い辛いとか、フローの機能としてsObject 型が使えたらもっと汎用的になるのになとかIF文の数式位各要素の中で使えたらいいのになとか、思うことは多少ありますが、手軽にかゆい所に手が届き易くなったのかなとかという所感でまとめさせていただきます。
兎にも角にも、最後まで読んでいただき有難うございました!!

あと、題材やアイデア等、ご協力いただいた社内の方々にこの場を借りて謝意を。有難うございましたー!
32 件
     
  • banner
  • banner

関連する記事