次の方法で共有


モデル駆動型アプリのフォームに関する問題のトラブルシューティング

この記事は、モデル駆動型アプリ フォームの操作中に発生する可能性のある一般的な問題のいくつかを修正するのに役立つ情報が含まれています。

重要

  • この記事で説明するツールは、トラブルシューティングを目的として設計されています。これらは、運用展開での問題のトラブルシューティングに使用できますが、毎日の運用展開シナリオで使用するためのものではありません。
  • これらのトラブルシューティング ツールは、特に明記されていない限り (たとえば、ブラウザー タブがモデル駆動型アプリにアクセスする場合)、現在のユーザー セッションにのみ影響します。 システムのカスタマイズを変更したり、他のユーザーやセッションに影響を与えたりすることはありません。 現在のセッションが閉じられると、効果は適用されなくなります。
  • ほとんどのツールは、すべての運用環境で使用できます。 記事で言及されているいくつかのツールは、まだ組織に展開されていない可能性があります。新しいツールは定期的に追加されます。
  • この記事に一覧表示されているツールは、シナリオに沿って書かれています。 それらを個別に使用して、さまざまなタイプの問題のトラブルシューティングを実行できます。
  • URL パラメーターを使用して、さまざまなフォーム コンポーネントを無効にするおよびモニターで登録済みフォームのイベント ハンドラーとライブラリを表示するは、多くのシナリオのトラブルシューティングに頻繁に使用する重要かつ基本的なツールです。
  • モニターの使用方法の詳細については、モニターを使用して、モデル駆動型アプリフォームの動作のトラブルシューティングをするを参照してください

URL パラメーターを使用して、さまざまなフォーム コンポーネントを無効にする

フォームに関する問題のトラブルシューティングを実行する場合、問題の原因となった特定のコンポーネントを特定するために、URL パラメーターを使用してコンポーネントを無効にする必要があります。 問題の原因を絞り込むために、フラグを 1 つずつ使用することをお勧めします。 次の URL パラメーターを使用できます。

  • DisableFormCommandbar

    フォームのコマンド バーを無効にします。 フォーム ページのコマンド バーを無効にするだけで、リスト (グリッド)、ダッシュボードなどには対応していません。

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormCommandbar=true
    
  • DisableFormHandlers

    すべてのフォーム ハンドラーを無効にします。 DisableFormHandlers=true フラグを使用する場合、次のイベント ハンドラーが無効になります: OnLoadOnSave、ビジネス ルール、OnChangeTabStateChange

    きめ細かいコントロールのイベントまたはライブラリ インデックスの取得方法の詳細については、モニターで登録済みフォームのイベント ハンドラーとライブラリを表示するを参照してください。

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormHandlers=true
    
    • &flags=DisableFormHandlers=eventName

      イベント名を指定してフォーム ハンドラーを無効にします (例: **DisableFormHandlers=onload)。

      https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormHandlers=true
      
    • &flags=DisableFormHandlers=eventName_index

      サポートされている任意のイベント名に対して、指定されたインデックスのイベント ハンドラーを無効にします。 例えば、DisableFormHandlers=true_0 はインデックス 0 のすべてのイベント ハンドラーを無効にします。 DisableFormHandlers=onload_2 はインデックス 2 の OnLoad イベント ハンドラーを無効にします。

    • &flags=DisableFormHandlers=eventName_startIndex_endIndex

      startIndex および endIndex 値 (両方が含まれる) を指定して、指定された範囲内のすべてのイベント ハンドラーを無効にします。 例えば、DisableFormHandlers=true_0_2 はインデックス 0、1、2 のすべてのイベント ハンドラーを無効にします。 DisableFormHandlers=onload_2_5 はインデックス 2、3、4、5 の OnLoad イベント ハンドラーを無効にします。 イベント ハンドラーが多い場合は、このアプローチを使用して、問題のあるハンドラーをすばやく絞り込むことができます。

    注意

    ビジネス ルールはビジネス ルール デザイナーで作成され、クライアント側のスクリプトにコンパイルされ、OnLoadOnSave、および OnChange などの複数のフォーム イベントに登録されます。 ビジネス ルールを無効にする方法は、他のフォーム イベントと非常に似ています。 ただし、以下のような重要な違いがあります:

    • DisableFormHandlers=truebusinessrulebusinessrule_*index*、または businessrule_*startIndex_endIndex* を使用すると、登録されているすべてのフォーム イベントでビジネス ルールが無効になります。
    • たとえば、次の画像は、バックエンドでビジネス ルールを更新する手順を示しています。 組織内で 1 度だけ実行する必要があり、トラブルシューティング後に変更を戻すことができます。
      ビジネス ルールの更新
    • 上記のアクションを実行してフォームを更新すると、以下の画像に示すように、追加情報を含む別のメッセージが表示されます。
      ビジネス ルールの個別コントロール
  • DisableFormLibraries

    フォーム ライブラリを無効にして、ライブラリが読み込まれないようにします。 きめ細かいコントロールのイベントまたはライブラリ インデックスの取得方法の詳細については、モニターで登録済みフォームのイベント ハンドラーとライブラリを表示するを参照してください。 使用方法は DisableFormHandlers に似ていますが、値としてイベント名を指定しない点が異なります。

    • &flags=DisableFormLibraries=true: すべてのフォーム ライブラリを無効にします。
    • &flags=DisableFormLibraries= index**: 指定されたインデックスでフォーム ライブラリを無効にします。
    • &flags=DisableFormLibraries= startIndex_endIndex**: startIndex および endIndex (両方を含む) の範囲でフォーム ライブラリを無効にします。
  • DisableWebResourceControls

    フォーム上のすべての Web リソース コントロールを無効にします。

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableWebResourceControls=true
    

    Web リソースを無効にする

  • DisableFormControl

    フォーム コントロールを無効にします。 コントロールを無効にするには、コントロール名を指定します。 &flags=DisableWebResourceControls=true で問題が解決でき、フォームに複数の Web リソース コントロールがある場合、このフラグを使用して、問題の原因となっているコントロールをさらに特定できます。

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormControl=controlname
    
  • DisableBusinessProcessFlow

    フォームですべての業務プロセス フローを無効にします。

    https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableBusinessProcessFlow=true
    
  • navbar これは flag パラメーターではありません。むしろ、URL で navbar=off を使用します。

