ソース.csvファイルのデータを操作する

外部連絡先 

外部IDはGenesys Cloudの必須キーフィールドです。インポートプロセス一意の連絡先を決定するために使用します。このフィールドは連絡先を識別するのに役立ち、同じスプレッドシートを介して既存の連絡先を簡単に更新できます。インポート プロセスでは、一意の外部 ID ごとに 1 つの Genesys Cloud 外部連絡先レコードが作成されます。インポート プロセスでは、行内のすべての連絡先フィールドが、対応する Genesys Cloud 外部連絡先レコードにインポートされます。

bulk39

外部 ID を作成するときは、文字と数字の任意の組み合わせを使用できます。たとえば、CRM または ERP システムの一意の識別子を使用することも、自分にとって意味のある複合キーを作成することもできます。255 文字の制限を満たしていれば、レコードを識別するために使用する任意の外部 ID を使用できます。.csv が CRM から抽出される場合は、CRM の一意の識別子 (UUID) を使用することをお勧めします。UUID を使用すると、今後の機能更新で CRM から連絡先を同期できるようになります。

レコードを1回だけインポートする予定の場合は、必要な外部IDを使用できます。 システムは、これらの外部IDに対応するように内部IDを生成します。

メモ: 
  • 以前に連絡先をインポートしたことがある場合は、古い一括インポート プロセスでは、システムは電話番号または電子メール アドレスの識別子のみを使用して、連絡先を新しい外部 ID と照合し更新します。
  • .csv 一括インポートを実行するときに既存の連絡先を新しいレコードと正常にマージするには、電話で照合するときに .csv ファイル内のすべての電話番号が E.164 形式に従うことが重要です。
  • .csv ファイル内の電話番号が E.164 形式に準拠していない場合、インポート プロセスのデータ検証手順で警告が表示されます。インポート プロセスが連絡先のインポートを続行している間、ID 解決アルゴリズムが電話番号に基づいて連絡先を正確に照合して結合するという保証はありません。
  • 古い連絡先に、新しい .csv ファイル内の電子メールまたは電話番号と一致する電子メールまたは電話番号がない場合、システムは .csv 内に指定された外部 ID を持つレコードを作成します。
  • 連絡先の情報が同じファイル内で複数回繰り返されている場合、連絡先は複数回更新され、インポートされた行カウンタにその繰り返しが反映されます。ただし、更新が行われる順序は保証されません。

以前にインポートした連絡先を更新するときは、重複レコードが作成されないように、同じ外部 ID を使用するようにしてください。

連絡先の情報がファイル内で複数回繰り返されている場合、連絡先は複数回更新され、インポート回数にその繰り返しが反映されます。ただし、更新が行われる順序は保証されません。

たとえば、外部 ID として「A」を使用してレコードを含むスプレッドシートをインポートし、後でそのレコードの外部 ID として「B」を使用して同じスプレッドシートを再インポートすると、Genesys Cloud は既存のレコードを更新する代わりにレコードを作成します。既存のレコードを更新するには、常に同じ外部 ID を使用します。

ノート:  電話番号は、その電話番号との通話およびSMSインタラクションを同期するためにE164形式である必要があります。

外部組織

T外部組織の外部IDインポートプロセスで一意の組織を決定するために使用するキーフィールド インポート プロセスでは、一意の外部組織外部 ID ごとに 1 つの Genesys Cloud 外部組織レコードが作成されます。インポート プロセスでは、行内のすべてのアカウント フィールドが対応する Genesys Cloud 外部組織レコードにインポートされます。

bulk39

外部組織の外部 ID を作成するときは、文字と数字の任意の組み合わせを使用できます。255 文字の制限を満たしていれば、自分にとって意味のある複合キーを作成できます。.csv が CRM から抽出される場合は、CRM の一意の識別子 (UUID) を使用することをお勧めします。UUID を使用すると、今後の機能更新で CRM から連絡先を同期できるようになります。

外部連絡先を外部組織と関連付ける

外部連絡先を外部組織に関連付けるには、.csv ソース ファイル内の同じ行に入力します。

 メモ:   次の例では、一部のフィールドがサイズ変更または非表示になっています。

