Copifyが取り組む すべての仕事。

1. 1両方のストアにCopifyをインストールし、「接続」の「ストアを接続」でペアリングします。一方のストアで10文字の接続コードを発行し、もう一方で15分以内に入力します。
2. 2AU → NZのデータフローを作成し、「商品」「在庫」「コレクション」「メタフィールドと値」をオンにします。地域ごとに帳簿を分けるため、「顧客」と「注文」はオフのままにします。
3. 3新しいデータフローは一時停止の状態で作成されます。有効にして「今すぐ同期」を実行し、新しいストアに一度でデータを投入します。
4. 4データの種類ごとにスケジュールを設定します。商品と在庫は「毎時」、ほとんど変わらないコレクションは「毎日」または「毎週」にします。
5. 5価格はそのままコピーされ、換算はされません。Shopifyのファイルは同期されず、AUで削除した商品はNZで削除するまでNZに残ります。

マーチャンダイジングするカタログは1つだけ。NZは、設定したスケジュールで商品・在庫・コレクションの変更を取り込みます。スプレッドシートの往復は不要です。

1. 1マスターストアから各ブランドストアへのデータフローを作成します。ストアの組み合わせごとに1つのフローです。
2. 2「商品」「コレクション」「メタフィールドと値」をオンにし、「同期対象」の商品フィルターで、各フローをそのブランドが扱うコレクションやタグに絞り込みます。
3. 3「メタフィールドマッパー」で各定義を「1:1 同期」「別のキーにマッピング」「無視」のいずれかに設定し、各ブランドのテーマが想定どおりの場所でカスタムデータを読めるようにします。
4. 4「宛先にスキーマを同期」をクリックして各ブランドストアに不足しているメタフィールド定義を作成し、「今すぐ同期」でデータを投入します。

商品データは共通のまま、品揃えはブランドごと。ラインナップの更新はそれを扱うすべてのブランドに届き、各ブランドは独自のカスタムデータ構成を保てます。

1. 1メインストアにクリアランス用のコレクションを用意します。自動コレクションなら、対象商品が自動で更新されます。
2. 2アウトレットストアへのデータフローを作成して「商品」をオンにし、「同期対象」でクリアランスコレクションに絞り込みます。現在条件に一致する商品数が表示されます。
3. 3「商品」のスケジュールを「毎時」に、在庫の動きが速い場合は「30分ごと」に設定します。各実行では前回送信した内容とレコードを比較するため、変更された商品だけが書き込まれます。
4. 4クリアランスから外れた商品はアウトレットから削除されません。Copifyは削除を反映しないため、アウトレット側で自分でアーカイブしてください。
5. 5「分析」の「同期履歴」で、各実行が反映されたことを確認します。

一度設定したコレクションから、アウトレットストアに商品が自動で入ります。商品を入力し直す人はいません。

1. 1「新規デプロイ」を開始してストアを選び、「何をデプロイしますか？」で「マーケットのカスタマイズ」を選択します。
2. 2コピー元とコピー先のテーマ、コピー元のマーケットを選びます。各マーケットには、カスタマイズ済みページの数が表示されます。
3. 3適用先のマーケットを選び、「カスタマイズしたすべて」を選択します。ホームページだけなら「特定のページのみ」を選びます。
4. 4書き込みの前に「変更を確認」します。各ページには「新規」または「更新」の表示と、変わる設定が示されます。
5. 5「詳細オプション」では、色・フォント・アプリブロックや翻訳テキストもコピーでき、マーケットを自動でリンクしたままにできます。ページの変更は「デプロイとリクエスト」から元に戻せますが、翻訳テキストは戻せません。

マーケットの見せ方は、国ごとに2週間を繰り返すものではなく、一度作って配布するものになります。2つのストア間だけでなく、1つのストア内でも使えます。

1. 1「デプロイ」で「新規デプロイ」を開始します。送信元と送信先のストアを選び、「テーマとデータ」を選択して両方のテーマを選び、「比較して続行」をクリックします。
2. 2変更された各ファイルを差分で確認します。JSONの設定ファイルはビジュアル表示、それ以外はコードで表示されます。
3. 3既存のテーマに書き込む場合は、反映したくないファイルのチェックを外します。同一のファイルは自動的に除外されます。「セーフモード」では、テーマ全体を新しい非公開の下書きにコピーします。
4. 4事前チェックを確認してから「デプロイ」します。「デプロイを承認」の権限がない場合は「承認に送る」になります。

