menu
%}

Salesforce管理者向け 年度替わりの作業(後編) ~当日の作業~

 2018.05.29 support_service_team

こんにちは、アドミニストレーターの下重です。

会社の会計年度が4月始まりの企業において、Salesforce組織のシステム管理者として私が実際に経験した調査や作業について紹介します。今回は後編ということで、年度替わり前夜〜当日に行う作業について説明していきます。 

当日までに行う準備や調査作業について紹介したブログSalesforce管理者向け 年度替わりの作業(前編)~当日までの準備~も参考にしていただければ幸いです。

前回のおさらい

Salesforceシステム管理者に任命されたあなた。上長から、「3月末で年度が切り替わるんだけど、Salesforceでやることあれば準備進めておいてよ」という、ざっくりした指示を受けたとします。

前提条件

「 3/31~ 4/1 」にかけて定常勤務時間外に年度替わりに伴う本番作業が行われると仮定します。
準備期間は「 3/1 ~ 3/30 」までの約1ヵ月間仮定します 

当日までに、こんな準備作業を行いました。※前編参照

  1. 不足ライセンス数の調査
  2. 年度替わり作業実施時のサービス停止時間帯の検討
  3. 企業の組織変更に合わせたロール構成の検討・変更
  4. レポート・ダッシュボードの変更内容の検討
  5. Salesforce利用ユーザの検討
  6. レコード所有者の変更内容検討

それでは、当日作業を紹介していきます。

年度替わり当日の作業

Salesforceの年度切替作業は「準備」と「当日作業」では圧倒的に「準備」の方が大変です。「当日作業」はしっかりと計画された “タスク一覧” をもとに作業を黙々と こなしていけば良いだけですので。

①サービス停止

システム管理者である私は、3月31日の夜から4月1日の朝にかけて作業を行いました。 想定通りの時間帯にサービスが停止されるように、3月31日の夜(作業開始前)までにはログイン制限の設定を完了させましょう。 

プロファイルのログイン時間帯制限機能を使ってこれを実装しました。

サービス停止

上記は月曜日の夜から火曜日にかけて作業を行うときの設定です。

【ポイント】
再開する日の時間設定は、作業が完了するまでの間は「終日ログイン不可」に設定しておくと良いです。作業が予定より伸びてしまった場合、再開時間を再設定するのは面倒ですので。

②承認プロセスの代理承認

私の担当する組織では、承認待ちの申請データがあった場合、 年度替わりで承認者・申請者が異動してしまい、承認されずに残ってしまうことを避けるため、 このタイミングですべての代理承認を済ませてほしいと依頼されており、暫定措置として以下の対応を行いました 

以下のように「代理承認の実行」作業を行います。 

1. 承認待ちとなっているプロセスの検索
「承認プロセスの一括移行」から承認待ちの申請データを検索します。

承認プロセスの代理承認

2. 代理承認の実行
検索結果から代理承認を実行します。

代理承認の実行1

代理承認の実行2

代理承認の実行3

【ポイント】
もちろん直接ユーザが承認することが望ましいので、予め年度替わりまでに承認を済ませてもらうように周知しておくことをおすすめします。実際に代理承認を行う際にはコメント欄にその旨を記載しておくと親切です(「○○期年度替わり時の代理承認」みたいな感じでOKです)。

③共有ルール、ワークフロー、入力規則などの変更

ロールの変更に伴い、共有ルール、ワークフロー、入力規則などの変更が必要な場合は、このタイミングで変更を行いましょう。※ワークフロー、入力規則については条件にロール名を指定している場合などに変更が必要になると思います。

【ポイント】
その他、ホーム画面のレイアウトや、メールテンプレートの変更などもこのタイミングで行いましょう。不要なワークフロールールや、入力規則などがあれば、年度替わりを期に無効化するのもよいでしょう。

④ユーザ情報の変更

年度替わりに伴い、人の異動がある場合、Salesforceを利用する部署から利用しない部署への異動、またはその逆もあると思います。準備作業で作成したCSVファイルを使用してデータローダで一括反映していきましょう。

ユーザ情報の変更

【ポイント】
無効化/更新/新規のCSVファイルを用意して3回に分けて実施すると確認しやすいと思います。その際は、「新規」より先に「無効化」を実施しましょう。ライセンス数に余りがない場合、不要ユーザを無効化してからでないと新規ユーザへのライセンス割り当てが実施できませんので。

