これらがベストプラクティスである理由
ベストプラクティス
Adobe Workfront でカスタムフォームを作成する前に、ホワイトボードや紙の上でカスタムフォームを図式化します。
その理由は次のとおりです
すべての必須情報を入力できるフィールドがあり、ユーザーがフォームに簡単に入力できるようにフィールドが整理されていることを確認します。フォームを図式化すると、表示ロジックを使用して一部のフィールドを表示したり非表示にしたりすることが可能か判断できます。
ベストプラクティス
テンプレートで作成されたプロジェクトに、常に特定のカスタムフォームを添付する必要がある場合、そのテンプレートにカスタムフォームを添付します。めったに変更しないフィールドや、特定の情報を必要とするフィールドに入力しておくこともできます。
その理由は次のとおりです
これにより、フォームが既に添付され、情報の一部が既に入力されているので、プロジェクトの作成が迅速になり、該当するすべてのプロジェクトでカスタムフィールドが正しく完全に入力されます。
ベストプラクティス
カスタムフォームを作成して、Workfront システムに会社として追加した外部の顧客やベンダーに関する情報を追跡します。
その理由は次のとおりです
カスタムフォームを使用して、住所、主要連絡先の名前などを追跡し、Workfront 内で簡単にアクセスできるようにします。このカスタムフォーム情報は、レポートに取り込むこともできます。
ベストプラクティス
個別のフィールドを複数のフォームに付加するのではなく、共通フィールドと計算フィールドを含む単一の「一般」または「汎用」のカスタムフォームを作成します。これにより、企業全体の情報を一貫した方法で収集できます。
その理由は次のとおりです
「一般」フォームでは、これらのフィールドは一箇所に集まっているため、メンテナンスが容易になります。これらのフィールドを異なるフォームに別々に持たせると、個別に更新することが必要になりますが、そのようにするのではなく、1 つのフォームで更新できるようになります。
ベストプラクティス
カスタムフォームにセクション区切りを追加して、整理して分かりやすくします。
その理由は次のとおりです
関連する情報をセクションに分けてグループ化すると、ユーザーがフォームを扱いやすくなります。
ベストプラクティス
カスタムフォームを短くして、フォームが完全に入力され、必要なすべての情報が得られるようにします。
その理由は次のとおりです
長いフォームはユーザーにとって威圧的であり、しばしばフォームが完全に入力されなくなります。その結果、割り当て情報が不完全になり、レポートに使用するデータも不正確になります。
カスタムフォームに多数のフィールドが含まれる場合は、関連するフィールドを並べて配置し、可能な限りスクロールを減らします。スキップロジックを使用して、入力する必要のないフィールドを非表示にしたり、表示ロジックを使用して、特定のフィールドを表示したりすることもできます。
ベストプラクティス
ラジオボタンやドロップダウンメニューなどの定義済みのカスタムフィールドオプションを使用して、ユーザーが特定のオプションから選択するように求め、回答オプションを制限します。
その理由は次のとおりです。
定義済みのフィールドを使用すると、ユーザーはボックスをクリックするか、メニューから選択するだけであり、その質問に対するすべての回答が統一されます。
正確なレポートを作成するには、一貫した正確なデータが不可欠です。データに一貫性がないと、レポートが不正確になり、個々のレベル以上の意思決定に影響を与える可能性があります。この一貫したデータを使用すると、グラフをレポートに追加して、データを視覚的に表現することも可能になります。自由な形式のテキストフィールドは、グラフに使用できません。
ベストプラクティス
フィールドラベルが明確に表現され、説明的であることを確認します。
その理由は次のとおりです。
カスタムフォームに入力する人は、どのような情報が求められているかを理解できます。
ベストプラクティス
カスタムフィールドの「説明」フィールドに情報を追加して、フィールドに入力するユーザーが入力する必要のある情報を示します。
その理由は次のとおりです。
この情報は、カスタムフォームのフィールドの横にある「?」アイコンにカーソルを合わせると、ポップアップとして表示されます。テキストフィールドの書式を指定するとともに、フィールドに入力すべきデータを指定します。
ユーザーに詳細を提供することで、余計な会話、メールの往復、混乱を減らすことができます。情報に不備や不足があると、その分仕事が遅れてしまいます。
ベストプラクティス
表示ロジックを使用して、別のフィールドが特定の方法で入力された場合に必要なフィールドを表示します。カスタムフォームのスキップロジックを使用して、リクエストの種類に関係のないフィールドを非表示にします。
その理由は次のとおりです
必要なフィールドのみを表示する、または不要なフィールドを非表示にすると、より明確なカスタムフォームが作成され、ユーザーがカスタムフォームを入力する際に混乱を避けることができます。全体的に短いフォームになり、ユーザーに与える威圧感が減り、応答率が高くなります。
表示ロジックを使用すると、作成と管理に必要なカスタムフォームの数を減らすこともできます。
ベストプラクティス
別のフォームから計算情報を取り込むことで、カスタムフォームで必要な計算数を減らします。
その理由は次のとおりです
例えば、イシューフォームに「アセット数」という計算フィールドがあり、アイテムに添付されたアセット数を計算するとします。これはリクエストキューで使用されます。この情報は、リクエストが変換された時にプロジェクトに引き継ぐ必要があります。イシューフォームをコピーし、プロジェクトフォームとして保存します。次に、イシューの計算フィールドの名前を、プロジェクトフォームの計算ボックスに追加します。この例では、プロジェクトフォームの「アセット数」という計算フィールドに、文字通り「アセット数」と入力します。これにより、Workfront はプロジェクトでこの計算を再実行しなくなり、代わりにイシューのカスタムフォームの値を使用するようになります。
ベストプラクティス
該当する場合は、同じ目的を果たすフィールドライブラリの既存のフィールドを使用します。
その理由は次のとおりです
Workfront 内の 2 つのフィールドに同じ名前を付けることはできません。フィールドの名前が共通な場合、そのフィールドは既に存在している可能性があります。新しいフィールドを作成する前にフィールドライブラリを確認し、そのフィールドが既に存在するかどうかを確認します。
自分が作成したものではないフィールドを使用する場合、このフィールドに対する変更は、そのフィールドが含まれるすべてのカスタムフォームに影響を与えることに注意が必要です。計算を変更したり、フィールドのタイプを変更する（テキストからラジオボタンなど）必要がある場合は、新しいフィールドを作成し、元のフィールドとは異なる名前を付ける必要があります（似た名前を持つ複数のフィールドがあると、ユーザーにとって混乱を招く可能性があることに注意が必要です）。
ベストプラクティス
必須フィールドを使用して、プロセスまたは組織にとって重要な情報を確実に取り込みます。
その理由は次のとおりです
カスタムフォームのデータが不完全な場合、作業が遅れ、レポートに影響を与える可能性があります。必須フィールドのインジケーター（フィールド名の横の赤い *）は、カスタムフォームを編集して保存したり、正式にリクエストを送信したりする前に、特定の情報が必要であることをユーザーに通知します。
ただし、必須フィールドは控えめに慎重に使用する必要があります。すべてのフィールドを必須にすると、利用価値のある完全な情報をフィールドに入力できなくなる場合があります。また、オブジェクトの詳細エリアでカスタムフォームを編集する場合、入力が不完全な必須フィールドを使用すると、カスタムフォームを保存できなくなります。
ベストプラクティス
カスタムフォームのフィールド名を変更する場合は、そのフィールドを呼び出す計算フィールドに影響を与える可能性があるので、注意が必要です。
その理由は次のとおりです
フィールド名を変更する場合は、名前を更新する必要があります。名前が、カスタムフォームの計算カスタムフィールドまたはテキストモードに組み込まれた計算で使用されます。フィールド名を変更すると、計算が中断され、情報が不正確になる場合があります。
ベストプラクティス
Workfront の通常のシステムメンテナンスの一環として、カスタムフォームやフィールドを定期的に（四半期に 1 回など）レビューします。
その理由は次のとおりです
組織が作業に必要なデータを収集していない場合、カスタムフォームやフィールドは役に立ちません。
更新を行う場合は、これらの変更が Workfront の他の側面に及ぼす影響に注意してください。 例えば、フィールド名を変更すると、そのフィールドを使用する計算が中断される場合があります。 または、フォームのラベルや名前を変更すると、レポートに必要な情報が表示されなくなったり、別のシステムとの統合が実行されなくなったりすることがあります。
カスタムフォームを更新する以外に、使用率の低いフォームやまったく使用されていないフォームを特定します。 使用頻度の低いフォームを別のフォームと組み合わせることはできますかまたは、フォームが収集している情報がチームで不要になったので、そのフォームを非推奨にする時期かもしれません。
これらの不要なフォームに対する措置をとる前に、カスタムフォームとカスタムフィールドの非アクティブ化と削除に関する説明を参照してください。
ベストプラクティス
不要なカスタムフォームは、削除せずに、ディアクティベートします。
その理由は次のとおりです
カスタムフォームを削除すると、そのカスタムフォームから入力されたすべてのカスタムデータが削除されます。
カスタムフォームを非アクティブ化すると、関連する履歴データはすべて保持されます。 この情報に関するレポートを継続できます。
また、非アクティブ化すると、ユーザーがカスタムフォームを選択するドロップダウンメニューにフォームが表示されなくなります。 ただし、フォームは、既に添付されているオブジェクト上に表示されます。
ベストプラクティス
カスタムフォームで不要になったカスタムフィールドを、セクション区切りの下に非表示にします。そのセクションはシステム管理者のみに表示します。
その理由は次のとおりです
既存のカスタムフィールドを削除すると、カスタムフォームからそのフィールドが削除されるだけでなく、そのカスタムフィールドが使用されているすべてのフィールドに含まれるすべてのデータが削除されます。これにより、レポートに必要な履歴データが削除されます。
データの損失を防ぐには、不要なフィールドをカスタムフォーム自体で非表示にします。 カスタムフォームのセクション区切りを使用すると、関連付けられた Workfront オブジェクトの表示、投稿、管理に対するアクセス権をユーザーが持っているかどうかに基づいて、そのセクションの一部であるフィールドの表示／非表示を切り替えることができます。 または、セクションを「管理者のみ」に設定すると、システム管理者のアクセスレベルを持つユーザーだけがフォームのセクション全体を表示できます。
ベストプラクティス
Workfront インスタンスでカスタムフォームを作成できるユーザーを制限します。
その理由は次のとおりです
カスタムフォームを作成できるユーザーのグループを選択すると、Workfront インスタンスで作成されるカスタムフォームの数を制御できます。
さらに、他のユーザーがフォームを作成できるようにすると、システム管理者の作業が軽減され、各グループが定期的に使用するカスタムフォームの更新を制御できるようになります。