カンマで区切って複数の URL パラメーターを追加することもできます (,)。

https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormHandlers=true,DisableWebResourceControls=true,DisableFormCommandbar=true,DisableBusinessProcessFlow=true&navbar=off

注意

DisableFormHandlers および DisableFormLibraries の違いは次の通りです:

  • DisableFormHandlers フラグは、含まれているフォーム ライブラリに関係なく、フォーム ハンドラーを無効にします。 一方、DisableFormLibraries フラグは、ライブラリに含まれている関数 (イベント ハンドラー) に関係なく、フォーム ライブラリ (Web リソース) を無効にします。 簡単に言えば、DisableFormLibraries は指定された JavaScript Web リソース ファイルが読み込まれていないことを確認します。
  • DisableFormHandlers フラグは、含まれているフォーム ライブラリが読み込まれるのを妨げることはありません。 したがって、ライブラリに存在しながらイベント ハンドラーとして登録されていない JavaScript コードの実行を停止することはありません。 たとえば、フォーム ライブラリ new_myscript.js が次のように書かれている場合 (推奨される方法ではありません):
  • DisableFormHandlers から始めて問題が解決するかどうかを確認し、解決しない場合は DisableFormLibraries を試してみてください。 任意のスクリプトを無効にすると、フォーム シナリオが壊れる可能性があるというリスクが常に伴います。 ただし、後者は JavaScript ファイル全体が無効になるため、より多くの副作用が発生する傾向があります。 DisableFormHandlers と DisableFormLibraries の違い
  • myOnloadHandlerOnLoad イベント ハンドラーとして登録されているとすると、DisableFormHandlers=true フラグは 2 番目の通知のみを防ぎ、DisableFormLibraries=true フラグは両方の通知を防ぎます。

モニターで登録済みフォームのイベント ハンドラーとライブラリを表示する

登録済みのフォーム イベント ハンドルとライブラリを表示するには、モニターFormEvents 操作を表示できます。

フォーム イベント

DisableFormHandlers または DisableFormLibraries URL フラグを使用するときは、eventIndex パラメーター値と libraryIndex パラメーター値が必要になります。 イベントまたはライブラリを無効にすると、FormEvents 操作 (すべてのイベントの登録済みイベント ハンドラーの全体図)、および FormEvents.eventName 操作 (特定のイベントが発生したときにログに記録される詳細) の両方でイベントが有効になっている状態が確認できます。

フォーム イベント OnLoad

フォームをロードするときの予期しない動作

モデル駆動型アプリ フォームの読み込み時に予期しない動作を引き起こす可能性のある一般的な問題は次のとおりです。

  • 列またはコントロールには、期待する値がありません。
  • コントロールが無効になっていないか、有効になっていません。
  • コントロールは表示されないか、非表示になっていません。

トラブルシューティング方法

フォームを開いたときに予期しない動作が発生する理由は複数あります。 最も一般的なものの一つは、同期または非同期で実行され、列とコントロールの動作を変更する OnLoad スクリプトです。 スクリプトが問題の原因であるかどうかを判断するには、アプリ URL の末尾に &flags=DisableFormHandlers=true を追加してフォーム ハンドラーを無効にします。

