既に登録済みのレコードにて、作業者が設定されたレコード(申請処理がされたもの)が存在しているのではないでしょうか。 設定変更するにあたり、その既存レコードを一度初期プロセスに戻すか、削除(バックアップ推奨)してから、プロセス設定を変更かけてみて下さい。

バックアップとは別にcsvに書き出す」を自分ルールにしています。 あとまだ対策できていないのですが、kintone利用者の大半が「フィールド=Excelのセル」と勘違いしてることが多く簡単に「フィールドの書式？変えて」とか自分たちで文字列フィールドを変更したのに「この項目日付で絞れない！」とか言って

バックアップを取る データのリストアが可能な事を確認する リカバリのできる状況で変更を行う などなど。 kintoneのCSV入出力ではコメントが再現できなかったりしますが、少なくともフィールドデータが復旧できないという「最悪の事態」は避けられます。 あとは対策にどこまでかけるかですが、それは

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

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

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

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

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

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

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