本番に届くものをファイル単位で管理でき、反映前に差分を読め、反映後もデプロイ前のスナップショットにロールバックできます。

1. 1デプロイウィザードで送信元と送信先を比較します。各ファイルは新規・変更・削除として表示され、どのファイルでも差分を開けます。
2. 2既存のテーマを上書きする場合は、反映したいファイルだけを含めます。個別の設定をスキップすると、以降のデプロイでも送信先の値が保持されます。
3. 3「セーフモード」をオンのままにすると、新しい非公開テーマにデプロイされます。オフにすると公開中のテーマが対象になり、続行する前にウィザードが警告します。
4. 4確定する前に事前チェックを確認します。重大な問題・警告・情報が分けて表示され、商品やページなどのレコードがハンドルで照合されてその場で更新されることも示されます。
5. 5「デプロイ」するか、「承認に送る」を選びます。どちらの場合も先にデプロイ前のスナップショットが取られるため、上書きされたテーマファイルはロールバックできます。

衝突は、公開中のストアで後から見つかるのではなく、ウィザードの中で明らかになり、判断できます。ファイルごとに、差分と、安全な既定のデプロイ先と、事前チェックの警告付きで。

1. 1いつもどおり送信元と送信先を比較します。マーケットのカスタマイズファイルはテーマファイルなので、他のファイルと一緒に確認リストに表示されます。
2. 2共有テンプレートだけを反映するならそれらのチェックを外すか、個別の設定をスキップして、以降のデプロイでも送信先の値を保持します。
3. 3または「セーフモード」をオンのままにします。リリースは新しい下書きテーマに入り、公開するまで公開中のテーマには触れません。
4. 4マーケットの作業を意図して移す場合は、代わりに「マーケットのカスタマイズ」を使います。書き込みの前に、マーケットごとに各ページを「新規」または「更新」としてプレビューできます。
5. 5デプロイ前のスナップショットは他のテーマファイルと同様にマーケットのファイルも含むため、リリースと一緒にロールバックされます。

地域ごとのストア表示の作業が、テーマのリリースの巻き添えにならずに残ります。移すかどうかは自分で決められます。

1. 1本番 → ステージングのデータフローを作成し、「商品」「コレクション」「ページ」「ブログ記事」「メタフィールドと値」「メタオブジェクト」をオンにします。
2. 2「顧客」と「注文」はオフのままにします。ステージングがShopifyの開発ストアの場合、顧客データがコピーされる前にCopifyが警告します。
3. 3スケジュールを「毎日」にするか、テストサイクルの前に「今すぐ同期」を実行します。

ステージングが本物のストアと同じように動きます。本物のカタログ量、本物のコレクション、本物のメタフィールド。顧客レコードはコピーしません。

1. 1事前の準備は不要です。すべてのデプロイでデプロイ前のスナップショットが取られ、スナップショットを保存できない場合はデプロイが実行されずに止まります。
2. 2「デプロイとリクエスト」、または「バックアップ」の「テーマデプロイとロールバック」タブでデプロイを開き、「ロールバック」をクリックします。テーマファイルが復元され、デプロイで追加されたファイルは削除されます。
3. 3ロールバックには「デプロイを承認」の権限が必要なので、誰でも押せるボタンではありません。
4. 4コンテンツについては、「バックアップ」の「バージョン履歴とロールバック」で個別のレコードを戻すか、バックアップを復元します。「分析」の「同期履歴」で、何がいつ実行されたかを確認できます。

テーマのリリースは、運用の規律ではなく設計によって元に戻せます。スナップショットはデプロイの前提条件であり、取り忘れることはありません。

1. 1「設定」→「ユーザー」で、「デプロイを承認」の権限を承認担当者だけに付与します。ストアオーナーと管理者はすべての権限を持つため、これらのロールは少人数に絞ります。
2. 2それ以外の人は、必要な権限だけを持つ標準ユーザーにします。「デプロイを承認」がない場合、デプロイは「承認に送る」になります。
3. 3凍結期間中は、バックアップ対象の種類（商品、コレクション、ページ、ブログ記事、URLリダイレクト、メタフィールド定義、ナビゲーションメニュー、メタオブジェクト）を毎日バックアップするようスケジュールします。
4. 4期間中は「分析」の「同期履歴」で想定外の動きがないか確認します。