この例では、Angus Reid は Phoenix Foundation II の問題解決者です。インポート プロセスにより、Phoenix Foundation II の外部組織レコードと Angus Reid の外部連絡先レコードが作成されます。「外部連絡先」では、アンガス・リードがフェニックス財団 II 組織の外部連絡先として登場します。 

bulk39

複数の外部を関連付ける との連絡 外部の 組織

複数の外部連絡先を1つの連絡先に関連付けるには外部の組織ごとに、同じ外部組織外部 ID を割り当てます。 

 メモ:   次の例では、一部のフィールドがサイズ変更または非表示になっています。

この例では、Kathryn、Josh、およびRebeccaは、すべてOffice Mart組織の連絡先です。

bulk39

メモ: 
  • インポート プロセスで同じ外部組織外部 ID を持つ複数の行が検出されると、Genesys Cloud はすべてのフィールドでアカウント データが同じであると想定します。たとえば、外部組織の外部 ID が同じであるすべての行では、アカウント名が同一である必要があります。複数の行に同じ外部組織外部 ID がある場合、インポート プロセスではアカウント データの行のうち 1 つだけがインポートされます。Genesysは、プロセスがインポートするアカウントデータの行を保証しません。アカウントの行セットの最初または最後の行である必要はありません。したがって、アカウント データのすべての行は同一である必要があります。
  • .csvファイルを使用して、手動で作成した組織にメンバーをインポートすることはできません。

一括インポートプロセスがマージアクションを管理する方法

この例では、連絡先のみをインポートし、.csv ファイル内のすべての外部連絡先組織フィールドが空であると想定します。

一括インポート プロセス中に、インポート プロファイル画面で次のオプションが選択されました。

  • 連絡先の一致:外部ID、電話番号、メールアドレス
  • 一致した連絡先を統合する:一致するすべての連絡先を結合して更新する

この例では、検索される識別子の順序は次のとおりです。

  1. ExternalID:123AABC
  2. 電話: +1 919 432 5523
  3. email: tom.sellenta@sag.aftra.com

.csv の勤務先電話番号は連絡先 C の携帯電話番号と一致します。新しいマージされた ContactD が作成されます。

次の表では、

  • フィールド名列には、.csv ファイル内のフィールド名が示されます。
  • CSV データ (エンリッチ要求) 列には、.csv ファイルのデータが表示されます。
  • 連絡先 B 列は、Genesys Cloud でキュレーションされた連絡先です。
  • 連絡先 C 列は、Genesys Cloud でキュレーションされた連絡先です。
  • 連絡先 D 列は、インポート完了後に結合された連絡先です。
  • 説明列には、連絡先 D 列のデータがどのようにインポートされたかが説明されています。 
フィールド名 CSV データ (エンリッチ リクエスト) 連絡先B 連絡先C 連絡先 D (統合された連絡先) 説明
外部 ID 123AABC 123AABC .csv レコードの外部 ID は、マージされたレコードの主な識別子として強化されます。古い .csv インポートで使用されていた連絡先 ID は、連絡先レコードでは使用されなくなり、表示されなくなりました。
トム トミー トム トム データが競合している場合、マージされた連絡先には .csv ファイルの最新データが保持されます。
middleName T T 衝突なし
Selleck Selk Selleck データが競合している場合、マージされた連絡先には .csv ファイルの最新データが保持されます。
タイトル 問題解決者 問題解決者 連絡先 C の値が使用されます。
salutation Mister Mr. Mister データが競合している場合、マージされた連絡先には .csv ファイルの最新データが保持されます。
work Email tom.selleck@sag.aftra.com tom@gmail.com tom.selleck@sag.aftra.com tom.selleck@sag.aftra.com データが競合している場合、マージされた連絡先には .csv ファイルの最新データが保持されます。
personal Email tom@hotmail.com tommy@yahoo.com tom@gmail.com データの損失を避けるために、マージ中は電子メールと電話番号は慎重に処理されます。2 つの連絡先が同じフィールド (workEmail など) を使用している場合、データは別の使用可能なフィールド (personalEmail や otherEmail など) に移動されます。

