ソース.csvファイルのデータを操作する
外部連絡先
外部IDはGenesys Cloudの必須キーフィールドです。インポートプロセス一意の連絡先を決定するために使用します。このフィールドは連絡先を識別するのに役立ち、同じスプレッドシートを介して既存の連絡先を簡単に更新できます。インポート プロセスでは、一意の外部 ID ごとに 1 つの Genesys Cloud 外部連絡先レコードが作成されます。インポート プロセスでは、行内のすべての連絡先フィールドが、対応する Genesys Cloud 外部連絡先レコードにインポートされます。
外部 ID を作成するときは、文字と数字の任意の組み合わせを使用できます。たとえば、CRM または ERP システムの一意の識別子を使用することも、自分にとって意味のある複合キーを作成することもできます。255 文字の制限を満たしていれば、レコードを識別するために使用する任意の外部 ID を使用できます。.csv が CRM から抽出される場合は、CRM の一意の識別子 (UUID) を使用することをお勧めします。UUID を使用すると、今後の機能更新で CRM から連絡先を同期できるようになります。
レコードを1回だけインポートする予定の場合は、必要な外部IDを使用できます。 システムは、これらの外部IDに対応するように内部IDを生成します。
- 以前に連絡先をインポートしたことがある場合は、古い一括インポート プロセスでは、システムは電話番号または電子メール アドレスの識別子のみを使用して、連絡先を新しい外部 ID と照合し更新します。古い連絡先に、新しい .csv ファイル内の電子メールまたは電話番号と一致する電子メールまたは電話番号がない場合、システムは .csv 内に指定された外部 ID を持つレコードを作成します。
- 連絡先の情報が同じファイル内で複数回繰り返されている場合、連絡先は複数回更新され、インポートされた行カウンタにその繰り返しが反映されます。ただし、更新が行われる順序は保証されません。
新しい一括インポート プロセスを使用して以前にインポートした連絡先を更新する場合は、重複レコードが作成されないように、同じ外部 ID を使用するようにしてください。
連絡先の情報がファイル内で複数回繰り返されている場合、連絡先は複数回更新され、インポート回数にその繰り返しが反映されます。ただし、更新が行われる順序は保証されません。
たとえば、外部 ID として「A」を使用してレコードを含むスプレッドシートをインポートし、後でそのレコードの外部 ID として「B」を使用して同じスプレッドシートを再インポートすると、Genesys Cloud は既存のレコードを更新する代わりにレコードを作成します。既存のレコードを更新するには、常に同じ外部 ID を使用します。
外部組織
T外部組織の外部IDはインポートプロセスで一意の組織を決定するために使用するキーフィールド。 インポート プロセスでは、一意の外部組織外部 ID ごとに 1 つの Genesys Cloud 外部組織レコードが作成されます。インポート プロセスでは、行内のすべてのアカウント フィールドが対応する Genesys Cloud 外部組織レコードにインポートされます。
外部組織の外部 ID を作成するときは、文字と数字の任意の組み合わせを使用できます。255 文字の制限を満たしていれば、自分にとって意味のある複合キーを作成できます。.csv が CRM から抽出される場合は、CRM の一意の識別子 (UUID) を使用することをお勧めします。UUID を使用すると、今後の機能更新で CRM から連絡先を同期できるようになります。
外部連絡先を外部組織と関連付ける
外部連絡先を外部組織に関連付けるには、.csv ソース ファイル内の同じ行に入力します。
この例では、Angus Reid は Phoenix Foundation II の問題解決者です。インポート プロセスにより、Phoenix Foundation II の外部組織レコードと Angus Reid の外部連絡先レコードが作成されます。「外部連絡先」では、アンガス・リードがフェニックス財団 II 組織の外部連絡先として登場します。
複数の外部を関連付ける との連絡 外部の 組織
複数の外部連絡先を1つの連絡先に関連付けるには外部の組織ごとに、同じ外部組織外部 ID を割り当てます。
この例では、Kathryn、Josh、およびRebeccaは、すべてOffice Mart組織の連絡先です。
- インポート プロセスで同じ外部組織外部 ID を持つ複数の行が検出されると、Genesys Cloud はすべてのフィールドでアカウント データが同じであると想定します。たとえば、外部組織の外部 ID が同じであるすべての行では、アカウント名が同一である必要があります。複数の行に同じ外部組織外部 ID がある場合、インポート プロセスではアカウント データの行のうち 1 つだけがインポートされます。Genesysは、プロセスがインポートするアカウントデータの行を保証しません。アカウントの行セットの最初または最後の行である必要はありません。したがって、アカウント データのすべての行は同一である必要があります。
- .csvファイルを使用して、手動で作成した組織にメンバーをインポートすることはできません。
一括インポートプロセスがマージアクションを管理する方法
この例では、連絡先のみをインポートし、.csv ファイル内のすべての外部連絡先組織フィールドが空であると想定します。
一括インポート プロセス中に、インポート プロファイル画面で次のオプションが選択されました。
- 連絡先の一致:外部ID、電話番号、メールアドレス
- 一致した連絡先を統合する:一致するすべての連絡先を結合して更新する
この例では、検索される識別子の順序は次のとおりです。
- ExternalID:123AABC
- 電話: +1 919 432 5523
- 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 の前に来ます)
- ExternalID:123AABC
- email: tom.selleck@sag.aftra.com
- 電話: +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、電子メール アドレス、電話番号。
- 一致した連絡先を統合する:一致したすべての連絡先を結合して更新します。
この例では、検索される識別子の順序は次のとおりです。
- ExternalID:123AABC
- email: johnny@gmail.com
- 電話番号: 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 | 更新がなければ、連絡に価値はない | ||||
| 自宅電話 | 更新がなければ、連絡に価値はありません。 | ||||
| その他電話 | 更新がなければ、連絡に価値はない |
外部連絡先（古いインポート プロセス）
連絡先IDは必須のキーフィールドです。 Genesys Cloudインポートプロセスは、それを使用して固有の連絡先を決定します。 同じスプレッドシートを使用して既存の連絡先を簡単に更新できるように、連絡先を特定するのに役立ちます。 一意のContact IDごとに、インポート プロセスによって1つのPureCloud 外部連絡先のレコードが作成されます。 インポートプロセスは、行のすべての連絡先フィールドを対応するGenesys Cloud外部連絡先レコードにインポートします。
連絡先IDを作成するときは、文字と数字の任意の組み合わせを使用できます。 たとえば、CRMまたはERPシステムの一意の識別子を使用できます。ou can 作成する あなたにとって意味のある複合キー。 レコードを一意に識別するために使用する任意のIDにすることができます。
レコードを1回だけインポートする予定の場合は、必要な外部IDを使用できます。 システムは、これらの外部IDに対応するように内部IDを生成します。
以前に連絡先をインポートしており、レコードを更新する場合は、既存の連絡先に同じ連絡先IDを使用していることを確認してください。 そうしないと、Genesys Cloudは既存のレコードを更新する代わりに新しいレコードを作成します。
たとえば、1つのレコードを含むスプレッドシートがあり、連絡先IDとしてAでインポートするとします。 後で、同じスプレッドシートを再インポートしてそのレコードを更新します。 そのレコードの連絡先IDは、以前のインポートと同じでなければなりません。 代わりに、そのレコードの連絡先IDとしてBを使用してスプレッドシートを再インポートした場合、Genesys Cloudは既存のレコードを更新する代わりに新しいレコードを作成します。
外部組織
Account ID はインポートプロセスが一意の組織を決定するために使用するキーフィールドです。 一意のAccount IDごとに、インポートプロセスによって1つのPureCloud 外部組織のレコードが作成されます。 インポートプロセスでは、行内のすべてのアカウントフィールドが対応するGenesys Cloud外部組織レコードにインポートされます。
アカウントIDを作成するときは、文字と数字の任意の組み合わせを使用できます。 意味のある複合キーを作成することができます。
外部連絡先を外部組織と関連付ける
外部連絡先を外部組織に関連付けるには、.csvソースファイルの同じ回線それらを入力します。
この例では、Kathryn SmithがOffice Martのバイヤーです。 インポートプロセスでは、Office Martの外部組織のレコードとKathryn Smithの外部連絡先のレコードが作成されます。 外部連絡先では、Kathryn SmithはOffice Mart組織の外部連絡先として表示されます。
複数の外部を関連付ける との連絡 外部の 組織
1つの外部組織と複数の外部連絡先を関連付けるには、すべてに同じAccount IDを割り当てます。
この例では、Kathryn、Josh、およびRebeccaは、すべてOffice Mart組織の連絡先です。
- インポートプロセスで、同じアカウントIDを持つ複数の行に遭遇した場合、Genesys Cloudは、アカウントデータがすべてのフィールドで同じであると想定します。 たとえば、アカウント名は、同じアカウントIDを持つすべての行で同一である必要があります。 インポートプロセスは、複数の行に同じアカウントIDがある場合、アカウントデータの行の1つのみをインポートします。 Genesysは、プロセスがインポートするアカウントデータの行を保証しません。 アカウントの行セットの最初または最後の行である必要はありません。 したがって、アカウントデータのすべての行は同一である必要があります。
- .csvファイルを使用して、手動で作成した組織にメンバーをインポートすることはできません。