フォーム ハンドラーを無効にした後に予期しない動作が発生しなくなった場合は、特定のフォーム ハンドラーがこの動作を引き起こしていることを強く示しています。 この動作を引き起こしているスクリプトを特定した場合は、スクリプト所有者に連絡を取り、この問題のトラブルシューティングを進めてください。

保存の進行中のエラー メッセージ

フォームを保存すると、保存の進行中のエラーメッセージが表示されます。

このエラーは、フォーム OnSave イベントが前の OnSave イベントが完了する前にトリガーされた場合に発生します。 この動作はサポートされていません。エラーは設計上表示されます。前の OnSave イベントが完了する前に OnSave イベントを呼び出すと、意図しない結果を伴う再帰的な保存ループが発生するためです。

このエラーの一般的な原因は、OnSave イベント ハンドラで save() メソッドを呼び出すスクリプトです。 別の考えられる原因は setTimeout() メソッドにおける save() の同時呼び出しである可能性があります。別の save() 呼び出しが行われる前に前の save() 呼び出しが完了したかどうかに応じて、エラーが断続的に表示される可能性があります。

トラブルシューティング方法

モニター では、FormEvents.onsave 操作により、エラーの原因となっているすべての詳細が提供されます (呼び出しスタックはデモ用に変更されています)。 呼び出しスタックでは、このエラーの原因となった正確な Web リソース、関数、行番号、列番号がわかります。 問題を再現できない場合、フォーム チェッカーはエラーを検出できません。

保存中エラー

スクリプト所有者に連絡を取り、問題のトラブルシューティングを進めてください。

断続的なフォーム エラー

断続的またはランダムなフォーム エラーの最も一般的な原因は、サポートされていないクライアント API メソッド フォームの使用です。 これらのエラーには、次の特性があります。

  • これらは、特定のレコード、ユーザー、リージョン、またはブラウザーに対してのみ、またはネットワークまたはサービスの負荷が高い期間中にのみ発生します。

  • サポート インスタンスで発生することはめったにありません。

  • これらはコンピュータで 1 回発生する可能性があり、ブラウザのキャッシュをクリアした後に同じエラーが再度発生する可能性があります。

  • formContext.getControl または formContext.getControl(arg).getAttribute() は、有効なコントロールまたは列に対してランダムに null を返します。

サポートされていないクライアント API メソッドを作成する方法はたくさんあり、それらはすべて共通のパターンを共有しています。それらは、フォーム ロード パイプラインで競合状態を引き起こします。 これらは競合状態を引き起こすため、この問題は、クライアント API を介してフォームに完全にアクセスできるようになる前にカスタム スクリプトが実行された場合にのみ発生します。 競合状態はさまざまな要因で発生する可能性があります。

  • JavaScript Web リソースでは、フォームにアクセスできるようになるのを待つことなく Web リソース ファイルが読み込まれるとすぐに実行されるグローバル スコープにコードが配置されます。 コードが、OnLoad ハンドラーなど、次のような有効なフォーム ハンドラー内で実行されていることを確認してください。

    サポートされていないクライアント API メソッド

  • Power Apps component framework コンポーネント スクリプト ファイルでは、クライアント API メソッドは init または updateView 関数の内部でアクセスされます。 init() および updateView() 関数は、フォームにすぐにアクセスできるようになるのを待たずに、コンポーネントがロードされるとすぐに実行されます。 サポートされていないクライアント API メソッドを Power Apps component framework コンポーネントで使用することはできません。

クライアント API は、Web リソース ファイルの window.setTimeout() 関数の中でアクセスされます。 ページの状態は、setTimeout() メソッドがラップされた関数を実行するときには予測ができません。 タイマー機能の性質上、実行が発生すると、ページが遷移状態 (ページの読み込み中または保存中) になり、クライアント API から簡単にアクセスできない場合があります。

トラブルシューティング方法

モニターを使用すると、サポートされていないクライアント アクセスがいつ発生したか、および競合状態が原因でアクセスが間違った時間に発生したかを判断するのに役立つ情報にアクセスできます。 ただし、サポートされていないコードが問題を引き起こさない適切なタイミングで実行された場合、フォーム チェッカーはそのようなサポートされていないクライアント アクセスを報告しません。

サポートされていないクライアント API

注意

説明のために、コール スタックが変更されました。 呼び出しスタックには、Web リソース、関数、エラーの原因となっている行などの詳細が表示されます。

スクリプト所有者に連絡を取り、問題のトラブルシューティングを進めてください。

フォームを保存しようとすると、フォームまたはレコードが保存されない

一般的な原因は、executionContext.getEventArgs().preventDefault() メソッドを呼び出す OnSave イベント ハンドラーが保存操作をキャンセルすることによるものです。