この例では、「tom@gmail.com」は削除されるのではなく、workEmail から personalEmail に移動されます。このプロセスは、すべての可能なフィールドが使用されるまで繰り返し続行されます。利用できるフィールドがなくなった場合、データは削除されます。 
その他メール tommy@hotmail.com 特定のフィールド名は重要ではなく、可能な限り、マージされた連絡先のデータが保持されます。再配置可能なフィールドが残っていない場合、データは削除されます。 
cell Phone +1 919 432-5523 .csv の勤務先電話番号は連絡先 C の携帯電話と一致します。このフィールドは、.csv データの携帯電話番号 (この場合は空) のインポート後に更新されます。
work Phone +1 919 432-5523 +1 317 845-1232 +1 317 845-1232 [インポート フィールド] チェックボックスがオフになっているため、インポート後も連絡先 C の勤務先電話番号は変更されません。
自宅電話 更新がなければ、連絡に価値はありません。
その他電話 更新がなければ、連絡に価値はない

この例では、連絡先のみをインポートします。.csv ファイル内の外部組織フィールドは空であると想定されます。

一括インポート プロセス中に、インポート プロファイル画面で次のオプションが選択されました。

  • 連絡先の一致:外部ID、電話番号、メールアドレス
  • 一致した連絡先を統合する:最初に一致した連絡先のみ更新

この例では、検索される識別子の順序は次のとおりです。(メール ID は ExternalID の前に来ます)

  1. ExternalID:123AABC
  2. email: tom.selleck@sag.aftra.com
  3. 電話: +1 919 432-5523

.csv の勤務先メールは連絡先 C の勤務先メールと一致し、勤務先電話は連絡先 B の携帯電話と一致しました。「一致したすべての連絡先を結合して更新する」オプションが選択されていないため、両方の連絡先が CSV データと部分的に一致しているにもかかわらず、インポート後に連絡先 C のみが更新され、連絡先 B は変更されません。

次の表では、

  • フィールド名列は .csv ファイル内のフィールド名を示します。
  • CSV データ (エンリッチ リクエスト)列は .csv ファイルのデータを示します。
  • 連絡先B列は、Genesys Cloud でキュレーションされた連絡先です。
  • 連絡先C列はGenesys Cloudでキュレーションされた連絡先です
  • 連絡先Cを更新しました列は、インポート完了後のマージされた連絡先です。
  • 説明列は、連絡先 D 列のデータがどのようにインポートされたかを説明します。 
フィールド名 CSV データ (エンリッチ リクエスト) 連絡先B 連絡先C 連絡先Cを更新しました 説明
外部 ID 123AABC 123AABC

.csv レコードの外部 ID は、連絡先 C レコードの主な識別子として強化されます。

古い .csv インポートで使用されていたアカウント ID は、連絡先レコードでは使用されなくなり、表示されなくなりました。

トム トミー トム トム 衝突がなければ、変化もない。
middleName T .csv のデータを使用して連絡先 C を更新します。
Selleck Selk Selleck 対立。.csv のデータを使用して連絡先 C を更新します。
タイトル 問題解決者 問題解決者 インポート フィールドのチェックが外れているため、更新はありません。
salutation Mister Mr. Mister 対立。.csv のデータを使用して連絡先 C を更新します。
work Email tom.selleck@sag.aftra.com tom@gmail.com tom.selleck@sag.aftra.com tom.selleck@sag.aftra.com

.csv の勤務先メールは連絡先 C の勤務先メールと一致します。

この連絡先はインポート後に更新され、連絡先 B は最初に一致した連絡先ではなく、連絡先 C が最初に一致した連絡先であったため、変更されません。

personal Email tommy@yahoo.com tom@yahoo.com インポート フィールドが選択されていないため、更新はありません。
その他メール 更新がなければ、連絡に価値はありません。
cell Phone +1 317 845-1232 +1 317 845-1232 インポート フィールドが選択されていないため、更新はありません。
work Phone +1 919 432-5523 +1 317 845-1232 +1 919 432-5523 競合があるため、連絡先 C は .csv のデータで更新されます。
自宅電話 更新がなければ、連絡に価値はありません。
その他電話 更新がなければ、連絡に価値はありません。

