Zendesk データインポーターにおけるユーザーの「レコードの作成および更新」の挙動を確かめてみた
はじめに
Zendesk のデータインポーターは、管理センターから CSV をアップロードするだけでユーザーを一括で作成・更新できる便利なツールです。管理センター → オブジェクトとルール → ツール → データインポーターにある GUI 機能で、投入後の反映は非同期的に行われます。
すでにユーザーが入っている環境へ投入する場合は、既存ユーザーとのマッチングや一意性チェックの仕組みを理解しておくと、安心して更新を進められます。データインポーターは実際に動かして確認できることが多く、本記事では実測で分かった挙動を紹介します。
対象読者
- Zendesk へ既存ユーザーを含むデータを一括インポートする担当者
- 別システムから Zendesk へ顧客データを移行・統合しようとしている方
- データインポーターの挙動を投入前に把握しておきたい方
参考
新規作成 or 更新の挙動について
はじめに押さえておきたいのが、既存ユーザーの識別に使うキーです。公式ドキュメントは、name・email・external_id で既存ユーザーを識別できると説明しています。ここに加えて、複数のキーがそれぞれ別の既存ユーザーを指すときにどれが優先されるかを、実際に投入して確かめました。
結果として、既存ユーザーとのマッチングは次のように評価されました。
まず、どの行にも email と name が必要です。email が空か不正な形式のとき、または name が空のときは、その行は作成も更新もされません。これは既存ユーザーを external_id で更新する行でも同じで、email を空にすると弾かれます。
そのうえで、対象を決めるキーは external_id と email です。external_id が既存ユーザーに一致すればそのユーザーが対象になり、一致しなければ email で探します。phone と name は対象を決めるキーには使われません。phone は一意性チェックだけに関わり、name はマッチングに関与しません。どのキーでも見つからなければ、新規ユーザーになります。
email で既存ユーザーが見つかった場合は、そのユーザーが更新されます。投入行に external_id があれば、既存ユーザーの external_id はその値で更新されます。既存の external_id が空でも、別の値が入っていても投入値で置き換わります。 name やカスタムフィールドも投入値で更新され、レコードが 1 つにまとまります。投入行に external_id が無い場合は、既存ユーザーの external_id はそのまま保たれます。空欄にした電話番号は上書きされず維持されました。
一意性チェックによるエラーについて
Zendesk では email も phone もアカウント全体で一意である必要があります。そのため、投入行の email や phone が、その行の対象とは別の既存ユーザーのものと重なると、その行はエラーになり、作成も更新もされません。これは既存ユーザーを更新する行でも、新規ユーザーを作成する行でも同じです。
たとえば、external_id で本人にマッチした行の email を、別のユーザーがすでに持っている email に変更しようとすると、次のようなエラーが表示されます。
Record validation errors. メール: user@example.com はすでに使われています.
電話番号でも同様です。一意性は、代表の電話番号 (プライマリ) だけでなく、副番号 (セカンダリ) として登録された番号にも及びます。既存ユーザーがある番号をセカンダリで持っている場合、その番号を含む別の行はエラーになります。
Record validation errors. 電話番号: +81-90-xxxx-xxxx はすでに別のユーザー (ユーザーB) が使用しています.
この一意性チェックは、同じ CSV の中の行にも働きます。同じ電話番号を複数の行に入れると、先頭の行はその番号で取り込まれますが、残りの行は同じ番号がすでに使われている状態になり、一意性のエラーになります。Zendesk では同じ電話番号を複数のユーザーに登録できないためです。同じ番号を持つ人が複数いる場合は、どれか 1 行にだけ電話番号を残し、ほかの行は電話番号を空欄にして取り込むと、エラーを避けられます。前の章のとおり、電話番号を空欄にした行は、既存ユーザーを更新する場合でもその電話番号を消しません。
無効なメールアドレスのエラーについて
新規作成では email が必須です。電話番号だけを入れて email 列を空にした行は、email が必要だと通知され、電話番号だけのユーザーは作成されません。
電話番号しか持たないレコードを投入したい場合は、仮のメールアドレスを生成して埋める方法があります。たとえば電話番号を使って、次のような形式のアドレスを emails 列に入れておきます。
phone-819012345678@example.invalid
仮アドレスなので Zendesk からの通知は届きませんが、name と電話番号は保持されるため、電話や SMS での連絡はそのまま機能します。
メールの形式チェックには、寛容な部分と厳格な部分があります。いくつかのパターンを実際に投入して確かめました。
まず、ローカル部 (@ より前) のドットの位置には寛容です。一般的な形式チェックでは弾かれることが多い、先頭・末尾・連続したドットも、そのまま受け付けられました。これらは携帯キャリアのメールに実在する形式です。
受け付けられた (ローカル部のドット位置)
.taro@example.com 先頭にドット
taro.@example.com @ の直前にドット
ta..ro@example.com 連続するドット
一方で、ドメイン部 (@ より後) やアドレス全体の構造には厳格でした。次の形式は、フォーマットエラーで弾かれました。
弾かれた
tarodomain.com @ がない
taro@ ドメインがない
@example.com ローカル部がない
taro@sub@example.com @ が 2 個
taro rou@example.com ローカル部に空白
taro@examplecom ドメインにドットがなくトップレベルドメインがない
taro@.example.com ドメインの先頭にドット
taro@ex..ample.com ドメインに連続ドット
taro@example.com. ドメインの末尾にドット
taro@example.c0m トップレベルドメインに数字が混じる
太郎@example.com ローカル部に日本語など非 ASCII 文字
まとめると、ローカル部のドットには寛容ですが、ドメイン部は正しく整っている必要があります。トップレベルドメイン (.com や .jp などドメイン末尾の部分) は英字のみで、アドレス全体は ASCII 文字である必要があります。投入前に自前でメールを厳しく検証しすぎると、本来 Zendesk では通るローカル部の形式まで除いてしまうことがあります。ドメインの妥当性は保ちつつ、ローカル部のドット位置は許容する、というデータインポーターの基準に合わせておくと、取りこぼしと投入エラーの両方を防げます。
まとめ
Zendesk のデータインポーターの「レコードの作成および更新」で一括処理するときは、マッチングと一意性の仕組みを理解しておくと、移行をスムーズに進められます。
- どの行にも email と name が必要で、既存ユーザーを external_id で更新する行でも email を空にすると弾かれる
- 更新対象は external_id、次に email で決まり、phone と name は対象決定に使われない
- email 一致のとき、投入行の external_id が既存ユーザーの external_id を 空でも別値でも更新 し、name・カスタムフィールドもまとまる
- email と電話番号は一意であることが必須で、電話の一意性は副番号にも適用
- email の形式チェックは、ローカル部のドット位置には寛容だが、ドメイン部と ASCII には厳格
データインポーターは実際に動かして確認できることが多いので、本番投入の前にサンドボックスで一度試しておくと安心です。
