【Salesforce】頻繁な組織変更でもスムーズに！人事異動に強いレポートラインの設定事例

こんにちは、社内でSalesforceの改修および運用を担当しているシステム企画部のOです。

弊社はERPとしてSalesforceを利用しています。今回は、Salesforce組織におけるレポートラインの設定についてお話しします。特に、人事異動などの組織変更が頻繁に発生する組織において、システム管理者がどのような作業を行っているのか、具体的な設定方法も交えながら前編と後編に分けてご紹介します。

今回はその前編として、レポートラインの設定方法に焦点を当てて解説します。あくまで一例ではありますが、どなたかの参考になれば幸いです。

本題に入る前に、この記事で使ういくつかの言葉について、簡単に説明させてください。
まず「レポートライン」とは、各ユーザーの上長（マネージャーから管掌取締役まで）が、それぞれどのような決裁権限を持っているかを定めたものを指します。
次に、記事中で何度か出てくる「組織変更」という言葉ですが、これは一般的な組織体制の変更だけでなく、個々のメンバーの人事異動も含めて使っています。システム上では、これらの変更が組織の構造に影響を与えるため、まとめて「組織変更」と捉えています。

当社のレポートラインの設定概要
次回予告

当社のレポートラインの設定概要

弊社の設定の特徴

Salesforceの標準機能では、承認プロセスの承認者としてユーザーオブジェクトの標準項目である「マネージャー」を割り当てることができます。しかし、弊社では縦や横の兼務が多く、また月1回（場合によっては2回）組織変更があるため、この標準機能だけでは決裁者の業務内容や申請内容に沿ったレポートラインを実現することが困難です。日本企業特有の「役職の兼務」は、海外製のシステムであるSalesforceではシステム管理者の工夫が必要な部分かもしれません。

そこで、弊社ではユーザーオブジェクトに複数のカスタム項目を設けることで、この要件に対応しています。また、TeamSpiritを導入しているため、それに付随する勤怠社員オブジェクトにも同様にカスタム項目を設定し、各承認プロセスに合わせた承認者を柔軟に割り当てられるようにしています。

ユーザーオブジェクトと勤怠社員オブジェクトの使い分け

弊社では、承認申請を大きく2つのパターンに分けています。

パターンA: 組織変更後の新しい上長が承認するもの

これは、業務に直結する申請で、人事発令（原則として毎月第一営業日）と同時にレポートラインを更新します。

例: 契約申請、出張申請、採用申請、各種ツールの利用申請など
使用オブジェクト: ユーザーオブジェクト

パターンB：組織変更前の旧上長が承認するもの（TeamSpirit）

これは、勤怠や経費など、会社の締め日に合わせて申請するものです。締め日が人事発令よりも後になるため、承認者は旧上長となります。

例: 勤怠申請、経費申請
使用オブジェクト: 勤怠社員オブジェクト

このように、申請の種類に応じて2つのオブジェクトを使い分けています。

実際の設定概要

パターンA（ユーザーオブジェクトを使用）

上長情報の登録: ユーザーオブジェクトに、マネージャーから管掌執行役員までの上長情報を登録します。
例）Aさんの所属部署のチームマネージャーはBさん、部長はCさん、執行役員はDさん
フローを実行（決裁者情報の登録）: 項目の値更新をトリガーとしてフローを実行し、当社で定めた決裁権限基準に応じた決裁者（チームマネージャー決裁者〜執行役員決裁者）つまり誰がどのような決裁権限を持っているかを設定します。 *1
フローを実行（承認者の登録）: 申請用オブジェクトのレコード作成をトリガーとしてフローを実行し、申請の区分（出張申請なのか人事採用申請なのかなど）に応じて、決裁者情報をもとに決裁権限基準*に応じてレコード内の「承認者」項目に該当ユーザーを入力します。
承認プロセスの実行: 承認申請をトリガーとして承認プロセスを実行し、各承認ステップの承認者を、レコード内の「承認者」項目から取得します。

パターンB（勤怠社員オブジェクトを使用）

フローを実行: 勤怠社員オブジェクトの項目の値の更新をトリガーとしてフローを実行。パターンAで設定した上長情報を勤怠社員レコードの「承認者」項目に反映させます。
承認プロセスの実行: 申請用オブジェクトのレコード承認申請をトリガーとして承認プロセスを実行し、各承認ステップの承認者を、レコード内の「承認者」項目から取得します。