業務アプリのデータベースで孤立レコードを防ぐ方法

孤立レコードが日常の問題を生む理由

孤立レコードとは、データ自体は残っているものの、責任を持つ担当者やチームが明確でなくなったレコードです。従業員が退職したとき、顧客アカウントの担当が変わったとき、チームが統合されたときなどによく起こります。データはデータベースに残っていても、その周りの作業が止まってしまいます。

たとえば、Mayaに割り当てられたサポートチケットを考えてみましょう。管理者がMayaのユーザーアカウントを削除し、未対応のチケットを別の担当者へ移さなかった場合、それらのチケットがすべての担当者の作業キューから消えてしまうことがあります。顧客は回答を待ち続け、サポートチームは誰か別の人が対応していると思い込んでしまいます。

営業レコードでも同じ問題が起こります。退職する営業担当者が、何十ものアカウント、フォローアップタスク、見積もりを持っているかもしれません。後任の担当者がいなければ、更新時期が過ぎ、新しい問い合わせも放置されます。すでに退職したマネージャーを指している承認依頼も、途中で止まることがあります。

影響は実務に直結します。

• 未割り当ての作業を示すキューがないため、スタッフが期限を逃す。
• 顧客への返信が遅れたり、内容が食い違ったりする。
• マネージャーが、誰がレコードに対応すべきか判断できない。
• レポートに作業量が正しく反映されず、結果が誤解を招く。
• 本来アクセスできない人に、機密データが表示され続ける。

データベースで孤立レコードを防ぐには、担当者をアプリ全体に関わるルールとして扱いましょう。チケットは担当者とサポートチームの両方に属することがあります。アカウントは営業担当者に属し、関連する請求書は経理に属することもあります。ユーザーがアプリを使い始める前に、こうした関係を定義しておきます。

削除されたユーザー、無効化されたユーザー、アーカイブされたレコードは、それぞれ異なる状態です。ユーザーを削除するとアカウントがなくなり、そのユーザーが担当していたレコードとのリンクが壊れることがあります。ユーザーを無効化すれば履歴は残りますが、新しい作業の担当者には選べないようにする必要があります。レコードをアーカイブすると日常の画面からは外れますが、監査、レポート、復元のために引き続き利用できます。

たとえば、完了したサポートチケットは、一定期間が過ぎたらアーカイブへ移せます。一方、無効化された担当者が持つ未対応のチケットは、チームキューや指定された後任者へ移すべきです。この違いを明確にすれば、対応が必要なレコードが誰かの操作なしに見えなくなる事態を防げます。

レコードごとに担当者の意味を決める

フォームや自動化を作る前に、担当者を定義します。それぞれのレコードについて、次のアクションに責任を持つのが個人なのか、チームなのか、システム処理なのかを決めましょう。顧客サポートのチケットは担当者に属するかもしれません。営業アカウントは地域チームに属するかもしれません。定期インポートはシステムアカウントに属することがあります。

担当者が作業に影響するレコードを一覧にします。顧客、リード、商談、タスク、サポート案件、承認、注文、社内依頼などが一般的です。対応が必要ないレコードには個人の担当者が不要なこともありますが、レポートやエラー対応のためにチームやシステムの担当者が必要になる場合があります。

作成者が現在の担当者だと決めつけないでください。この2つの役割は異なることがよくあります。たとえば、コーディネーターがイベント後にリードを登録し、営業担当者がフォローアップを行うことがあります。履歴が重要なら、両方の項目を保存します。「作成者」は誰がレコードを入力したかを示し、「現在の担当者」は今対応すべき人を示します。

担当者の項目ごとに、信頼できる情報源を1つにします。営業画面ではアカウントマネージャーを表示し、サポート画面では別の連絡先担当者を表示すると、いずれスタッフが異なる名前を目にすることになります。担当者の項目はメインレコードに置き、そのレコードが表示されるすべての場所で同じ項目を使いましょう。これにより、スタッフの退職やチーム変更があっても、データベースで孤立レコードが生まれにくくなります。

複数担当にする場合は境界を決めます。「営業とサポート」というラベルは柔軟に見えますが、両方のグループが相手の対応を待つ原因になります。複数の人が閲覧、編集、関与できる場合でも、次のアクションを担当する個人またはチームは1つに決めてください。