トラブルシューティング方法

モニターでは、FormEvents.onsave 操作により、保存イベントがキャンセルされた理由のすべての詳細が、フォーム UI 自体から利用可能なものより詳細に提供されます。

レコードが保存されないエラー

スクリプト所有者に連絡を取り、問題のトラブルシューティングを進めてください。

フォームがフリーズする、読み込みが遅い、または原因不明のエラーがスローされる

フォームがフリーズしたり、読み込みが遅くなったり、または「Web リソース メソッドが存在しません」というスクリプト エラーや一般的なスクリプト エラーではないエラーがスローされる理由はたくさんあります。 考えられる理由には次のものがあります。

  • 不正な OnLoad スクリプト。
  • Web リソース コントロール。
  • リボン ボタンのスクリプトとルール。
  • 同期ネットワーク要求。
  • カスタム プラグイン。
  • ビジネス プロセス フローのエラー。

トラブルシューティング方法

フォームを介さずに問題が再現されるかどうかを判断します。 もし再現されるなら、フォームのコンテキストから調査されるべきより広範な問題があります。 問題の実際所有権は、ケースバイケースで詳細が異なります。

  • この問題がフォームでのみ発生すると思われる場合は、URL パラメーターを使用して異なるフォーム コンポーネントを無効にするを参照して、問題の原因となっているコンポーネントを絞り込みます。
  • 問題の原因が特定のフォーム ライブラリ/スクリプト ファイルであることが分かった場合は、これらのカスタマイズを行った所有者に連絡を取り、問題の根本原因を特定してください。
  • DisableWebResourceControls フラグを使用して Web リソース コントロールが問題を引き起こしていると特定した場合、問題が再現されなくなるまで、DisableFormControl フラグを使用して 1 つずつ無効にできます。 問題を再現しない最後の無効化されたコントロールが、問題の原因となっているコントロールです。 コントロールの所有者に連絡を取り、問題のトラブルシューティングを進めてください。
  • DisableFormCommandbar フラグを使用して問題の原因がコマンド バー/リボンであることを特定した場合、これはフォームの問題ではなく、コマンド バーの問題であることを意味します。 コマンド チェッカーを使用して、個々のコマンドのトラブルシューティングを行い、問題の原因となっているコマンドを特定します。

ビジネス ルールまたはカスタム スクリプトが機能していない

この問題は、従来の Web クライアントで機能していたビジネス ルールまたはカスタム スクリプトが統一インターフェイスで機能しなくなった場合に発生します。 このエラーが発生する主な理由の 1 つは、ビジネス ルールまたは統一インターフェイスのスクリプトが、統一インターフェイスで使用できないコントロールを参照していることです。

トラブルシューティング方法

ビジネス ルールまたはスクリプトが統一インターフェイスで機能しない理由の 1 つは、それらの一部であるコントロールが統一インターフェイスに存在しないことです。 複合コントロールは Web クライアントに存在しますが、統一インターフェイスでは、複合コントロールはパーツに分割され、異なる方法で保存されます。 たとえば、列 fullname がビジネス ルールまたはカスタム スクリプトの一部である場合、列 firstnamemiddlename、また lastname が代わりに使用される必要があります。

フォーム チェッカーを起動すると、CompositeControl 操作で、問題の原因となっている複合コントロール、代わりにビジネス ルールまたはカスタム スクリプトで使用できる列、および完全な呼び出しスタック (呼び出しスタックはデモ用に変更されています) を含む、より詳細な情報を確認できます。

カスタム スクリプトが機能しない

ビジネス ルール またはカスタム スクリプトに対応する所有者に連絡を取り、フォーム チェッカーによって提案されたコントロールを変更します。

ほとんどのフォームには 関連 タブがあり、関連メニュー項目 を含む 関連メニュー が開きます。

拡張されたフォームの関連タブ

関連メニュー項目 が期待どおりに表示されない場合があります。

トラブルシューティング方法

関連メニュー項目が期待どおりに表示されない理由は、以下が考えられます。

メイン テーブルと関連テーブルの間には一対多または多対多の関係が必要です。 フォームにメイン テーブルの行が表示されている。 関連テーブルは、フォームの 関連 メニューに表示されるテーブルです。 これらのリレーションシップが存在しない場合、関連するメニュー項目は表示されません。

確認するためには、Power Apps ポータル に移動して テーブル を選択し、表示したいリレーションシップを含むテーブルを選択します。

関連 メニューには、Dataverse によって作成された特定のリレーションシップの関連テーブルは表示されません。 これらのリレーションシップは、カスタマイズ不可としてマークされています。

AssociatedMenuConfiguration.IsCustomizable プロパティ は、リレーションシップをカスタマイズできるかどうかを示します。 最も簡単な確認方法は、Web API を使用してリレーションシップをクエリしAssociatedMenuConfiguration 複合型 データを表示することです。

