移行ツールに関するよくあるご質問

自動レコード作成ルールとサービス レベル アグリーメント (SLA) の移行ツール

移行ツールにアクセスまたは実行できる人

管理者と CSR マネージャーの役​​割を持つユーザーは、移行ツールを実行できます。

移行されたルールは、移行後に自動的にアクティブ化されますか ?

いいえ。 移行が完了したら、移行したルールを手動でアクティブ化する必要があります。

非推奨期限後もレガシ ルールを使用できますか?

はい アクティブなレガシ ルールは、ルールが非アクティブ化されるまで、廃止されるまで引き続き実行されます。 ただし、編集エクスペリエンスとサポート性は非推奨になった後は停止します。

移行ステータスが「不完全」の移行ステータスを持つルールをアクティブ化できますか?

いいえ。 移行されたルールは、不完全なルールを確認し、存在する問題を修正した後、完了としてマークする を はい に切り替えた場合にのみアクティブになります。 この時点で、ルールは正常に移行されたとみなされます。

移行後、従来のルールは無効になりますか?

• 自動レコード作成ルールは、「はい」にします。 統一インターフェイスで移行された 自動レコード作成ルールをアクティブ化する場合、対応するレガシ ルールは非アクティブ化されます。
• SLA の場合は、「いいえ」です。 統一インターフェイスで移行された SLA ルールをアクティブ化する場合、対応する 2 つのレガシ ルールは共存できるためアクティブ化されたままになります。

"未完了" 移行ステータスとはどういう意味ですか?

• 概要セクション: 移行プロセス全体が、選択したすべてのルールの移行を正常に完了できなかったことを意味します。
• ルールの横:そのルールにエラーがあるか、完全に移行できなかったことを意味します (1 つ以上の項目または条件の移行に失敗した)。

移行ツールで追跡される部分的に移行されたルールのリストはどこにありますか ?

部分的に移行されたルール、または不完全に移行されたと識別されたルールは、完全に移行されたとは見なされません。 したがって、それらは まとめ セクションの 保留中 で追跡されます 移行が正常に完了したルールのみが、移行済み でカウントされます。

移行ツールは、カスタム フォームやカスタム フィールドをサポートしますか?

• 自動レコード作成ルールは、「はい」にします。 移行ツールカスタム エンティティ、フィールド、属性、構成をサポートしています。
• SLA の場合は、「いいえ」です。 移行ツールはカスタム エンティティ、フィールド、属性、構成を完全にはサポートしていません。 移行を完了するには、ユーザーはカスタム エンティティ、フィールド、属性、構成上の既存のカスタマイズ フロー、ワークフロー、プラグイン、またはその他のカスタム コードを変更する必要があります。

移行を実行する前に、Power Automate に対して別のライセンスが必要ですか ?

いいえ。 ライセンス取得のガイドラインの詳細については、Dynamics 365 アプリケーションに対する Microsoft Power Apps と Power Automate の使用権とは ? を参照してください。

自分の一部のルールが未完了であるか、部分的にしか移行されていません。 どうすればよいですか。

問題の詳細に基づいて Web クライアントで問題の詳細を使って移行に戻るか、移行されたルールを統一インターフェイスで直接修正することができます。

特定の移行済みルールに対して移行ツールを再実行できますか？

はい、以下の条件に基づいて、特定の移行済みルールの移行ツールを再実行できます。

• 未完了、または失敗した移行ルールの場合: 移行ツールを再実行するときに、同じルールを選択します。 ツールは、既存の未完了または失敗したルールを新しく移行されたルールに自動的に置き換えます。
• 正常に移行されたルールの場合: 移行ツールを再実行する前に、統一インターフェイスで移行したルールを削除してください。

移行が完了すると、従来の SLA に関連付けられている既存の SLA レコードはどうなりますか?

• 移行後に従来の SLA が非アクティブ化された場合: タイマーは、そういった SLA レコードの終了状態になるまで実行され続けます。 しかし 解決 と 一時停止 機能が動作しなくなります。
• 従来の SLA がまだアクティブ状態である場合: 従来の SLA に関連付けられている既存の SLA レコードは、引き続き期待どおりに機能します。
• 統一インターフェイス アプリで作成された SLA を既存のレコードに使用する場合: SLA フィールドを手動で 統一インターフェイス SLA に更新するか、レコードを更新するプラグインを作成する必要があります。 たとえば、プラグイン ロジックは、Modern Flow または Workflow である可能性があります。

最新の自動レコード作成で移行されたルールまたはフローについては、最新の自動レコード作成に関する FAQを参照してください。

条件変換に関する既知の問題

このセクションでは、ルールまたはアイテムが移行を正常に完了しない主なシナリオについて説明されています。

自分のルール アイテムやルール条件がネストされたグループ句内に関連エンティティがある場合、統一インターフェイスに移行されますか ?