この例では、一部の連絡先が識別され、一部の連絡先がキュレーションされます。定義上、識別された連絡先はまだシステム内で識別子を要求していません。キュレーションされた連絡先は、作成時に識別子を要求しています。

連絡先には次の 3 つの種類があります。

  • はかない:クライアント側の Web 識別子または Cookie に関連付けられているが、その他の情報を持たない自動生成された連絡先。つまり、Web Cookie/クライアント側識別子が指す空の連絡先です。有効期間 (TTL) は 60 日間に制限されます。
  • 特定された:非 Cookie の PII を持ち、60 日間の TTL 制限がある自動生成された連絡先。
  • キュレーション:エージェントまたは API 呼び出しによって作成または_昇格_された連絡先。TTL制限はありません。


一時的な連絡先と識別された連絡先はシステムによって生成され、検索 API、逆ホワイトページ検索、またはスキャンには表示されません。

システム内で次の 2 つの連絡先が一致します。

  • 連絡先 B (キュレーション)
  • 連絡先C(特定済み)

一括インポート プロセス中に、インポート プロファイル画面で次のオプションが選択されました。

  • 連絡先の一致:外部 ID、電子メール アドレス、電話番号。
  • 一致した連絡先を統合する:一致したすべての連絡先を結合して更新します。

この例では、検索される識別子の順序は次のとおりです。

  1. ExternalID:123AABC
  2. email: johnny@gmail.com
  3. 電話番号: null

.csv ファイルの個人メール フィールドは連絡先 C の他のメール フィールドと一致し、CSV の勤務先電話番号は連絡先 B の携帯電話と一致します。

次の表では、

  • フィールド名列には、.csv ファイル内のフィールド名が示されます。
  • CSV データ (エンリッチ要求) 列には、.csv ファイルのデータが表示されます。
  • 連絡先 B 列は、Genesys Cloud でキュレーションされた連絡先です。
  • 連絡先 C 列は、Genesys Cloud で識別された連絡先です。
  • 連絡先 D 列は、インポート完了後に結合された連絡先です。
  • 説明列には、連絡先 D 列のデータがどのようにインポートされたかが説明されています。 
フィールド名 CSV データ (エンリッチ リクエスト) 連絡先B  連絡先C 連絡先D 説明
外部 ID 123AABC 123AABC .csv レコードの外部 ID は、マージされた連絡先 D レコードの主な識別子として強化されます。
Johnny Johnny 競合があるため、識別された連絡先の値が使用されます。
middleName マシュー M マシュー 矛盾があるため、最新のキュレーションされた連絡先が使用されます。
バンクスIV 銀行 バンクスIV バンクスIV 競合があるため、識別された連絡先の値が使用されます。
タイトル ジョニーボーイ .csv インポートでは null 値は使用されません。連絡先Cの値が使用されます。
salutation Mr .csv インポートでは null 値は使用されません。連絡先Bの値が使用されます。
work Email Banks@gmail.com Banks@gmail.com データの損失を避けるために、マージ中は電子メールは慎重に処理されます。したがって、.csv データの勤務先メールは null ですが、マージ後も連絡先 B の勤務先メールは保持され、マージされた連絡先 D の勤務先メールに配置されます。
personal Email johnny@gmail.com johnny@gmail.com .csv からの個人メールは連絡先 C の他のメールと一致します。

.csv の値は、結合された連絡先 D の個人メールに使用されます。
その他メール johnny@gmail.com johnny@gmail.com データの損失を避けるために、マージ中は電子メールは慎重に処理されます。したがって、.csv データの勤務先メールは null ですが、マージ後も連絡先 C のその他のメールは保持され、マージされた連絡先 D のその他のメールに配置されます。
cell Phone 更新がなければ、連絡に価値はありません。
work Phone 更新がなければ、連絡に価値はない
自宅電話 更新がなければ、連絡に価値はありません。
その他電話 更新がなければ、連絡に価値はない