項目の横に、その定義をわかりやすい言葉で書いておきます。たとえば、「現在の担当者とは、次回の顧客連絡に責任を持つ人です」と定義します。この一文があれば、構築担当者は明確なルールに従えます。スタッフも一貫した基準で作業を割り当てられます。

業務アプリのデータベース設計では、担当者は確認が必要な関係です。アプリ側で無効な従業員を担当者に選べないようにし、チームに有効なメンバーがいない場合は代替担当者を表示する必要があります。AppMasterでは、Data Designerでこうした関係を設計し、ビジネスプロセスを通じてレコードを作成、更新する際にも同じ担当者ルールを適用できます。

画面を作る前に関係を整理する

ページではなく、レコードから始めます。画面が整っていても、その背後にあるデータのつながりが不明確なことがあります。アプリに必要なレコードを簡単な図にし、それぞれの子レコードを、所有または説明する親レコードにつなげましょう。

顧客サポートアプリでは、1人の顧客に複数のチケットが紐づくことがあります。各チケットには、メモ、タスク、添付ファイル、メッセージが付くかもしれません。チケットはこれらの作業レコードの親であり、顧客はより広い背景情報を提供します。この関係図があれば、フォームやダッシュボードを作る前に孤立レコードを防げます。

作業データと参照データを分ける

参照用のレコードと、進行中の作業を表すレコードは分けて管理します。商品、サービスカテゴリ、地域、ステータスラベルは共有される参照データです。チケット、営業案件、請求書、社内依頼は、特定の出来事や作業を表すデータです。

チケットから商品カテゴリを参照することはできますが、カテゴリがチケットを所有するわけではありません。管理者がカテゴリを削除した場合、アプリは影響を受けるチケットについて代わりのカテゴリを選ぶようスタッフに求めるべきです。カテゴリと一緒にチケットまで削除してはいけません。

各関係をわかりやすい言葉で書き出します。小さな表や簡単な図で十分です。

• 1人の顧客は複数のチケットを持てる。すべてのチケットは1人の顧客に属する。
• 1つのチケットには複数のメモを付けられる。すべてのメモは1つのチケットと1人の作成者に属する。
• タスクはチケットに関連付けられるが、一時的に未割り当てキューに置くこともできる。
• ファイルはチケット、メモ、顧客レコードのいずれかに属し、スタッフが用途を特定できるようにする。
• 1つの商品カテゴリには複数のチケットを紐づけられる。カテゴリ項目が任意なら、チケットにカテゴリがなくてもよい。

空の値を許可する場所を決める

常に存在しなければならないリンクがあります。チケットのないサポートメモは意味を失うため、チケットとのつながりを必須にします。一方、短時間だけ空のままでもよいリンクがあります。新しいタスクは、マネージャーが担当者を選ぶまで未割り当てキューで待機できるかもしれません。

この違いを、業務アプリのデータベース設計に明記します。すべての関係について、空欄を許可するか、アプリが自動入力するか、関連レコードが変更されたときに何が起こるかを決めてください。明確なデータベースレコードの担当者管理があれば、再割り当て、アーカイブ、レポートでのミスが減ります。

関係図が機能することを確認してから画面を作ります。そうすれば、フォームで必要な項目を必須にし、関係のない選択肢を隠し、後で誰も追跡できないレコードの作成を防げます。

新しいレコードのルールを設定する

アプリに入るすべての新しいレコードには、担当者が必要です。スタッフ用フォーム、顧客ポータル、スプレッドシートのインポート、自動ワークフローから作られるレコードも対象です。担当者が空のままだと、たとえ短時間でもフォローアップが抜け落ちることがあります。

レコードの種類ごとに既定の担当先を設定します。サポート依頼はサポートキューへ、新しい営業リードは営業オペレーションチームへ送るといった具合です。既定の担当先は、必ずしも1人である必要はありません。アプリが明確な割り当てルールを適用できるまでは、共有キューのほうが安全なこともあります。

実際の働き方に合うルールを使います。

• 顧客の地域や郵便番号でアカウントを割り当てる。
• 選択された商品を担当するチームへ依頼を送る。
• 営業時間中に新しいチケットをキューへ振り分ける。
• 未対応の作業量が最も少ないチームメンバーに次のリードを割り当てる。
• インポートしたレコードは、確認されるまでインポートを実行した従業員に保持する。