いいえ。 現在、関連するエンティティ階層の 1 つのレベルのみをサポートしています。 このようなルール アイテムまたはルール条件は、移行する前にグループ句内の関連エンティティを削除した場合にのみ正常に移行できます。 何もアクションを実行しない場合、ルールは 移行前チェックアップ ステップで失敗します。 移行を続行することを選択した場合、ルールには関連アイテムの条件が空になります。

例: ネストされたグループ句内の関連エンティティ

移行前の Web クライアント ビュー

凡例:

a. アイテムのタイトル。

移行後の統一インターフェイス ビュー

凡例:

2a. "_FailedMigration" が、移行したアイテムのタイトルに付きます。

2b. 同じ標準プレースホルダー Created On equals 2200-01-01 が条件に追加されます。

Not-On 演算子を使用する日付型フィールドを持つルール アイテムや条件が、移行前のチェックアップや実際の移行中にエラーとなるのはなぜですか ?

日付 データ型の Not-On 演算子は、統一インターフェイスでサポートされていません。 したがって、移行の一部としてはサポートされていません。 この問題を修正するには、それぞれ対応するルールの移行ツールを再度実行する前に、Web クライアントでレガシ アイテムか条件を {not-on selecteddate} から {selecteddate less than and selecteddate greater than} へ変更することができます。

例: Not-On 演算子を使用する DateType フィールド

移行前の Web クライアント ビュー

凡例:

a. アイテムのタイトル。

移行後の統一インターフェイス ビュー

凡例:

2a. "_FailedMigration" が、移行したアイテムのタイトルに付きます。

2b. 条件 Created On equals 2200-01-01 が条件に追加されます。

移行中に自分の DateTime フィールドのデータが変更されるのはなぜですか ?

統一インターフェイス には個別の時刻フィールドは存在しません。 したがって、DateTime フィールドはカレンダー コントロールからテキスト フィールドに変更されます。 次の例のテキスト フィールドに示すように、入力は特定の形式である必要があります。

例: DateTime フィールド

移行前の Web クライアント ビュー

凡例:

a. 移行前の 日時 フィールド。

b. 移行前の 日付のみ フィールド。

移行後の統一インターフェイス ビュー

凡例:

a. 移行後 日時 フィールド。

b. 移行後 日付のみフィールド。

移行後、統一インターフェイスの自分の一部の演算子フィールドが空欄になるのはなぜですか?

ルックアップ データ型の場合、equal、not equal, null、not null 演算子のみが統一インターフェイスでサポートされており、そして移行ツールでサポートされています。 Under 演算子と not-under 演算子は統一インターフェイスではサポートされていないため、移行ツールではサポートされていません。 under または not-under 演算子を含む条件は、移行後 関連エンティティとして変換されます。 統一インターフェイスでは空白として表示され、編集できません。

例: Under および not-under 演算子フィールド

移行前の Web クライアント ビュー

凡例:

a.Under 演算子。

移行後の統一インターフェイス ビュー

凡例:

b. 空白の演算子フィールド。

注意

顧客サービス ハブで条件を定義する場合、次の制限が適用されます。

• Date & Time ピッカー コントロールは条件で使用できなくなりました。 ただし、テキスト フィールドで日付と時刻を編集することはできます。
• 関連するエンティティ階層の 1 つのレベルのみをサポートしています。 ただし、アプリケーション内のネストされた関連エンティティを選択することはできます。
• And / or 句のグループ内の関連エンティティには対応していません。
• Date データ型の Not-on 演算子はサポートされていません。
• Lookups のデータ型では、equal、not equal、null、not null の演算子はサポートされています。 Under 演算子と Not Under 演算子は、サポートされていません。

有効化したルールを再度移行できますか?

• 自動レコード作成ルールでは、「はい」です。 アクティブ化されたルールを再度移行することはできますが、まず非アクティブ化して統一インターフェイスから削除する必要があります。
• SLA の場合は、「いいえ」です。 移行された SLA ルールがアクティブ化された後、別のエンティティ (ケースや使用中の場合など) にリンクされます。 デフォルトでは、アクティブ化されたルールは正常に移行されています。 アクティブ化されたルールを再移行するには、まず、その組織を削除する必要があります。 ただし、統一インターフェイス SLA ルールには制限があります。 ルールがケースまたはエンティティに関連付けられた後 (つまり、ルールが一度有効化された後)、非アクティブ化されていても削除することはできません。 したがって、ルールが以前アクティブ化されたり適用された場合は、そのルールを再度移行することはできません。

非推奨の標準 SLA ルールを移行できますか ?

いいえ。 移行ツールは、拡張 SLA ルールのみをサポートします。 標準の SLA ルールは廃止されました。 これらは、統一インターフェイスでサポートされなくなったため、移行ツールでもサポートされていません。 詳細については、Dynamics 365 Customer Service の標準 SLA は非推奨になりました を参照してください。

既知の問題

チャネル プロパティの廃止

従来のルールのカスタマイズでチャネル プロパティを使用した場合、移行ツールはそれらのルールを正常に移行できません。 すべてのユーザーに対してこのギャップを修正するために適用できる一般的な回避策はありません。 回避策は、レガシー ルールでのチャネル プロパティの使用方法に大きく依存します。