部署 テーブルと 目標 テーブル間のリレーションシップがカスタマイズ可能かどうかを確認するとします。 この関係の SchemaNamebusiness_unit_goal です。 ブラウザーで URL を入力します。

GET [Organization URI]/api/data/v9.2/RelationshipDefinitions(SchemaName='business_unit_goal')/Microsoft.Dynamics.CRM.OneToManyRelationshipMetadata?$select=AssociatedMenuConfiguration

テーブル定義をクエリして、同じデータを取得することもできます。

GET [Organization URI]/api/data/v9.2/EntityDefinitions(LogicalName='businessunit')/OneToManyRelationships(SchemaName='business_unit_goal')/AssociatedMenuConfiguration

どちらの要求に対する応答も次のようになります。

{
    "@odata.context": "[Organization URI]/api/data/v9.2/$metadata#RelationshipDefinitions/Microsoft.Dynamics.CRM.OneToManyRelationshipMetadata(AssociatedMenuConfiguration)/$entity",
    "MetadataId": "2124b4bd-f013-df11-a16e-00155d7aa40d",
    "AssociatedMenuConfiguration": {
        "Behavior": "UseCollectionName",
        "Group": "Details",
        "Order": null,
        "IsCustomizable": false,
        "Icon": null,
        "ViewId": "00000000-0000-0000-0000-000000000000",
        "AvailableOffline": true,
        "MenuId": null,
        "QueryApi": null,
        "Label": {
            "LocalizedLabels": [],
            "UserLocalizedLabel": null
        }
    }
}

IsCustomizablefalse であることに注目してください。 したがって、リレーションシップはカスタマイズできず、目標関連 メニューに表示されません。

テーブルが Web クライアント (2019 年以降廃止) で作成された場合、統合クライアントに対して無効になっているため、表示されない場合があります。

確認するには、ソリューション エクスプローラー に移動し、テーブル (エンティティ) を選択します。 統合クライアントに対して有効にする がオンになっていることを確認します。

ソリューション エクスプローラーに、エンティティが統合クライアントに対して有効になっていないことが表示される

モダン デザイナーで作成されたテーブルには、この問題は発生しません。 テーブルは常に統合クライアントで有効です。

注意

特定のシステム テーブルは、統合クライアントで有効にすることができません。 たとえば、プロセス セッション はモデル駆動型アプリでは使用できません。

監査履歴 は関連メニューにありません。

トラブルシューティング方法

次の場合、監査履歴はサポートされません。

関連メニュー項目 が表示されるべきではないときに表示される可能性があります。

トラブルシューティング方法

関連メニュー項目が表示される理由は、以下が考えられます。

システムは、自己参照多対多リレーションシップのフォーム XML カスタマイズを無視します。 カスタマイズがプライマリ テーブルに対するものであるか、関連テーブルに対するものであるかを示すことができないため、システムはこれらのカスタマイズを無視します (この場合、両方とも同じテーブル)。 したがって、システムはこれらのカスタマイズを無視します。

フォーム XML を変更して関連メニュー項目を非表示にしても、関連メニュー項目は引き続き表示されます。 関連項目の順序やラベルの変更など、自己参照リレーションシップのフォーム XML カスタマイズはすべて無視されます。

一部のシステム テーブルは非表示にできません

たとえば、カスタム テーブルには常に 活動 関連メニュー項目と表示されます。 フォーム デザイナー を使用したり、フォーム XML を変更したりして非表示にすることはできません。

関連するメニュー項目のテキストが必要な言語ではありません。

トラブルシューティング方法

一部の関連メニュー項目がユーザーの言語とは異なる言語で表示されている場合は、フォーム XML に翻訳されたラベルがないかどうかを確認してください。

フォーム XML をチェックして、言語ごとにラベルが定義されているかどうかを確認します。 たとえば、このフォーム XML は、navContacts 項目に米国英語 (1033) ラベルのみが付いています: Contacts

<NavBarByRelationshipItem Id="navContacts" Area="Sales" Sequence="10064" RelationshipName="contact_customer_accounts" Show="true">
  <Titles>
    <Title LCID="1033" Title="Contacts" />
  </Titles>
</NavBarByRelationshipItem>

この問題を解決するには、翻訳されたラベルをフォーム XML に追加します。 たとえば、このフォーム XML は、米国英語 (1033) とドイツ語 (1031) の両方のラベルが付いている navContacts 項目を表示します。

<NavBarByRelationshipItem Id="navContacts" Area="Sales" Sequence="10064" RelationshipName="contact_customer_accounts" Show="true">
  <Titles>
    <Title LCID="1033" Title="Contacts" />
    <Title LCID="1031" Title="Kontakte" />
  </Titles>