割り当ての理由も保存します。リードレコードに「顧客がOntarioを選択したため、北部営業に割り当て」と記録する例です。これがあれば、マネージャーはルールが正しく機能したか確認でき、スタッフも修正が必要なときに判断しやすくなります。割り当て理由は自由記述のコメントとは分け、後で集計できるようにします。

どのルールにも当てはまらないレコードもあります。フォームに地域が入力されていない、インポートファイルに見慣れない商品コードがある、キュー内の全員が対応できない、といったケースです。こうしたレコードを担当者なしで放置してはいけません。「割り当てが必要」といったステータスを付けた監視対象の例外キューに送り、そのキューを毎営業日確認する責任を指定されたチームに持たせます。

担当者ルールは、レコードを作成する処理の一部として実行します。AppMasterでは、ビジュアルなビジネスプロセスでレコードを作成し、担当者またはキューを選び、割り当て理由を保存し、責任チームへ通知できます。有効な担当者を割り当てるか、レコードを例外キューへ置くまで、処理を完了させないようにします。

これにより、タスクの抜けや顧客からの未回答の依頼が、後で整理しなければならない問題になる前に防げます。

スタッフ変更に備えて再割り当てルールを書く

スタッフの変更があると、数時間のうちに未対応の作業が担当者不明になることがあります。営業担当者が退職する、サポート担当者が別チームへ異動する、マネージャーが育児休暇に入るなど、どのケースにも、誰が引き継ぐのか、何を移すのか、いつまでに対応するのかを定めたルールが必要です。

これまでに作成されたすべてのレコードではなく、進行中のレコードを移します。進行中の営業案件、未解決のサポートチケット、承認依頼、今月が期限のタスクには新しい担当者が必要です。アプリで履歴を保持するなら、成約済みの案件や完了したチケットは、元の従業員とのつながりを残しても構いません。

誰かが不在になる前に、各チームの代替担当者を決めておきます。指定された同僚、チームリーダー、またはマネージャーが整理を担当する共有キューなどです。すべてを汎用アカウントに割り当てるのは避けましょう。そこに置かれた作業は、誰かが対応するだろうと考えられがちです。

再割り当てルールには、次の内容を含めます。

• 退職、役割変更、休暇など、移管を開始するイベント。
• どのレコードのステータスを進行中とみなすか。
• 既定の引き継ぎ先と、その選択を変更できる人。
• 以前の担当者、移管日、理由をアプリに記録する方法。
• マネージャーが再割り当てを確認する期限。

レコードの履歴には元の担当者名を残します。現在の担当者は、最後に顧客と話した人を知る必要があります。マネージャーが監査の履歴を確認することもあります。古い値を上書きするだけでなく、別の場所に保存してください。「チーム異動のため、6月12日にMaya PatelからJordan Leeへ担当者を変更」といった履歴があれば、現在の責任者を混乱させずに背景を伝えられます。

緊急度に応じて期限を設定します。マネージャーが優先度の高いチケットや案件を1営業日以内に確認し、優先度の低いレコードは3営業日まで待てるようにする方法があります。期限を過ぎたらマネージャーに通知するか、エスカレーションキューへ送ります。

AppMasterでは、Data Designerで現在の担当者、以前の担当者、移管理由、優先度、確認期限を設計できます。Business Processで、スタッフの状態が変わった後に対象レコードを移動し、マネージャー向けの確認タスクを作成できます。ルールが引き継ぎ用スプレッドシートだけに存在せず、アプリ内で確認できるようになります。

何も言わずに削除せず、アーカイブ処理を選ぶ

削除はすっきり見えますが、後でチームに必要な背景情報まで失われることがあります。終了した顧客依頼が請求判断の根拠になることもあります。古い仕入先レコードが過去の購入を裏付ける場合もあります。公開前に、どのレコードを終了、アーカイブ、削除できるのかを決め、それぞれの操作に明確な意味を持たせましょう。

作業は終わったものの、通常の履歴として残す必要がある場合は「終了」を使います。たとえば、サポート担当者が解決済みのチケットを終了します。スタッフはチケットとメッセージを読めますが、再開しない限り返信は追加できません。

日常の作業には不要になったものの、レポート、監査、後日の紛争対応で必要になる可能性があるレコードはアーカイブします。アーカイブされたアカウントは既定の一覧や検索結果から外し、権限を持つスタッフだけがアーカイブ用のフィルターで見つけられるようにします。担当者、作成日、ステータス履歴、関連ファイル、アーカイブ理由は保持してください。数か月後によく出る「誰が、なぜこの判断をしたのか」という疑問に答えられます。