本番へのデプロイは指名された承認者を待ち、すべてが毎日バックアップされ、誰が何を変更したかはログでわかります。

1. 1参照用のストアをテンプレートとして用意し、新規クライアントのストアごとにCopifyをインストールして、接続コードで2つをペアリングします。
2. 2「デプロイ」でテーマを「セーフモード」で送り、ページ、ブログ記事、ナビゲーションメニュー、URLリダイレクト、メタフィールド定義をレコード単位で選んで一緒に送ります。
3. 3カタログの構造については、「コレクション」「ページ」「メタフィールドと値」のデータフローを作成し、「宛先にスキーマを同期」をクリックしてから「今すぐ同期」を実行します。

新しい構築は空のストアではなく自社の標準から始まり、テンプレートの改善は入力し直すことなく次のクライアントに届きます。

1. 1どのストアが卸売アカウントを管理するかを決め、そのストアをデータフローの送信元にします。同期は一方向で、方向は後から切り替えられます。
2. 2「詳細設定」で「顧客」をオンにします。顧客はメールアドレスで照合されるため、同じ顧客が両方のストアで認識されます。
3. 3「顧客」を「ライブ」に設定すると、送信元での編集がその場でもう一方のストアに届きます。スケジュール実行の対象は、過去60日間に更新された顧客です。
4. 4「同期履歴」を「顧客」で絞り込み、何がいつ書き込まれたかを確認します。

卸売アカウントは管理元のストアに従います。そこで変更した住所は、入力し直さなくてももう一方のストアに届きます。

1. 1新しいストアにCopifyをインストールし、接続コードで既存のストアとペアリングします。
2. 2データフローを作成し、引き継ぎたいデータの種類をすべてオンにします。顧客と注文は過去60日間が対象で、Shopifyのファイルはコピーされません。
3. 3「今すぐ同期」で一度にデータを投入し、メタフィールド定義は「宛先にスキーマを同期」をクリックします。
4. 4テーマは「デプロイ」で、「セーフモード」で新しい下書きテーマとして送ります。
5. 5その後は、データフローをスケジュールで継続同期するか、一時停止してストアを別々に運用します。

既存のカタログとコンテンツから始まる新しいストア。その後も揃えておくことも、別々に運用することもできます。

1. 1始める前に「テンプレートCSVをダウンロード」して、必要な列を確認します。
2. 2CSV（最大50 MB・100,000行）をアップロードし、宛先のストアを選んで列をマッピングします。「自動検出」がヘッダーを照合します。
3. 3行は既定でマージされます。レコードが見つかれば更新し、なければ作成します。コマンド列を使えば行ごとに上書きできます。
4. 4インポートを開始したら、そのまま作業を続けられます。インポートはバックグラウンドで実行され、「インポートキュー」に成功・失敗・スキップの件数とともに進捗が表示されます。
5. 5仕入先がフィードを公開している場合は、マッピングを保存し、そのURLからCSVまたは.xlsxを取得するスケジュールを追加します。

結果ファイルにはすべての行と、その行がどうなったか、失敗した場合はエラーが記載されます。問題のある行は探し回らずに修正して再実行できます。

1. 1旧システムから過去の注文をCSVにエクスポートします。
2. 2「データのインポート」で「注文」と宛先のストアを選び、注文番号をマッピングします。注文はIDまたは名前で照合されます。
3. 3注文は既定でマージではなく作成のみになるため、ファイルを再実行しても、インポート済みの注文が書き換えられることはありません。
4. 4インポートを開始します。バックグラウンドで実行され、結果ファイルで失敗した行とその理由を確認できます。

注文履歴が移行後も残るので、切り替え当日からサポートやレポートがゼロからのスタートになりません。

1. 1ファイルをアップロードして列をマッピングします。「自動検出」が一致するヘッダーをマッピングします。
2. 2実行する前に「ファイルをチェック」をクリックします。マッピングに沿ってファイル全体を読み込み、何も書き込みません。何行が何件のレコードになるか、それぞれがどうなるか、どのキーで照合されるかが表示されます。
3. 3未マッピングとして表示された列を確認します。マッピングの誤りはそこに隠れています。
4. 4エラーと警告を順に確認します。スプレッドシートの往復で壊れたSKUやバーコード、文字コードや区切り文字の問題も含まれます。
5. 5ファイル内に既存のレコードを特定できる情報がない場合、Copifyは推測せず、すべての行を新規作成するか、すべてスキップするかを確認します。

