バックアップと復元の練習もして最悪元に戻せるという確信をえてからやりました。 https://hazime-style.com/?p=711

バックアップなどの関連サービスを検討されるのもよいかもしれません。レコード更新・削除のタイミングでバックアップが取得されます。定期バックアップも可能です。 https://kb.kintoneapp.com/

バックアップの仕組みで苦労しましたね。

バックアップサーバーを立てて、しこたま事前テストしたCSVファイルを組織変更当日、本番に流す感じの運用でやってました。 さて、どクラウドのkintoneではどういう作戦でいこうかな。 あ、動的グループはkintoneだけなんですね。なるほど、それはkintoneだけユーザーのメリットになるのかな。

バックアップする手段がありません。飛んだら終わり。 変更履歴を記録する機能は利用者としてはあってほしい機能ですが、kintoneとしてはそれなりの負荷がかかる機能だと思います。 ので、krewDataで使う出力アプリなど、明らかに履歴機能が不要と思われるアプリではオフにするようにしています。 ユー

バックアップして削除) やりたいことが1個片付いたので、次探してきます！

バックアップをして、可能なものは本番環境で直接やってしまう。「フィールド削除」を行わない限り、kintoneのデータはまず大丈夫です（と信じています^^;）。 で、ココでテスト中のフィールドを利用者に見せたくない、触らせたくないという心理が働きますが、 それを回避するため、グループフィールドで隠蔽

バックアップを取って慎重に削除。 仰るとおり、フィールド削除して消えたデータはもどってきませんから。^^;

バックアップされている場合、使用中ユーザーと入れ替えてリストアします。削除されたユーザーと入れ替えるユーザーを誰にするのか、事前に確認を行います。 　 など、運用上のデメリットはあるように思います。 　 とりあえず、うちでは一度登録したユーザーは削除せず、使用停止にする運用ルールで進めていますが、削

バックアップについて。バックアップツールでレコード番号が変わるのは仕方ないかな。 ・プロセス管理の履歴をデータ化できないのかな？ ・フィールドコードの命名規則って皆さんどうしてるんだろう？気にする？気にしない？ などなど。 松田様の「kTool」アプリも追加させていただきました。 機能が豊富そうで