法的、業務上、レポート上の用途がないレコードだけを削除します。一時的な下書き、重複したテストデータ、誤って作られた空のレコードなどが候補です。支払い、完了済みの作業、署名済みの書類、その他の関連履歴があるレコードは削除できないようにします。

無効なレコードを本当に無効にする

アーカイブのステータスには、背後のルールが必要です。スタッフがアーカイブ後もタスクを追加したり、金額を変更したり、別の人に割り当てたりできるなら、アーカイブという表示に意味はありません。通常の編集をロックし、アーカイブされた項目への自動リマインダーやフォローアップタスクも停止します。

次のような、制限された操作だけを許可します。

• レコードと履歴を表示する。
• 理由を記録して復元する。
• 権限がある場合にエクスポートする。
• ポリシーで必要な場合に社内向けのコンプライアンスメモを追加する。

通常、レコードを復元できる人はマネージャーまたは管理者が決めます。

保持期間を設定する

各アーカイブをいつまで利用できるかを書き出します。期間はレコードの種類によって変えて構いません。完了した社内依頼は、取引履歴のある顧客アカウントほど長く保持する必要がないかもしれません。期間が終わったら、指定された管理者が社内ポリシーに基づいて完全削除するか確認します。

AppMasterでは、Data DesignerでActive、Closed、Archivedなどのステータスを設計できます。Business Processのルールで編集を禁止し、日常の画面からアーカイブデータを隠せば、文書化したポリシーを一貫したアプリの動作に変えられます。

例外のエスカレーション経路を作る

担当者ルールを設けても、判断が難しいケースは残ります。すでに存在しないチームに顧客が属している、引き継ぎ前に従業員が退職する、インポートで担当者なしのレコードが作られる、といった場合です。こうしたレコードには、目に見える行き先と、整理する責任者が必要です。

「未割り当ての顧客レコード」や「担当者確認」といった名前の例外キューを作ります。有効な担当者がいないレコードはすべて自動的にそこへ送ります。誰でも見られるものの、誰も責任を感じない汎用受信箱は避けてください。

マネージャーまたは少人数の業務チームにキューの確認を任せます。アプリには、各項目がキューに入った理由、入った日時、最後に確認した人を記録させます。この履歴があれば、同じレコードが判断されないまま人から人へ移されるのを防げます。

リスクに応じて期限を変える

レコードによって確認期限を変えます。担当者のない新しいサポートチケットは1時間以内に対応が必要かもしれません。一方、無効な仕入先連絡先は数営業日待てることがあります。期限は一律にせず、遅れた場合の影響に基づいて決めましょう。

たとえば、次のように設定できます。

• 担当者のない緊急サポート案件はすぐにキューへ送り、30分後に当番マネージャーへ通知する。
• 未割り当ての進行中の営業案件を、翌営業日までに確認する。
• 不完全なインポートレコードを5営業日以内に確認する。
• 担当営業が退職したアカウントは、次回予定された顧客連絡の前に再割り当て対象として通知する。

期限を過ぎたら、指定されたマネージャーへ通知します。そのマネージャーが対応しなければ、決められた時間の後に別の人やチームへ送ります。経路は短く保ちましょう。承認者が多すぎると、顧客を待たせることになります。

間違った割り当てを簡単に報告できるようにする

間違いに最初に気づくのは、現場のスタッフであることがよくあります。各レコードに「割り当ての問題を報告」アクションを用意しましょう。「担当エリアが違う」「顧客が利用業者を変更した」など、短い理由を入力してもらい、履歴を削除せずにレコードを例外キューへ移します。

AppMasterでは、Data Designerでステータスと担当者項目を使ってキューを設計できます。Business Processで期限を設定し、メール、SMS、Telegramによる通知を送れます。スタッフはアプリの画面から問題を報告し、プロセスが適切な確認者へ送ります。

明確なエスカレーション経路があれば、不確実な状態を解決している間もレコードを有効な状態に保てます。管理者にとっても、担当者のない業務データが見えない場所に溜まるのではなく、確認件数を測れる一覧になります。

例、退職する営業担当者

営業担当者が金曜日に退職を申し出たとします。その人は38件の顧客アカウント、11件の未対応の見積もり、複数の下書き見積もりを持っています。チームがユーザーアカウントを無効化するだけなら、これらのレコードが日常の作業キューから消えたり、明確な担当者を失ったりする可能性があります。小さな抜けが、すぐに更新漏れや顧客からの依頼への未回答につながります。