インポートの問題は、後からストアで見つかるのではなく、読めるレポートで明らかになります。修正は後片付けではなく、列のマッピングで済みます。

1. 1「バックアップ」で、これから変更するストアとエンティティの種類について「バックアップを作成」をクリックします。
2. 2「価格更新前」などのメモを付けておくと、後で見つけやすくなります。
3. 3一括変更を実行します。
4. 4問題が起きたら「復元」をクリックします。プレビューが現在のストアを確認し、上書きされる件数、削除された項目のうち再作成される件数、復元できない件数を表示します。
5. 5すべてを復元するか、戻したいレコードだけを選びます。バックアップ後に削除された商品は再作成できません。復元で更新されるのは、まだ存在する商品だけです。

一括変更が後戻りできない操作ではなくなります。変更前の状態は、復元できるバックアップとして、またはJSONやCSVとしてダウンロードできる形で残ります。

1. 1「バックアップ」の「スケジュールバックアップ」で、ストアとエンティティの種類ごとに「スケジュールを追加」をクリックします。
2. 2「毎日」「毎週（日曜日）」「隔週（2週間ごと）」「毎月（1日）」から選び、実行する時刻（時・分）を設定します。
3. 3各スケジュールには前回と次回の実行が表示され、削除せずに無効にできます。
4. 4「保持ルール」を開くと、プランで種類ごとに何件のバックアップを、どれだけの期間保持するかを確認できます。

復旧ポイントが、必要になる前から存在します。一度設定した頻度で作成され、新しいものが入るたびに古いものから入れ替わります。

1. 1テーマはZIPのアップロードではなく「デプロイ」でデプロイします。すべてのデプロイで送信先の現在のテーマファイルが先に保存され、そのスナップショットを保存できない場合はデプロイが止まります。
2. 2Copifyはストアの組み合わせごとに直近10件のスナップショットを保持し、古いものは自動で削除します。
3. 3スナップショットは「デプロイとリクエスト」、または「バックアップ」の「テーマデプロイとロールバック」タブで確認できます。後者には、ロールバックで元に戻される内容が一覧表示されます。
4. 4戻したいエントリからロールバックします。テーマファイルが復元され、デプロイで追加されたファイルは削除されます。「デプロイを承認」の権限が必要です。

戻ることのできるテーマの状態の、短く信頼できる履歴。誰かが覚えておく習慣ではなく、デプロイの副産物として作られます。

1. 1変更前に取られた、そのエンティティの種類の最新のバックアップを開き、「復元」をクリックします。
2. 2プレビューが現在のストアを確認し、上書きされる件数、削除された項目のうち再作成される件数、復元できない件数を表示します。
3. 3その一覧を検索・絞り込み・並べ替えて、すべてを読まずに必要なレコードを見つけます。
4. 4すべてを復元するか、レコードを含める・除外して、壊れたものだけを戻します。削除された商品やブログは再作成できず、まだ存在する場合にのみ復元されます。
5. 5復元はバックグラウンドで実行され、詳細は「同期履歴」に記録されます。ストアが元に戻ったら、新しいバックアップを取ります。

ひどい一夜が取り返しのつかないものではなくなります。確定する前に復旧で何が起きるかを確認でき、壊れたものだけを戻せます。

1. 1商品とコレクションだけでなく、カタログ以外の種類もバックアップします。メタオブジェクト、メタフィールド定義、ナビゲーションメニュー、URLリダイレクト、ページ、ブログ記事です。
2. 2それぞれに個別のスケジュールを設定します。月に一度しか変わらない構造データに、カタログと同じ頻度は必要ありません。
3. 3想定外にならないよう、範囲を把握したうえで判断します。顧客、注文、テーマはバックアップの対象外です。テーマの状態は、代わりに各デプロイのデプロイ前スナップショットで保存されます。

商品だけでなく、ストアの構造もカバーされます。復旧すればストア表示が元どおりに組み上がり、土台を手作業で作り直す必要はありません。

