はじめに
Customer Zero(自社D365 Sales導入)の一環として、ライセンス更新90日前の顧客に対してMicrosoft Bookings連携付きの案内メールを自動配信する仕組みを構築しました。今回はその実装過程で遭遇した課題と解決策をまとめます。
対象読者:CI-Data / CI-Journeysで「セグメントは作ったのにメールが送れない」「型が合わないと怒られる」といったエラーに悩んでいる方。
やりたかったこと
- ライセンス更新90日前になったら、顧客に面談予約リンク付きメールを自動配信する
- メール送信から1週間後、予約が入っていなければ営業担当者にフォローアップタスクを出す(※今回は除外)
1. Microsoft Bookingsで予約ページを構築する
まず、面談予約の受け皿としてBookingsに共有予約ページを作成しました。
担当者振り分けの設計
当初は担当者ごとに個別リンクを発行する案(パターンB)を検討しましたが、最終的には1つの会議の種類に複数スタッフを割り当て、空いている担当者に自動振り分けする方式を採用しました。理由は運用のシンプルさです。
- ✅ 営業担当者を担当スタッフとして登録
- ❌ 退職予定のメンバーは対象から除外
💡 ポイント: 「選択したスタッフを予定に割り当てます」モードにしておくと、チェックを入れた複数人の中から空いている人へ自動的に割り当てられます。顧客に担当者を選ばせる必要がありません。
ハマったポイント:管理画面のプレビューが変な時刻を表示する
営業時間を9:00〜17:00に設定しているのに、管理画面上のプレビューでは「0:00」「0:30」といった深夜の時間帯が表示され焦りました。
原因を切り分けるため、実際に公開されるURLをシークレットウィンドウで直接開いたところ、正しい時間帯(12:00〜16:30など)が表示されることを確認。管理画面内プレビューの表示バグであり、実際の予約ページには影響がないと判断しました。
| 症状 | 原因 | 対処 |
|---|---|---|
| 管理画面プレビューで深夜の時間帯が表示される | プレビュー機能側の表示不具合(推測) | 公開URLを直接シークレットウィンドウで開いて実際の挙動を確認 |
2. CI-Dataセグメントの再設計(Account基準→Contact基準)
既存の「①ライセンス期限90日以内」セグメントはAccount(取引先企業)を基準に作られていましたが、メール配信にはメールアドレスを持つContact(取引先担当者)が必要です。
起きたエラー
CI-Journeysのメール編集画面で以下の警告が表示されました。
この体験は Customer Insights - Data プロファイルをターゲットにしていますが、選択したメッセージは取引先担当者に合わせてパーソナライズされます。
対処:セグメントを複製してContact起点に組み直す
既存セグメントの「詳細の編集」を確認したところ、ベーステーブル(Account/Contact)は後から変更不可であることが判明。複製の上でゼロから条件を組み直しました。
- **交差(Intersect)**でルール1・2の両方を満たすメンバーのみ抽出
- 結果、8件のメンバーが正しく抽出された(元のAccountベースと同数で整合性を確認)
⚠️ 注意: ドロップダウンの初期値には要注意です。ルール1は最初「contact.Id は 空」(意味が逆)になっていたり、ルール2の日付範囲が「明日以降」と「昨日以前」で左右逆になっていたりと、テンプレートの初期状態のまま進めると意図と逆の条件になることがあります。
3. メール本文のパーソナライズで型不一致に苦戦
セグメントをContact起点に直しても、メール本文に既存の{{#each 取引先担当者}}(Account配下の複数Contactをループする構文)が残っていたため、公開時に同じ型不一致エラーが再発しました。
解決策:パーソナライズの「リセット」
動的テキスト作成パネルには「データは取引先担当者でフィルター処理されます」という制限メッセージが表示されることがあります。この状態のまま選択しても型不一致は解消されません。
「リセット」リンクをクリックしてから改めて対象者ツリーを開くと、「取引先担当者」だけでなく「CustomerProfile」という選択肢が現れます。ここから氏名フィールド(msdynci_lastname)を選択することで、型が揃いました。
4. コンプライアンス設定(Commercial目的の必須項目)
メールの「目的」を Commercial(商用) に設定すると、法令遵守のため以下2つのプレースホルダーが本文に必須となります。
- 会社の住所(
{{CompanyAddress}}) - 基本設定センター(配信停止リンク、
PreferenceCenter)
これらはメールヘッダー設定パネルの歯車アイコンから「コンプライアンスプロファイル」→「default」を選択し、目的を「Commercial」に設定した上で、本文フッターにパーソナライズ挿入する形で解消しました。
5. 公開時の権限エラー:tec_autocounterの読み取り権限不足
すべての設定を終えていざ公開したところ、以下のエラーで止まりました。
調査の結果、tec_autocounterは環境に導入済みの自動採番アドオン(Soluzione Auto Counter)が使用するテーブルで、CI-Journeysの裏側で動くアプリケーションユーザー「Dynamics Marketing Customer Experience Platform PROD」に、このテーブルへの読み取り権限のみが不足していたことが原因でした。
対処手順
- Power Platform管理センター → 対象環境 → 設定 → セキュリティロール
- 「Marketing Services User Extensible Role」を開く(まさにこの用途のための拡張可能ロール)
- テーブル検索で「auto」と入力し、
Auto Counter(tec_autocounter)の読み取り列を「組織」に変更 - 保存
作成権限は不要と判断し、読み取りのみ最小権限で付与しました。
6. 公開成功、そして一時停止
権限追加後、無事に公開が完了しました。テストデータへの誤配信を防ぐため、いったんジャーニーを一時停止状態にしています。
今回のトラブルシューティングまとめ
| # | 症状 | 原因 | 対処 |
|---|---|---|---|
| 1 | 管理画面プレビューの時刻がおかしい | Bookings管理画面側の表示バグ(推測) | 公開URLを直接確認 |
| 2 | セグメントとメールの対象者が噛み合わない | AccountベースのセグメントとContact向けメールの型不一致 | セグメントをContact起点で再構築 |
| 3 | パーソナライズで同じ型不一致が再発 | 既存の{{#each}}構文がContact型のまま |
「リセット」からCustomerProfile型のフィールドを選び直す |
| 4 | Commercial目的で新たな警告 | 会社住所・配信停止リンクが本文に未挿入 | コンプライアンスセクションで必須要素を挿入 |
| 5 | 公開時に権限エラー | アドオンテーブルへの読み取り権限不足 | セキュリティロールに読み取り権限を追加 |