営業マネージャーは、まず対応が必要なアカウントから確認します。アプリで、すべての進行中のアカウントを地域チームのリーダーに割り当てられます。そのリーダーが、各アカウントを新しい営業担当者に割り当てるまで責任を持ちます。採用に時間がかかっても、スタッフ変更中のデータベースレコードの担当者を明確に保てます。

未対応の見積もりは、退職する担当者ではなくアカウントに従わせます。アカウントが北部地域のリーダーへ移るなら、未対応の見積もりも同じ人へ移します。新しい担当者は、元の担当者のレコードを探さなくても、商談履歴、連絡先、次のアクションを確認できます。

下書き見積もりには別のルールが必要です。顧客への連絡がなく、フォローアップの予定もなく、最近の更新もない下書きは、今後の作業対象にする必要がないかもしれません。マネージャーは削除ではなくアーカイブできます。アーカイブされた下書きは参照用に残りますが、営業のアクティブな一覧を圧迫したり、リマインダーを発生させたりしません。

地域データがないアカウントもあります。こうしたレコードを手動確認キューへ送り、営業オペレーションマネージャーに通知します。担当者は顧客の所在地、アカウントメモ、現在の契約を確認してから割り当てます。アプリには、誰が確認を担当し、いつまでに完了させる必要があるかを表示します。

AppMasterでは、管理者が担当者を退職予定にしたとき、Business Processでアカウントのステータスと地域を確認できます。対象レコードを再割り当てし、条件に合う下書きをアーカイブし、例外用の確認タスクを作成できます。各操作の履歴が残るため、孤立レコードが発生しません。

公開前に担当者ルールをテストする

担当者ルールは図の上では問題なく見えても、最初の繁忙週に機能しないことがあります。短いテストを行えば、実際の顧客依頼、請求書、サポート案件が無効な従業員の下で止まる前に、抜けを見つけられます。

可能であれば、現実に近いデータのコピーを使います。異なる権限を持つユーザーを作り、関連項目を持つレコードを割り当てます。連絡先と商談があるアカウントや、タスクと添付ファイルがあるプロジェクトなどです。通常の作業だけでなく、扱いにくい例外ケースもテストしましょう。

レコードがアプリに入るすべての経路をテストする

レコードが入る経路は、メインの作成フォームだけではありません。スタッフがスプレッドシートをインポートすることもあれば、連携機能がリードを追加したり、自動処理が夜間にサポートチケットを作ったりします。どの経路でも担当者が割り当てられるか、共有キューへ送られることを確認します。

次のようなチェックを行います。

• 関係する各権限で手動作成し、期待した担当者が表示されることを確認する。
• 担当者情報がないファイルをインポートし、代替ルールが実行されることを確認する。
• すべての連携や自動処理でテストレコードを送る。
• 子レコードが親の担当者を引き継ぐのか、担当者を必須にするのか、無視するのかが、ポリシーどおりに動くことを確認する。

営業担当者が割り当てられていないインポート済みのリードは、空の担当者項目のままにせず、営業キューへ送るべきです。担当者の空欄は、エラーメッセージより見つけにくいことがあります。

スタッフ変更と禁止される操作をシミュレーションする

進行中の作業を持つテストユーザーを無効化します。アプリがそのユーザーのレコードを一覧表示し、指定された後任者またはキューへ移し、必要な場合に以前の担当者を履歴へ残すことを確認します。その後、後任者としてログインし、移された作業を開いて更新できることを確認します。

進行中の子レコードがある親レコードをアーカイブしてみます。未対応のチケットがある顧客アカウントなら、ルールに応じた動作をする必要があります。アーカイブを禁止する、関連レコードもアーカイブする、またはマネージャーに判断を求める、といった動作です。使える親レコードのない子レコードを、アプリが何も知らせず残してはいけません。

最後に権限を確認します。一般の従業員は自分のチーム内で担当者を変更できる必要があるかもしれません。一方、チーム間で作業を移したり、退職者のレコードを再割り当てしたりできるのはマネージャーだけにする場合があります。管理者アカウントだけでなく、実際の権限を持つアカウントでテストしてください。