1. 1「バックアップ」で、送信元ストアの完了済みバックアップを選びます。復元はバックアップ元のストアにしか戻せないため、他のストアへはCSVを使います。
2. 2CSVとしてダウンロードします。ヘッダーはインポーターと一致しています。
3. 3「データのインポート」で同じデータの種類と別のストアを選び、ファイルをアップロードします。一致するヘッダーは自動でマッピングされ、必須フィールドは実行前に表示されます。
4. 4行は既定でマージされます。レコードが既にあれば更新し、なければ作成します。「インポートキュー」で実行状況を確認し、最後に結果ファイルをダウンロードします。

バックアップが移行用ファイルにもなります。一方のストアからダウンロードし、Copifyのインポーターで別のストアに再インポート。何が反映されたかは行単位のレポートでわかります。

1. 1ビジネスにとって重要なエンティティの種類のバックアップを作成します。
2. 2完了したバックアップはどれでもJSONまたはCSVでダウンロードできます。内容は、バックアップ実行時点のレコードです。
3. 3ファイルは、保持ポリシーで定められた場所に保管します。

特定のベンダーのアカウントに依存しない、持ち運び可能でタイムスタンプ付きの自社レコードのエクスポート。

1. 1「バックアップ」の「保持ルール」を開きます。プランで種類ごとに何件のバックアップを保持し、それぞれを何日間保管するかがわかります。
2. 2重要なエンティティの種類ごとに復旧ポイントが存在するよう、期間に隙間ができない頻度でスケジュールを設定します。
3. 3古いバックアップは、新しいものが入るたびに、また有効期限に達すると自動で削除されるため、期間はプランで定められた長さに保たれます。
4. 4プランで認められる期間より長く必要な場合は、アカウント全体を別のプランに移すのではなく、ストア単位で保持期間を調整できます。
5. 5期間を超えて残す必要があるものは、バックアップをダウンロードし、ポリシーで定められた場所にファイルを保管します。

復旧可能な期間を、誰かが続けてくれていることを願う習慣ではなく、数字で示して指し示せるものにできます。

1. 1在庫を管理するストアをデータフローの送信元にします。同期は一方向で、在庫のリアルタイム同期が双方向で動いている場合、Copifyはループとして警告します。
2. 2「データフロー設定」で「在庫」を「ライブ」に設定します。ライブはShopifyのWebhookで動くため、変更はその場で送信されます。
3. 3ライブには裏で動くスケジュールがないため、定期的な確認として「商品」を「毎時」または「15分ごと」にしておきます。
4. 4「同期履歴」を「リアルタイム」トリガーと「失敗」ステータスで絞り込み、反映されなかったものを見つけます。

在庫の変更が次の実行時ではなくほぼリアルタイムでもう一方のストアに届き、2つのストアの在庫が食い違う時間が短くなります。

1. 1「データフロー設定」で「メタフィールドを設定 →」をクリックし、「メタフィールドマッパー」を開きます。
2. 2各定義には「両方のストア」「ソースのみ」「宛先のみ」のいずれかが表示されます。
3. 3それぞれを「1:1 同期」、宛先で使うネームスペースとキーを指定した「別のキーにマッピング」、または「無視」に設定します。
4. 4「宛先にスキーマを同期」をクリックして、宛先に不足している定義を作成します。

カスタムデータが、誰も参照しないネームスペースではなく、宛先のテーマが実際に読む場所に届きます。

1. 1差分同期に任せます。各レコードは、前回宛先に送信した内容と比較されます。
2. 2変更のないレコードは書き直されずにスキップされ、スキップされたレコードは同期済みとして数えられません。
3. 3保存する前に、「データフロー設定」に実行で実際に書き込まれる件数が表示されます。何も変わっていなければゼロです。
4. 4データの種類ごとにスケジュールを調整します。実行する曜日、「開始時刻」と「終了時刻」の時間帯、そして必要な場合だけ「毎時」「30分ごと」「15分ごと」を使います。

同期の作業量は実際に変わったものに比例するため、大規模カタログのコストは規模ではなく変更量で決まります。

1. 1「データのインポート」で「エクスポート」タブを開き、ストアとデータの種類を選んでCSVをダウンロードします。インポーターが読むのと同じ列なので、マッピングし直さずに戻せます。
2. 2目的の列だけを編集し、ファイルの他の部分には手を付けません。
3. 3再インポートします。更新で変わるのはファイルにあるフィールドだけです。Copifyはストアの既存データに変更をマージするため、ファイルにない列が空になることはありません。
4. 4そのレコードについてファイルをすべての正とする場合にのみ、その行のコマンドをREPLACEにします。
5. 5大きな変更の前にはそのエンティティの種類をバックアップしておき、編集前の状態を記憶ではなく復元ポイントとして残します。