[解決済みのサポート案件に関連付けられている活動に対してサポート案件を作成] オプションが選択されている場合の動作の違い

• 従来の動作: 指定された時間以降に解決された関連ケースが電子メールに含まれている場合、解決されたケースはデフォルトで再アクティブ化されます。 カスタマイズの必要はありません。
• 新しい動作: 指定された時間以降に解決された関連ケースが電子メールに含まれている場合、デフォルトで新しいケースが作成されます。 新しいサポート案件を作成する代わりに、既存のサポート案件を再アクティブ化するには、カスタマイズが必要です。

[顧客に有効な資格が存在する場合にケースを作成する] オプションが選択されている場合の動作の違い

• 従来の動作: メール送信者に有効な資格がなく、メールに関連するケースがある場合、既存の関連ケースが更新されます。
• 新しい動作: メール送信者に有効な資格がない場合、フローは呼び出されません。

ワークフローと Power Automate フロー間の Parityギャップ (ルール アイテム アクションのカスタマイズにのみ適用)

• 「First not null」式は自動的に移行できません。 ただし、カスタマイズは移行のフローに手動で適用できます。
• 検索レコードの表示名の文字列フィールドへのマッピングは、自動的に移行できません。 ただし、カスタマイズは移行のフローに手動で適用できます。
• ソース フィールドとして使用される活動関係者フィールドは、フローではサポートされていません。

フローに関する既知の問題

移行されたルールには、@ 文字列型のフィールドに追加の @ 文字があります

従来の自動レコード作成ルール ワークフローがカスタマイズされており、文字列フィールドにプレーン テキストの @ 文字がある場合、移行時に 1 つではなく 2 つの @ が表示されます。 たとえば、ケースの説明フィールドにメール アドレスをプレーン テキストで追加すると、@ 文字は特殊文字として扱われ、@@ として移行されます。

これは、移行フローで @triggerOutputs()?[body/_emailsender_value] などの動的表現の特殊文字として識別されるためです。

回避策は、移行されたフロー内の余分な @ を手動で削除することです。

移行では、同じ SLA 内で "適用可能な場合" が同じ複数アイテムや条件はサポートされません

Web クライアントでは、複数のアイテムを、SLA に対して同じ "適用可能な場合" の条件と異なる成功基準を使って定義できます。 ただし、同じ機能は統一インターフェイスではサポートされていません。 したがって、移行中、同じ "適用可能な場合" 条件を持つこの種類の SLA アイテムはそれ以降作成されません。

次のスクリーンショットは、統一インターフェイスでサポートされていないシナリオを表示しています。 異なる成功基準を持つ 2 つの [applicable when] 条件。

ワークフローからフローへの変換している間の活動パーティー型属性に関する問題

別の活動関係者型フィールドに割り当てられた活動関係者型属性は、Power Automate が現在このようなシナリオをサポートしていないため、ワークフローからフローへの変換中に移行されません。 (最も一般的に影響を受けるフィールドは、To、From、CC、電子メールの BCC フィールド。) ルールの移行は失敗しませんが、そのような活動関係者タイプ フィールドのデータ値は、別の活動関係者のタイプ属性は、移行後は空白になります。

例: 活動の関係者タイプ属性

移行前の Web クライアント ビュー

凡例:

a. From フィールドは、別の活動関係者タイプ属性 {Bcc(Email)} が割り当てられている活動関係者タイプ フィールドです。 移行後は空白になります。

b. To フィールドは移行されます。

移行後の統一インターフェイス ビュー

凡例:

b.To フィールド。

ワークフローからフローへの変換中にレガシ ワークフロー内の式の "First not null" チェックは、サポートされていません

レガシ ワークフローでは、検索フィールドを複数の式にマッピングします。ここでは "First Not Null" 式を以下の Web クライアントの例に示すように確認して割り当てます。 レガシ ワークフロー デザイナーにおける既知の制限事項により、このアプローチは、ワークフローからフローへの変換の一部としてはサポートされていません。 したがって、ワークフロー コンバーターは、null チェックを実行せずに最初の式を割り当てます。 次に、null 以外の値があるかどうかに関係なく、残りの式をすべて削除します。 次の例では、このフローはこのステップ内の 顧客 フィールドの 関連 (メール) のみを持ちます。

例: "First Not Null" 式

移行前のビュー

凡例:

a.Web クライアント ビュー: ワークフローでは、顧客フィールドは、{Regarding(Email); Contact(Create (Case)); Customer(Create (Case))} を持ちます

統一インターフェイスでは、顧客フィールドは null かどうかに関係なく 関連 (メール) のみを持ちます。

重要

移行ツールに関する問題が引き続き発生する場合は、自分の管理者か Microsoft サポートにお問い合わせください。

参照

最新の自動レコード作成に関する FAQ

自動レコード作成ルールと SLAを移行する

Dynamics 365 SLA および ARC 移行プレイブック