AppMasterを使えば、こうした確認を業務アプリに組み込めます。ビジネスプロセスで担当者を必須にし、未割り当ての作業をキューへ送り、関連レコードに対応が必要な場合はアーカイブを禁止します。アプリを公開する前に同じプロセスをテストし、スタッフの記憶に頼るのではなくルールを修正しましょう。

公開前の簡単な確認

実際の作業を始める前に、業務アプリの担当者を最終確認します。営業、サポート、業務運用、ユーザー管理を担当する人と一緒に行いましょう。スタッフの役割が変わっても、重要なレコードには責任を持つ人またはチームが必要です。

可能であれば、現実に近いレコードのテストコピーを使います。顧客、商談、サポート依頼、請求書、社内タスクを作成します。その後、担当者の状態を変更したときに、各画面に何が表示されるか確認します。

• 重要なレコードの種類ごとに、現在の担当者、共有キュー、または指定された代替チームを設定する。
• 無効なユーザーごとに、誰が開始し、誰が承認するのかを含む移管手順が文書化されていることを確認する。
• サンプルレコードをアーカイブし、権限を持つスタッフが検索、フィルター、関連する顧客履歴から見つけられることを確認する。
• 毎週月曜の朝など、例外キューを定期的に確認する担当者を1人決める。
• 担当者が退職した後に後任が決まっていない商談など、欠落または矛盾したデータを持つレコードをテストする。

アプリを作った人の助けを借りずに、スタッフにこれらの確認を実行してもらいます。マネージャーが数分で30件の未対応の顧客依頼を移せないなら、そのルールは紙の上にしか存在しないのかもしれません。アプリには、明確な操作、確認メッセージ、変更した人の記録が必要です。

権限もテストします。サポート担当者はアーカイブされた案件を見る必要があっても、再開はできないようにする場合があります。部門リーダーは自分のチーム内で作業を再割り当てできても、機密レコードを関係のないグループへ移せないようにします。

AppMasterでは、これらの確認を業務プロセスに組み込み、デプロイ前にテストできます。有効な担当者がいないレコード用に例外キューを追加し、その状態を解消する担当者から見えるようにします。誰も確認しないキューは、顧客や同僚が気づくまで問題を隠すだけです。

ルールを業務アプリに組み込む

ワークフローを作る前に、担当者ルールを書きます。マネージャー、サポート担当者、開発者が同じ判断をできるよう、わかりやすい言葉を使いましょう。たとえば、「各顧客アカウントには1人の有効なアカウント担当者を置く。その担当者が退職した場合、営業マネージャーは1営業日以内に後任を割り当てる。元の担当者は読み取り専用の履歴に残す」と定義します。

各ルールをアプリの項目、ステータス、アクションに変換します。アカウントレコードには、担当者、チーム、割り当て日、アーカイブ状態が必要かもしれません。再割り当てアクションでは新しい担当者の入力を必須にし、変更した人と日時を記録します。これにより、スプレッドシートによる場当たり的な対応ではなく、スタッフが従える明確な手順になります。

AppMasterを使えば、アプリケーションを手作業で書かずに、このような社内アプリを作成できます。Data Designerでアカウント、連絡先、タスクとその関係を設計します。続いてBusiness Process Editorで再割り当て依頼を振り分け、新しい担当者が存在するかを確認し、依頼が長時間待機したときにマネージャーへ通知できます。

最初の実用的なバージョンには、担当者なしレコードの一覧、理由の入力を必須にした再割り当てフォーム、履歴を保持するアーカイブアクション、例外を処理するマネージャー用キュー、期限を過ぎた割り当てを示すレポートなどを含められます。

最初の数週間は、そのレポートを頻繁に確認します。マネージャーのキューにレコードが溜まるなら、原因を探します。あるチームに移管が集中している、マネージャーに作業を割り当てる権限がない、未対応タスクの確認なしにアーカイブできる、といった原因が考えられます。

振り分けルールを調整し、現実に近いスタッフ変更で変更後の経路をテストします。アカウントを作成し、タスクと連絡先を割り当て、担当者を外し、アカウントを再割り当てします。そして、関連するすべてのレコードがスタッフの期待する場所に表示されることを確認します。

すべての例外を予測する必要はありません。顧客履歴、作業項目、責任が消えてしまう前に、例外を処理できる目に見える場所を用意することが大切です。スタッフに公開する前にAppMasterでワークフローを作成してテストしておけば、日々の担当者変更を通常の作業として扱えるようになります。