編集したものだけが変わり、それ以外は変わらないスプレッドシートの往復。一括編集と、うっかりのデータ損失を分ける違いです。

1. 1ファイルにコマンド列を追加します。各行で自分のレコードをどうするか（NEW、MERGE、UPDATE、REPLACE、DELETE、IGNORE）を指定するため、1つのファイルで追加・変更・削除を一度に行えます。
2. 2レコード内のリストは個別に制御します。タグ、バリエーション、画像、住所はそれぞれ独自のコマンドを持つため、既存のタグを置き換えずに追加したり、バリエーションのリストを丸ごと置き換えたりできます。
3. 3コマンドのない行は既定でマージされ、注文は既定で作成のみのため、再実行しても履歴が書き換えられることはありません。
4. 4何かを実行する前に、まず「ファイルをチェック」をクリックし、「実行される内容」で各コマンドに該当する行数を確認します。

追加・編集・削除という変更全体を1つのファイルで表せます。3回の作業と、その間の手作業の後片付けは不要です。

1. 1スタッフはShopifyの管理画面からCopifyを開いて登録し、「アクセスを申請」で必要な権限を申請します。
2. 2「設定」→「ユーザー」でロールを設定します。ストアオーナーと管理者はすべての権限を持ち、標準ユーザーはチェックされた権限だけを持ちます。
3. 3この協力者には「データフローを表示」「データフローを実行」「履歴を表示」にチェックを入れ、「接続を管理」と「請求」はチェックを外したままにします。
4. 4権限はいつでも変更でき、ユーザーを削除すればアクセスを取り消せます。

アクセス権が責任範囲と一致し、破壊的な操作は信頼ではなく権限で守られます。

1. 1「設定」→「ユーザー」で、「デプロイを承認」の権限を承認担当者だけに付与します。ストアオーナーと管理者は最初からこの権限を持っています。
2. 2「デプロイを管理」はあっても「デプロイを承認」がない人には、「デプロイ」の代わりに「承認に送る」が表示され、承認者へのメモを添えられます。
3. 3承認者は「承認」タブで依頼を確認し、変更を確認したうえで「承認してデプロイ」するか、理由を添えて却下します。
4. 4依頼は「承認待ち」「承認済み」「却下」「デプロイ済み」「ロールバック済み」と進み、その記録は「デプロイとリクエスト」に残ります。
5. 5同じ権限がロールバックにも適用されるため、リリースだけでなく、その取り消しも承認の対象になります。

テーマのリリースに、コードレビューと同じ承認の関門ができます。指名された承認者、承認した変更、そして却下には理由が残ります。

1. 1「設定」の「Slack通知」で「ワークスペースを接続」をクリックし、「チャンネルを追加」をクリックします。
2. 2通知する価値のあるトリガーを選びます。「同期失敗」「バックアップ失敗」「デプロイ失敗」「デプロイを却下」「デプロイをロールバック」「パイプライン切断」。完了の通知も残せます。
3. 3「配信頻度」を「即時」「毎時ダイジェスト」「日次サマリー」から選びます。
4. 4「パイプラインスコープ」を1つのデータフローまたはすべてに設定し、クライアントのチャンネルには自社ストアの通知だけが届くようにします。
5. 5「変更がない場合も通知する」はオフのままにして動きのないフローは静かにしておき、「静音時間」を設定して重要でない通知を夜間は保留します。

障害の通知が、チームが普段いる場所に、誰もミュートしない量で届きます。誰かが見に行くまでログに埋もれることはありません。

1. 1「分析」の「同期履歴」を開き、ステータス、送信元または送信先のストア、エンティティの種類、トリガー、日付で絞り込みます。
2. 2各エントリには、時刻、両方のストア、エンティティの種類とID、ステータス、実行のきっかけ（手動同期を実行した人を含む）、メッセージと詳細が表示されます。
3. 3「バックアップ」の「バージョン履歴とロールバック」でレコードを開き、バージョンをフィールドごとに比較して、必要ならロールバックします。
4. 4変更が同期ではなくデプロイによるものなら「デプロイとリクエスト」を確認し、「CSVをエクスポート」で記録を残します。

すべての同期操作が記録に残るため、障害は推測で再現するのではなく、記録から追跡できます。