</NavBarByRelationshipItem>

ユーザーの言語のテキストが定義されていない場合、システムは組織の基本言語を使用します。 それも存在しない場合、システムは米国英語のテキストを使用します。

フォーム セレクターにフォームが表示されたり、表示されなかったりするのはなぜですか?

フォーム セレクターは、ユーザーが特定のテーブルの異なるフォームを切り替えることができるドロップダウンです。

フォーム セレクターを拡張すると、利用可能なフォームが表示されます

フォームを表示するかどうかを制御する条件を理解する必要があります。

トラブルシューティング方法

次の条件がすべて満たされる場合、セレクターでフォームを使用できます。

  1. ユーザーはフォームへのアクセス許可を所有しています
  2. フォームがアプリ モバイルに追加されました
  3. フォームはクライアント API では非表示になりません
  4. Dynamics Customer Service workspace フォームの場合、ShowInFormSelectorTrue に設定されます

フォーム セレクターにフォームが表示されない場合は、

  1. 影響を受けるユーザーのセキュリティ ロールを確認してください。
  2. フォームがアプリ モバイルに追加されたかを確認してください。
  3. カスタム スクリプトを無効にする

予期される既定のフォームが既定で表示されないのはなぜですか?

テーブルに複数のフォームがある場合、目的のフォームは既定として使用されません。

トラブルシューティング方法

次の基準によって、ユーザーに表示される最初のフォームが決まります。

  1. フォームを開くときに formId が指定されている場合、そのフォームが表示されます。 formId は、openForm などのクライアント API 関数を使用するか、URL で取得できます。
  2. それ以外の場合は、ユーザーが選択した最新のフォームが表示されます。 システムはフォーム セレクターからの最新の選択内容を記憶しています。
  3. ユーザーがこれまでにフォーム セレクターを使用したことがない場合、システムは フォームの順序を使用します。

ユーザーがフォームを利用できない場合でも、システムは表示する適切なフォームを検索し続けます。

ユーザーは次の場合にフォームを使用できます。

  1. ユーザーはフォームへのアクセス許可を所有しています
  2. フォームがアプリ モバイルに追加されました

ユーザーが利用できるフォームがない場合、フォールバック フォーム が使用されます。

コントロールが無効/有効または表示/非表示の理由

フォームの読み込み時にコントロールが無効になったり非表示になったりする理由はたくさん考えられます。

トラブルシューティング方法

モニターを使用して、フォームの読み込み時の初期コントロール状態に関するすべての詳細を含む FormControls 操作を表示できます。

フォーム コントロール チェック

チェックする別の箇所は ControlStateChange.visible または ControlStateChange.disabled 操作で、そこではフォーム上でコントロールの無効化または表示状態がいつでも変更される理由を説明しています。 この操作では、変更前のコントロールの状態、成功する場合がある意図された状態の変更、および変更後の状態について説明します。 すべてのコントロール状態変更の試行が成功するわけではありません。 フォーム XML によって無効にされたコントロールの場合、クライアント API を介して OnLoad イベント ハンドラーで有効にできます。 ただし、セキュリティ上の理由でコントロールが無効になっている場合、クライアント API を介してコントロールを有効にしようとしても、状態が正常に変更される可能性はほとんどありません。

コントロールの状態が変更された

次のルールの一覧を順番に使用すると、コントロールを無効にできます。 ルールを満たしている場合、次のルールは無視されます。 コントロールを無効にするかどうかを変更する場合は、結果に使用されるルールまたはリストの前のルールへの入力を変更する必要があります。

  • フラグ DisableWebResourceControls=true または DisableFormControl=<control name> が渡され、コントロールがこれらのフラグの影響を受けると、コントロールは無効になります。
  • テーブル定義の統一インターフェイスで所有テーブルが読み取り専用の場合、コントロールは無効になります。
  • テーブルがオフライン モードで使用できない場合、コントロールは無効になります。
  • 現在のユーザーがレコードに対する書き込み権限を持っていない場合、コントロールは無効になります。
  • 列定義で IsValidforCreate が false に設定されると、コントロールは無効になります。
  • 列定義で IsValidforUpdate が false に設定されると、コントロールは無効になります。
  • 現在のユーザーに Assign to 権限がない場合、所有者列は無効になります。
  • ユーザーにフィールド レベルのセキュリティで定義された列に対する書き込み権限がない場合、コントロールは無効になります。
  • クライアント API スクリプトがコントロールを無効または有効にしている場合、コントロールが無効な状態ではその設定が尊重されます。
  • フォーム デザイナーでコントロールが無効になっている場合、コントロールは無効になっています。
  • ユーザーに検索コントロール テーブルに対する Append To 権限、または現在のレコード テーブルに対する Append 権限がない場合、検索コントロールは無効になります

