Salesforceのアクセス権限の設計・実装は難しい
おはようございます、いつきです。
Salesforceは色々なことができるプラットフォームです。今回は人材管理の機能を導入したいというニーズがあり、それに伴った権限設定を考えていきます。
💡人材管理用のシステムを入れた方が早くて安全という話と、やはり柔軟性が高く、開発・運用保守以外の追加コストが不要なSalesforceに機能を実装した方が安くてやりたいことが実現できるというのを天秤にかけて判断しています。ここら辺はまたどこかで記事にしようと思います。
Salesforceのアクセス権限の基本的な構成
Salesforce アクセス権限の基本的な考え方は、わたしの大好きな北爪さんの記事を紹介しておきます。これ以上わかりやすい記事は過去ないと思っています笑
また、この記事も大変わかりやすくまとまっておりました。
人材管理に求められる権限
基本的な構成がわかっても、それを実運用に乗せようとするとそんなに簡単な話ではありません。
今回は採用から、退職までの一連の流れを人材管理として考えます。下図はあくまで一例ですが、管理したい内容によって権限がバラバラになるケースがほとんどです。また、「兼任」のときの実装が悩ましいです。（項目の権限は権限セットで制御するので、あくまでレコード単位の権限を想定しています）
このように権限がバラバラになるため、基本的には主従関係では作成せず、参照関係でオブジェクトを作成していくことを推奨します。
実例を用いたパターン（採用応募から異動・退職まで）
[応募フェーズ]
情シスの応募があった場合は、採用担当と、情シスの責任者が主要で確認をします。この場合、レコードの所有者を「情シスの責任者」に割り当てればほぼ事は済みます。
ただし、途中で情シスより経理の方が向いていそうなので並行して検討したいとなった場合は、所有者を変更するか、レコードを手動共有する必要があります。
[雇用時のフェーズ]：実際に情シスとして雇用が決まった場合、応募のレコードから人材マスタのレコードを作成します。これはリードから取引の開始をするイメージに似ています。
採用担当か、情シスの責任者が人材マスタのレコードを作成します。人事担当が内容を確認して、問題なければ雇用手続きに進みます。
雇用手続きは、人事担当と情シスの責任者が契約管理レコードを用いておこないます。
経理も兼務する場合、手動でレコードを共有する必要があります。
[契約変更のフェーズ]：情シスから、事業側に異動が発生した場合
人事担当が契約管理のレコードを作成し、異動の手続きをおこないます。
異動する際に、人材マスタのデータも更新する必要がありますが、異動前に情シスの責任者が人材マスタを更新できなくなるのは問題が発生する可能性もあるので、注意が必要です。
⚠️情シスの責任者が、自分が上司だった時の過去の契約管理レコードを閲覧できるようにしておく場合は、契約管理レコードの所有者をそのままにし、必要なレコードのみ事業側の責任者に手動で共有します。
不要な場合は、人材マスタと契約管理を主従関係にし、人材マスタの所有者を責任者にしておくのが良いと思います。
基本的な権限設定
基本的な権限設定もかなり悩ましいですが、個人的には共有レコードで制御することを推奨します。
部署の数が多い場合、役職の階層が多い場合、組織図の変更頻度が多い場合に「公開グループと共有ルールの管理をしきれなくなる」ことが背景です。
上記の背景に当てはまらない組織の場合は、公開グループを作成して、条件に応じてレコードを共有するのが最適解だと思います。
その上で、基本的な権限設定は、オブジェクトの共有設定は非公開、共有ルールはなし、横断的な部署（採用、人事、経営）は権限セットでオブジェクト単位に設定、あとは所有者のみ利用できるようにしておきます。
この基本設定では、スタッフの上司になる責任者や、兼務部署の責任者が閲覧できないので、そのあたりを自動化していきます。
脱！手動共有
手動共有を都度するのは大変しんどいので、主に以下の手動操作を自動化していきます。
兼務時の共有
スタッフの異動時の共有
責任者の異動時の共有
事前に部門マスタと、所属履歴というオブジェクトを作成します。部門マスタには、責任者を「ユーザー」オブジェクトで必ずいれておきます。
基本的にはフローを使って、共有レコードを作成するアクションを利用する想定をしています。
共有レコードの作り方は以下の記事にまとめています。
兼務時の共有
兼務時は、所属履歴のコードを追加する操作をトリガーに共有レコードを作成します。もちろん、所属の開始日などをキーにして、タイミングを調整していくのも良いと思います。
スタッフの異動時の共有
スタッフが異動する場合、先に書いた通り元々共有されているレコードをどうするか？ということが検討課題に残ると思います。
たとえば、共有を削除する場合は、契約日（雇用条件の変更日）を元に共有レコードを削除するフローを設定しておきます。
上記フロー図には記載していませんが、契約日に、人材マスタ側の所属履歴も変更して、そこも自動的に共有ルールを変更するなど、関連するレコード権限も適切に変更する必要があります。
責任者の異動時の共有
責任者の異動時は、部門レコードにある「責任者」の項目を変更します。
どこまで自動化するか悩ましいですが、今回は部門マスタに、「責任者変更」ボタンを押下し、画面フローから責任者を更新するような動作を想定しています。
それ以外にも、契約管理レコードに紐づく所属履歴に役職情報を持たせ、契約日が来たら部門マスタに更新するような動作も可能ですが責任者が複数いた場合のエラー処理を考えるのがタイヘンなので、見送りました笑
その他、契約日はだいたい重なるので、デイリーやウィークリーでバッチを回すのもありだと思います。フローでは処理の上限に達するケースもあると思うので、そのあたりは状況に応じて適切な対応を検討してください。
アクセス権限周りはタイヘン
正直、アクセス権限を自前で実装しようとすると結構大変です。
このあたりは専用のアプリケーションを入れる方が安全な場合もあります。実際、わたしが支援しているところにも、Salesforceに評価情報をいれるのは慎重すぎるくらい検討を重ねたいと話しています。
とは言え、実現したい内容と、そもそも実現できるアプリケーションの有無、コスト周りが関わってくるので、Salesforceでやるのもひとつなのかなと思ったりしています。
プロジェクトが進んでいくとアクセス権限の設計もまた新しい気づきがありそうなので、その際はまた記事にしたいと思います。
それではまた来週！
この記事が気に入ったらサポートをしてみませんか？