なお、データローダ作業を実行する際は、事前の準備段階でSandbox環境を利用した「リハーサル」を必ず実施されることをお勧めします。 

⑤公開グループメンバーの変更

ユーザの変更が完了したら、公開グループに割り当てている「ユーザ」「ロール」「ロール&下位ロール」についてもこのタイミングで変更していきましょう。

公開グループメンバーの変更

【ポイント】
事前に公開グループごとの設定内容を資料にまとめ、該当部門への内容確認を済ませておくと、スムーズに作業が進めることができます。

⑥レコード所有者の変更

私の担当する組織では、年度替わりでの組織変更や人の異動に伴い、ユーザの所有する商談データについて、次の担当者へ引き継がれることが多発します。そのため、商談所有者を一括で変更してほしいと依頼されます。

準備作業で作成したCSVファイルを使用してデータローダで一括反映していきましょう。もちろんレコードの所有者は画面からも変更可能ですので、ユーザに対応してもらえるようであればお願いするという手もあります。

レコード所有者の変更
【ポイント】
年度替わり当日までに引き継ぎ先のユーザが確定できないこともあると思います。度替わり当日とその1~2週間後ぐらいの2回に分けて実施するようにするとスムーズに進められると思います。

⑦積み上げ集計項目の一括再計算

私の担当する組織では、積み上げ集計項目に「当年度」や「来年度」の合計を集計するために日付(期間)を指定しています。年度替わりに伴い、積み上げ対象期間として指定している日付(期間)を変更します。
変更したあと、「積み上げ集計項目の一括再計算」を実行することで全てのレコードに対して積み上げ集計項目の値を最新化させます。

積み上げ集計項目の一括再計算

⑧不要なコンポーネントの削除

事前にユーザへ告知した上で前年度まで使用していた以下のコンポーネントを削除していきます。

  • ロール
  • レポート・ダッシュボード
  • レポートフォルダ
  • ダッシュボードフォルダ

その他、不必要になった公開グループなどありましたら、このタイミングで削除しましょう。

【ポイント】
ユーザによっては、当該画面へのブックマークを作っている場合もあります。いきなり削除してしまうと現場が混乱します。必ず変更や削除の告知をした上で実施します。 ユーザへの影響がないものに関しては、当日削除をやらなくても翌日以降にゆっくり削除でOKです。 ユーザが新しいレポートやダッシュボードにアクセスしていることを確認できたタイミング(23週間後等)で実施するのも良いかもしれません。 

その他注意すること

Sandbox環境を利用できる状況であれば(Full Sandboxがベスト。契約がない場合はPartial Sandboxなど)、事前にひととおり当日作業のリハーサルを実施するとよいでしょう。準備中に気づけない「落とし穴」が見つかります。

たとえばこんな「落とし穴」が……

  • 商談所有者を変更しようとしたが、はるか昔に登録された商談データで、最近追加した入力規則に引っかかってしまって更新できない。
    → 正しい値に更新してもらうのは後回し、いったん入力規則を無効化して、所有者変更だけ済ませましょう。
  • データローダで一括で更新しようとしたら、タイムアウトエラーやガバナ制限エラーが発生してしまう。
    → そんなときは少し手間ですが、CSVファイルを分割したり、データインポートウィザードを試してみてください。ワークフロールールを起動しないでデータ更新してみましょう。
  • 予定していた時間内に作業が終わらない。
    → リハーサルでかかった時間を参考に、当日のスケジュールを作成しておくと焦らずに作業できます。

実際にやってみないと気づけない障害が発生しますので、リハーサルを実施することを強くおすすめします。

また、Sandboxでのリハーサル実施時は、必ず「メール送信機能や「自動化機能」を停止した状態でリハーサルします。 データローダを実行したことで、プロセスビルダーやワークフローなどの「メール送信アクション」が図らずも起動して、予期せぬ外部メール送信が発生する、というインシデントを防ぐために必要なことです。 

以上、私の担当組織で実際に行った年度替わりに伴う作業についての紹介でした。みなさまの担当するSalesforce組織と照らし合わせながら、参考にしていただければ幸いです。

新規CTA