最後に、コントロールが上記のすべてのチェックに合格した場合、レコードの状態によって、コントロールが無効になっているかどうかが判断されます。 コントロールは、アクティブなレコードではデフォルトで有効になっており、非アクティブなレコードでは無効になっています。

注意

FormControlsControlStateChange の違いは、FormControls 操作ではフォームの読み込み時の初期コントロール状態を反映するのに対して、ControlStateChange 操作では、フォームの読み込み中、フォームが読み込まれた後の OnChange イベントまたは OnSave イベントなど、フォームの状態の変化をいつでも反映します。

重要

コントロールの無効状態と非表示状態は、フォームが最初に読み込まれたときに複数回変更される場合があります。 コントロールが非表示または無効になっている理由を知るには、モニターに記録された最後の操作を確認してください。 たとえば、調査対象のコントロールに ControlStateChange.visible/ControlStateChange.hidden の操作がない場合、値と理由は FormControls の操作になります。 それ以外の場合は、最後ControlStateChange.visible/ControlStateChange.hidden 操作での値と理由になります。 ログをタイムスタンプで並び替えて、最後の操作を検索することができます。

コントロールがフォームの読み込みで特定の値を持つ理由

コントロールは、ユーザーが期待するような特定の値をフォームの読み込み時に持たない場合があります。

トラブルシューティング方法

フォームの読み込み時にコントロールが値を持つ理由は多数考えられます。 ControlDefaultValue の操作モニターでは、既定値のソースについて説明しています。

既定コントロール値

コントロールの値に複数の更新が発生している場合、Update Sequence は最終値を示します。 たとえば、これは既定値のコントロールであり、クライアント API スクリプトで渡された値で上書きされます。 提供されたコール スタックがあります。

コントロール値 (前)

関連付けの列マッピングに基づいて列にデータが入力されるシナリオがありますが、その場合、イベントはそれを示します。

コントロール値 (後)

値がどこから来ているかを確認し、以下の表に基づいてアクションを実行します:

Source 修正方法
クライアント API スクリプト スクリプトの所有者に連絡してください。
既定値 コントロールの構成を確認してください。
関連付けの列マッピング 関連付け構成を確認し、列マッピングを更新します。
URL を介して渡されるページ入力データによって渡される値 問題のある特定のフォームを開く API を確認してください。値が渡されています。

タブまたはセクションが表示または非表示になる理由

タブまたはセクションが非表示または表示になる理由はたくさん考えられます。

トラブルシューティング方法

モニターTabStateChange または SectionStateChange 操作は、次の図に示すように、表示状態の変化を説明します。 スクリプトが原因である場合、呼び出しスタックはこの動作の原因となった Web リソース ファイル、行番号、および関数名を表示します。

タブ セクション

状態理由、または Web リソース/ビジネス ルールの所有者の提案に従ってフォローアップし、動作を変更または修正してください。

予期しないダイアログまたはナビゲーション

ダイアログが表示されたり、ナビゲーションが予期せず発生したりする理由は数多く考えられます。 一般的な原因の 1 つは、Xrm.Navigation API メソッドが、カスタム スクリプトによってレコードまたはフォームを開くために呼び出されることです。 たとえば、フォームを開くと、次の図に示すように、アラートが表示されます。

通知ダイアログ ボックス

トラブルシューティング方法

モニターXrmNavigation 操作には、予期しない動作を引き起こしているスクリプトを特定するのに役立つ呼び出しスタックが含まれます。

モニターでの XrmNavigation 操作

Web リソースの所有者と連絡を取って、動作を変更または修正してください。

クイック作成フォームの代わりに別のフォームを開く

ルックアップまたはグリッドからクイック作成フォームを開くと、クイック作成フォームの代わりに別のフォーム (編集またはメイン フォーム) が開く場合があります。 この問題が発生する理由はいくつかあります。

  • メイン フォーム ダイアログの強制フラグが設定されている。
  • クイック作成フォームを利用できない。

トラブルシューティング方法

モニターを使用して、クイック作成フォームが開かないすべての理由を含む FormType 操作を表示できます。

テーブルが簡易作成に対して有効になっていない

テーブル定義 (メタデータ) によるクイック作成を無効にしたテーブル所有者に連絡を取る必要があります。

テーブルが簡易作成メニューのポップアップに表示されない

グローバル簡易作成メニューのポップアップを開いても、すべてのテーブルが使用できるわけではありません。 このリストでテーブルがフィルターされる理由はいくつかあります:

  • テーブルで使用できる簡易作成フォームがない。
  • テーブルが簡易作成フォームに対して有効になっていない。
  • テーブルが新しい統一インターフェイスに対して有効になっていない。
  • テーブルが統一インターフェイスで読み取り専用である。
  • テーブルのモバイル クライアントの可視性が変更できない。
  • テーブルがアプリ モジュールの一部ではない。
  • ユーザーには、テーブルに対する作成権限がない。
  • テーブルの作成権限がサポートされていない。

