kintoneの必須入力は保存時・申請時のどちらで確認する？下書きを残せる設計

kintoneの必須入力を増やした結果、「入力途中の下書きが保存できない」「申請の直前に不足が見つかる」と困っていませんか。項目を増やす前に、いつまでに入力されているべきかを決めると、保存と申請の役割を整理できます。

この記事では、常に必要な項目、条件に応じて必要な項目、申請時にそろえたい項目の3つに分けて考えます。架空の経費申請を例に、下書きを残しながら申請前に確認する設計を紹介します。

kintoneの必須入力を3つに分ける

すべてを標準の必須項目にすると、入力途中でもその値を求めることになります。逆にすべて任意だと、業務に必要な情報が抜けたまま申請されるおそれがあります。「何が必要か」と「いつ必要か」を1組で決めてください。標準フォームの設定方法はkintone公式のフォーム設定で確認できます。

経費申請アプリに、申請名・申請理由・見積添付があるとします。最初の相談では申請名だけを入力して下書きを保存し、内容が固まったら申請理由と見積添付をそろえて「申請」アクションを実行する流れです。

この場合、申請名は保存時から必要、理由と添付は申請時に必要、と分けられます。後者を標準設定でも常に必須にすると、理由が未定の下書きを保存できません。申請時チェックを設定するだけでは、標準側の必須設定は解除されない点に注意してください。

また、プロセス管理のステータス名・アクション名は実アプリで確認します。「申請」という名前でも、開始ステータスや遷移先が異なる運用では、対象を分けて設定する必要があります。

例えば、申請区分が「特別」の場合は、下書きであっても理由を必ず残したいなら、条件付き入力制御・書式変更プラグインの入力必須化が候補になります。条件に一致した追加・編集画面の保存時に確認する設計です。

特別を選んだだけで途中保存できなくならないか、通常へ戻したら任意入力にできるかも確認します。入力途中のメモを残したい業務なら、申請時まで待つほうが合う場合があります。

設定手順は条件付き入力制御の基本をご覧ください。テーブル内の理由入力については、テーブル外の条件で各明細行を必須にする例で扱っています。

入力途中は保存し、承認者へ渡す時点で空欄を防ぎたいなら、プロセス管理フィールド必須化プラグインが候補です。対象アクションと必要な項目を設定し、空欄があればアクションを進めずに知らせます。

詳細は申請時だけ必須入力にする設定手順をご覧ください。公式の仕組みとしては、プロセス管理のアクション実行イベントで処理の中止を制御できます。

不備を戻すための「差し戻す」操作にも必須条件を広げると、不足が原因で差し戻したいのに進めない設計になります。申請・承認・差し戻しを分け、各アクションで誰が何をそろえるかを確認してください。

利用者の権限や別の非表示・編集不可設定で入力できない項目を求めると、先へ進めなくなります。設定者だけでなく、申請者のアカウントと普段使う端末で試します。

値があるだけでは、理由が十分か、添付が正しいかまでは分かりません。申請時チェックは承認判断の代わりではありません。例えば理由欄に空白だけが入っているケースも含め、入力の案内と承認者の確認項目を用意します。

これらのプラグインは画面での操作に対する制御です。CSVや外部APIなどの更新をすべて同じ処理で検査するわけではありません。外部連携がある場合は、その経路のデータ確認も設計してください。

最初は1アクションと少数の項目に絞ると、止まった理由を調べやすくなります。入力項目の説明が伝わりにくい場合は、項目に入力ヒントを表示する方法も併せてご覧ください。

既存アプリの構成や利用者の操作に合わせて整理したい場合は、伴走支援のサービス案内をご覧ください。対象アプリと困っている操作が分かると、標準機能とプラグインの役割を整理しやすくなります。