要約

  • Salesforceはカスタム項目の削除時に、必須入力と一意性の属性を外す。復元後、必要な属性は改めて設定する。
  • 復元した数式項目は無効のままで、編集して保存するまで計算結果を返さない。変更済みレイアウトや削除された依存関係にも復旧作業がある。
  • 項目とデータを取り戻せるのは、組織による完全削除か15日経過の早い方まで。新しい項目枠を求める整理が、その選択肢を先に閉じることがある。

Salesforceの公式サポートには、項目を完全削除したのに新しい項目を作れない場合の手順がある。そこで求められるのは、組織ID、本番環境か検証環境かの確認、そして物理削除の承認だ。しかも、その処理を一つのオブジェクトに絞ることはできない。カスタム項目の物理削除は組織全体が対象になる。

この公開されたサポート手順は、復旧や整理の画面に収まりきらない仕事をよく表している。困っている場所は一つでも、決めるべき範囲はそこより広い。項目を戻す側にも似た食い違いがある。戻ってきた列と値を見て終わりにすると、その列が止めていた誤入力を見落とす。

削除済み項目の属性を手動で復元する公式説明は明快だ。カスタム項目を削除すると、一意性と必須入力の属性が自動的に取り除かれる。復元後に必要なら、設定し直す。Salesforceは値を返すが、その値に課していた二つの条件まで同じ操作で返してはくれない。

企業が買い直すことになるのは、操作の数分だけではない。「この番号は、なぜ重複してはいけなかったか」を覚えている人の時間も要る。復旧の完了条件に入れなければ、その作業はデータを使う部署へ回る。

戻った値より、拒否される値を見たい

仮に、注文の識別番号の重複を、この項目の一意性で防いでいたとしよう。復元時にはその属性を戻す仕事が残る。別の入力規則で重複を止めている構成なら、そちらも確かめる。保存済みの項目定義があれば、どの制御を買い戻すべきかを絞れる。

過去の番号が並んでいることと、次の番号が重複した際に保存を止めることは、別の結果である。必須入力も同様だ。古いレコードが埋まっていても、新しいレコードを空欄のまま保存できないとは限らない。

この違いは、受け入れに誰が参加するかを決める。管理者は設定を扱える。注文を照合する担当者は、番号が重なると何を調べ直すことになるかを知っている。業務の責任者は、どの空欄が後工程を止めるかを説明できる。復元操作だけで終わらせると、その知識が合流する場を失う。

必要な属性を戻さないまま入力を再開し、重複が発生すれば、注文を扱う担当者が番号を照合し、入力者へ問い合わせ、集計の差を説明することになる。管理者の復旧票は閉じていても、業務側の修正作業は残る。復旧時間だけを集計すると、別部署へ渡したこの時間が費用から消える。

受け入れでは、正しい入力が通ることと、禁止していた入力が拒否されることの両方を見るべきだ。データが戻った画面は安心を与える。適切なエラーは、ルールが戻った証拠を与える。

数式は帰ってきても、まだ勤務を始めない

削除済みカスタム項目の管理によると、数式項目は復元後も無効になっている。編集して保存するまで、値の代わりに #Error! が表示される。保存時に構文が確認され、問題があれば修正する。

数式の定義が残っていることと、必要な結果を計算していることを、復旧報告では分けたい。業務が欲しいのは定義の在庫ではなく、それを使った結果だからだ。

名前にも削除の跡が残る。開発者名の末尾には _del が付加される。同じ開発者名の削除済み項目がある場合は例外だが、付いた文字は復元後も残る。画面上の見覚えのある表示名だけで原状回復を判断せず、実際の開発者名と、それを使う設定を照合する必要がある。

検索への反映にも短い時間差がある。項目とデータを復元しても、すぐには検索結果に現れない。検索で見つかること、計算されること、誤入力を止めることは、それぞれ別に確認すべき状態である。

手動復旧は、削除中に変わった場所にも及ぶ。その間に変更したページレイアウトには項目を追加し直す。編集していないレポートやレイアウトには、復元した項目が残る。削除された項目の依存関係は再定義が必要で、関連を主従関係へ戻すには対象レコードに必要なデータをそろえる条件もある。

項目が不在だった間、周囲の仕事は止まっていなかったかもしれない。以前の定義と変更記録を残す価値は、戻すものと戻す先の両方を把握できることにある。

「使用場所なし」の画面が知らない仕事

削除前には、項目の使用場所を探す機能が役立つ。「Where is this used?」から、レイアウト、数式、Apex、有効な入力規則、レポートなどの参照を確認できる。

ただし、公式説明は見えない範囲も列挙している。外部キーの関係を経由する一部のレポート参照は出てこない。問い合わせる人にアクセス権がないレポートも返されず、結合レポートは対象外だ。パッケージのインストール先組織では管理パッケージ内の既存参照が表示されず、インストール後にその組織で追加した新しい参照は表示される場合がある。表示件数も、参照の種類順に並んだ最初の2,000件までである。

空の一覧に、企業全体の「誰も使っていない」という承認までさせるのは荷が重い。とりわけ私有のレポートやパッケージに散った用途は、復元のときに人を探して聞き直すと高くつく。

一方、削除の正式な条件では、他の項目、項目更新やApexから参照されているカスタム項目を削除できない。バックグラウンド処理が更新中の場合も、終わるまで削除ができないことがある。製品のこうした制約が既知の衝突を止めることと、企業が用途を把握することは、両方必要だ。

新しい項目のために、戻れる時間を捨てるのか

新しいプロジェクトが項目枠を求めているとき、削除済みの一覧は空き地に見える。ところが、カスタム項目の上限にも項目種別の上限にも、完全削除が終わるまでは数えられる。そこで早く消すよう求める担当者と、元の業務で必要だったかを調べる担当者が、同じ判断の席に着く必要がある。

前者が得るのは将来の設定枠であり、後者が手放すのは項目とデータを取り戻す機会だ。15日という期限内でも、組織が先に完全削除すれば回収の機会は終わる。新規プロジェクトの着手日だけを見て承認すると、まだ調べ終わっていない用途まで整理済みにしてしまう。

Purgeの説明は、準備済みの項目を完全削除の処理へ送る操作を示している。開始と完了は別であり、処理時間はシステムの負荷に左右される。進行状況はバックグラウンドジョブで確認できる。復元の可能性を手放しても、その瞬間に新しい枠が使えるとは約束できない。

一つのエラーに、組織全体の承認を渡す前に

冒頭のサポート手順が扱うのは、完全削除後も項目作成時のアクセスや空き列に関するエラーが続く状態だ。文書には対処の依頼内容と処理範囲が記載されている。利用企業の名前や損失額は載っていない。

注目すべきは、物理削除の対象を特定のオブジェクトに限定できないという条件である。一つの営業用オブジェクトで項目を増やしたいとしても、その担当者の都合だけでは承認の根拠が足りない。他の場所に残る削除済み項目の用途と、復元を必要とする担当者を確認してから、組織全体の処理を引き受ける。この段階では、最初にエラーを見た人と、放棄する選択肢の責任者が同じとは限らない。

復元する項目については、受け入れを具体的な値まで下ろせる。先ほどの仮の注文番号なら、新しい番号は保存でき、一意性が必要な番号の重複は拒否され、必須の値を空にすれば保存が止まる。数式を使う業務なら、期待する計算結果も返る。

古い値が見える画面だけなら、管理者一人でも確かめられる。次の注文を止めるべき場面まで確かめるには、その注文を扱う人が要る。復旧の完了印は、仕事を引き受ける側にも渡しておきたい。