トラブルシューティング方法

モニターを使用して QuickCreateMenu 操作を表示できます。これには、すべてのテーブルと、それらが簡易作成メニューのポップアップからフィルター処理される理由が含まれます。

フィルター処理の理由を理解するには、以下の例を参照してください。 説明に基づいて、当事者に連絡するか、適切な変更を加えます。

テーブルが統一インターフェイスで有効でない

テーブルが簡易作成に使用できない

テーブルがアプリ モジュールの一部ではない

予期しない未保存の変更メッセージ

フォームで作業する際、現在のフォームから移動したとき、またはフォームが変更なしで保存されると、フォーム フッターに未保存の変更メッセージが表示されます。

トラブルシューティング方法

未保存の変更 エラーは、フォームに変更を加えても、変更が保存されなかった場合に表示されます。 手動で変更を加えていない場合は、JavaScript、プラグイン、またはビジネス ルールから変更されている可能性があります。 モニターを使用して、変更のソースを見つけるのに役立つ UnsavedChanges 操作を表示できます。 OperationType UnsavedChanges でフィルタリングできます。

all attributes modified セクションには、未保存の変更エラーの原因となっている列の概要とその値が含まれています。 unsaved changes セクションでは、列に何が起こったかを詳細に示します。 すべての列について、変更を引き起こす可能性のあるコントロールのリストが表示されます。 値の変更 (previousValue、newValue)、および呼び出しスタックも表示されます。

以下のスクリーンショットは、問題の根本的な原因を示しています。 変更が OnLoad スクリプトから来ていることがわかります。

変更があり保存されていないエラー

注意

ユーザーがフォームに手動で変更を加えた場合、呼び出しスタックは提供されません。

変更がどこからのものか、およびそれが期待される動作であるかどうかを確認します。 スクリプトによって変更が発生した場合は、元の Web リソースを呼び出しスタックでさかのぼることができます。 ほとんどの場合、それはスクリプトです。 Web リソース自体に基づいて決定します。

ビジネス必須の列検証が期待どおりに動作しない

ビジネス必須の列は、値が空の場合、既定でフォーム保存操作をブロックします。 ただし、多くの設計上のシナリオでは、ビジネス必須の列は、値が空の場合は保存操作をブロックしないか、必要がないと思われる場合は保存をブロックしない場合があります。

トラブルシューティング方法

保存が成功したかどうかに関係なく、保存が試行されると RequiredFieldValidation 操作がログに記録されます。 この操作は、ビジネス必須の各列が保存操作をブロックする理由またはブロックしない理由を説明します。

次の図は、この操作の例です。 メッセージは、必須の各列の詳細レポートの読み取る方法を説明しています。 この例では、fax 列は 1 つのコントロールにバインドされており、同じ名前のコントロールは読み取り専用です。 したがって、必要な列の検証はトリガーされません。

列の検証

以下の画像で示す例は、jobtitle はビジネス プロセス フローにあってフォームにはないビジネス必須の列ですが、列は変更されません。 したがって、空の場合でも保存操作がブロックされることはありません。

必須の列の検証

フォローアップ

ほとんどの場合、動作は設計上のものであり、RequiredFieldValidation 操作は、この列がフォーム保存操作の特定の方法で動作する理由を説明します。 最初の例で示したように、コントロールが無効または非表示であるために必須の列の検証が列でスキップされた場合は、フォーム チェッカーの提案を参照してさらに分析してください。

これにより、コントロールが無効/有効または表示/非表示である理由など、別のトラブルシューティング シナリオが発生する可能性があります。

一部の列が結合ダイアログに表示されない

結合ダイアログは、テーブルの既定のメイン フォーム定義を使用し、ダイアログ内のすべての列ではなく、ほとんどの列を選択的にレンダリングします。 このフォーム チェッカー操作では、メイン フォームに表示されている場合でも、一部の列が結合ダイアログに表示されない理由を説明します。

トラブルシューティング方法

以下の MergeDialog.load 操作では、一部の列が表示されない理由を説明します。

この例では、問い合わせフォームの parentcustomerid 列が結合ダイアログでサポートされていません。 含まれているセクションがメインフォームの XML 定義で非表示になっているため、名刺の列は表示されません。 クライアント API を介してメイン フォームに所有セクションを表示することは可能ですが、結合ダイアログではイベント ハンドラーがサポートされていないため、結合ダイアログではフォームの XML 構成が考慮されます。

結合ダイアログの読み込み

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。