データモデル：情報の形を決める
オブジェクト、項目、レコードタイプ、リレーションは、業務データの形を決める機能です。標準オブジェクトで要件を満たせない場合にカスタムオブジェクトを検討し、利用者や業務プロセスによって入力値や画面を分けたい場合はレコードタイプなどを組み合わせます。
設計では、同じ情報を複数箇所に重複して持たせないこと、必須項目を増やしすぎないこと、後から集計しやすい形にすることが重要です。画面上の見え方だけでなく、レポートや自動化から利用するときの扱いやすさも考えます。
セキュリティ：操作権限とデータの公開範囲を分ける
プロファイルと権限セットは、オブジェクトの作成・参照・編集・削除や、利用できる機能を調整します。一方、組織の共有設定、ロール階層、共有ルールなどは、参照できるレコードの範囲に関係します。
最小限のアクセス権を基準にし、必要な人へ追加権限を与える考え方にすると設定を説明しやすくなります。問題文に「特定の利用者だけ」「一時的に」「特定条件のレコード」といった表現があるときは、どの層で制御すべきかを確認します。
自動化：いつ、何をきっかけに動くかを確認する
自動化を選ぶときは、処理内容より先に実行タイミングを整理します。レコードの保存前に値を整えるのか、保存後に関連レコードを作るのか、利用者の操作で画面を進めるのかによって、適したフローの形が変わります。
自動化は便利ですが、同じ対象へ複数の処理を重ねると保守が難しくなります。既存処理の有無、失敗時の扱い、実行する利用者の権限、テスト方法まで含めて設計することが大切です。
レポートとダッシュボード：保存場所と共有範囲も見る
レポートはデータを条件で抽出・集計し、ダッシュボードは複数の集計結果を可視化します。形式やグラフだけでなく、レポートタイプで参照できるデータ、実行ユーザー、保存フォルダーのアクセス権が結果に影響します。
閲覧できないという問題では、元データへのアクセス、レポートまたはダッシュボードフォルダーへのアクセス、実行ユーザーという順で確認すると、原因を切り分けやすくなります。
変更管理：本番へ入れる前に影響範囲を確かめる
設定変更は、対象機能だけでなく既存の入力、共有、自動化、レポートへ影響することがあります。検証環境で要件を確認し、利用者ごとの操作を試し、移行対象と手順を整理してから本番へ反映します。
資格問題では、要件を満たす最小の変更か、既存データを壊さないか、利用者への影響を抑えられるかという観点も判断材料になります。