お疲れ様です。 ふゆきさんがおっしゃっているとおり、基本的にはプラグイン自体に設定のバックアップ・復元機能が付いているか否かになると思います。 crenaさんのPlugin Managerには、プラグイン設定のバックアップ・復元機能があったりするんですが、対象となるプラグインがかなり限られてしまい

手前味噌ですが、私は 「AppInsight for kintone」 というプラグインを自作し、設計図を自動で生成しています。 ルックアップ・関連レコード・アクションのつながりをER図風に可視化したり、どのプラグインが入っているか一覧化できるので、棚卸しや設計の見直しに便利です。 設計図を手作

あくまでも、小生の個人的な感想です。（実務では問い合わせ記録はしてません🙇🏻） 提示のアプリ（以下、「アプリA」とします。）は「個々の問い合わせ対応を記録する」ものと割り切って、一覧が少々見づらくとも、入力負担軽減のためのフォーム設計重視でよいと思います。 これをFAQ集として活用するには、「関

上記の補足です。 本運用では、①②③アプリはいずれかの更新がそのまま他のアプリに連動してるわけではないので、各アプリの同期が重要となります。 ①アプリを更新した際には必ず②へのコピーボタンを押す、 ③アプリ更新時にも①アプリのコピーボタンを押す　ことの徹底の他、 上記キャプチャのように③アプリに

ご返信ありがとうございます。 残念ながら、私の業務ではデータの集計までで完了することが多いので、だいたいクロス集計表やグラフ、もしくはTISさんの「関連レコード一覧フィールド集計プラグイン」を入れた関連レコード一覧で表示するだけでほとんど足りています。 集計結果を別の計算に使用する場合には、トヨ

>できるだけプラグインは使うなという指示が出ています。 こんな👇イメージでしょうか？ >[関連レコードで表示させた値の合計を別フィールドで表示させたい。](https://community.cybozu.dev/t/topic/10374/12?u=fito12) このコメントの後

>やっぱり、簡単にはいきそうにないですか。 簡単＝アプリ開発と捉えて… 最終的にどういったフローを目指しているのかにもよると思いますが、 「複数の申請を１画面にまとめて一括承認」に拘っているなら、「まとめて承認アプリ」（仮称）を別に設けて、『関連レコードで「申請アプリ」のステータス［○○］

IDをどうやって持ってくるかが重要ですね。 以下妄想です。 承認者が事前に分かっているパターンです ① 申請者を社員名簿からのルックアップでIDも一緒に引っ張る （プロセス管理では作業者を作成者で進める） この時点で申請者のIDは一覧画面に表示 ② 申請時に承認者をルックアップする、IDも取得す

「保存まではする必要はない」ということは理解しました。 関連レコードは、値を参照表示するだけなので、「表示を見て人が判断」するしかない＝性善説にもとづいた運用で対応するしかないですね🤔 ルックアップの「絞り込みの初期設定」はステータスを条件にできますので、ご提示の「完了の場合のみ」だけでよいなら

そもそも論で恐縮ですが… >片方のアプリのステータスをもう片方のアプリにルックアップで表示させたい つまり、「片方のアプリのステータスをもう片方のアプリに__保存したい__」理由は何でしょうか？ ①「片方のアプリ」をルックアップしたときにそのレコードを特定できる情報（例　レコード番号）をど