Tính năng đồng bộ danh bạ của Google Workspace sao chép danh bạ giữa Google Contacts và CRM theo lịch trình. Các bản sao thường xuất hiện khi hai hệ thống không thể xác định cùng một người bằng khóa đối sánh đã cấu hình. Dữ liệu cũng có thể bị mất khi quy tắc xung đột ghi đè lên giá trị mới hơn hoặc thao tác xóa lan truyền giữa các hệ thống. Google Contacts có thể hoàn tác các thay đổi trong vòng 30 ngày qua, do đó đây là khoảng thời gian phục hồi thực tế.
Việc đồng bộ danh bạ hiếm khi gây ra mất dữ liệu ngẫu nhiên. Hầu hết các vấn đề phát sinh từ ba điểm có thể dự đoán được trong quá trình này: cách các bản ghi được đối khớp, cách giải quyết các chỉnh sửa xung đột và liệu việc xóa có được phép lan truyền hay không.
Nhiều nhóm coi việc đồng bộ hóa là một tác vụ thiết lập đơn giản. Kết nối Google Workspace, chọn các trường liên hệ, chọn hướng đồng bộ và bật nó lên. Vấn đề thường xuất hiện sau đó, khi ai đó phát hiện ra rằng danh sách liên hệ bị trùng lặp hoặc số điện thoại đã được sửa trong CRM lại bị thay thế bằng giá trị cũ hơn từ Google Contacts.
Những kết quả đó không nhất thiết là lỗi phần mềm. Chúng thường xuất phát trực tiếp từ cách cấu hình các quy tắc đồng bộ hóa. Cách tiếp cận an toàn hơn là hiểu rõ hoạt động của trình kết nối trong mỗi chu kỳ đồng bộ hóa, xác định hệ thống nào nên kiểm soát các trường quan trọng và tạo điểm khôi phục trước khi thực hiện đồng bộ hóa hàng loạt đầu tiên.
Cách thức hoạt động của tính năng đồng bộ danh bạ
Tính năng đồng bộ danh bạ của Google Workspace so sánh và cập nhật hồ sơ giữa hai hệ thống riêng biệt. Thông thường, quá trình này được lên lịch chứ không phải tức thời, vì vậy mỗi chu kỳ sẽ kiểm tra những thay đổi kể từ lần chạy trước và sau đó áp dụng các quy tắc đã được cấu hình.
Chu trình đồng bộ hóa bao gồm năm bước:
- Bộ kết nối kiểm tra các thay đổi – Nó xác định các liên hệ được tạo, chỉnh sửa hoặc xóa kể từ chu kỳ trước. Tùy thuộc vào trình kết nối, các kiểm tra này có thể diễn ra vài phút một lần thay vì ngay lập tức.
- Nó khớp với các bản ghi – Với mỗi thông tin liên hệ được thay đổi, trình kết nối sẽ tìm kiếm bản ghi tương ứng trong hệ thống kia. Trường được sử dụng cho việc so sánh này là khóa khớp, và địa chỉ email là một lựa chọn phổ biến.
- Nó lập bản đồ các cánh đồng – Bộ kết nối xác định các trường nào tương ứng giữa hai hệ thống. Tên, email, số điện thoại, công ty và chức danh công việc có thể có các trường tương đương trực tiếp. Các trường không có đích đến được ánh xạ sẽ không được chuyển giao.
- Nó giải quyết các xung đột – Nếu cùng một thông tin liên hệ được thay đổi trong cả hai hệ thống trước lần đồng bộ tiếp theo, một quy tắc xung đột sẽ xác định giá trị nào được giữ lại.
- Nó ghi lại những thay đổi – Bộ kết nối sẽ áp dụng các thay đổi thu được theo hướng đồng bộ hóa và quyền hạn đã chọn.
Điểm quan trọng là Việc đối sánh và giải quyết xung đột là hai vấn đề riêng biệt.Việc đối sánh xác định xem trình kết nối có cho rằng hai bản ghi thuộc cùng một người hay không. Giải quyết xung đột xác định giá trị nào được giữ lại khi nó biết rằng chúng thuộc cùng một người.
| Lưu ý quan trọng: Sao chép dữ liệu giữa hai hệ thống, mỗi hệ thống duy trì hồ sơ riêng của mình. Điều đó khác với việc đồng bộ hóa. Tích hợp Google Workspace CRM Được xây dựng dựa trên hồ sơ khách hàng chung. Nếu bạn vẫn đang lựa chọn phần mềm CRM, sự khác biệt này rất quan trọng vì hồ sơ chung giúp giảm lượng dữ liệu liên hệ cần được đối chiếu giữa các hệ thống riêng biệt. |
Những gì được chuyển giao?
Việc đồng bộ danh bạ không nhất thiết phải chuyển tất cả các trường thông tin từ hệ thống này sang hệ thống khác.
| Loại dữ liệu | Google Contacts | CRM | Kết quả đồng bộ điển hình |
| Họ tên | Có | Có | Thường được lập bản đồ |
| Có | Có | Thường được lập bản đồ và sử dụng để đối sánh. | |
| Điện thoại | Có | Có | Thường được lập bản đồ |
| Tên Công Ty | Có | Có | Thường được lập bản đồ |
| Chức vụ | Có | Có | Thường được lập bản đồ |
| Nhãn | Có | Khác nhau | Không được phép chuyển nhượng |
| Nguôn dân | Không | Có | Thường vẫn nằm trong CRM |
| Lịch sử giao dịch | Không | Có | Vẫn còn trong CRM |
| Các trường CRM tùy chỉnh | Không | Có | Thường vẫn nằm trong CRM |
Một trường chưa được ánh xạ không nhất thiết phải bị xóa. Đơn giản là nó không có đích đến trong hệ thống kia. Rủi ro phát sinh khi các nhóm cho rằng một trường tồn tại ở cả hai phía và sau đó phát hiện ra rằng nó chưa bao giờ được đưa vào quá trình ánh xạ.
Đồng bộ một chiều so với đồng bộ hai chiều
Hướng đồng bộ hóa xác định hệ thống nào được phép thay đổi hệ thống kia. Quyết định đó nên được đưa ra trước khi bạn lo lắng về việc ánh xạ từng trường riêng lẻ, bởi vì nó quyết định liệu các chỉnh sửa xung đột có thể xảy ra hay không.
| Tiêu chí | Đồng bộ một chiều | Đồng bộ hai chiều |
| Hướng thay đổi | Từ điểm xuất phát đến điểm đến | Cả hai hệ thống |
| Xung đột | Không có sự khác biệt giữa hai hệ thống. | Có thể |
| Bản ghi trùng lặp | Vẫn có thể | Có thể |
| Chỉnh sửa điểm đến | Có thể bị ghi đè | Có thể lây lan trở lại |
| Thiết lập độ phức tạp | Hạ | Cao hơn |
| Phù hợp nhất với | Một hệ thống đóng vai trò là hệ thống chính. | Các nhóm đang tích cực sử dụng cả hai hệ thống. |
Việc đồng bộ một chiều an toàn hơn khi một hệ thống rõ ràng là nguồn thông tin chính xác.
Ví dụ, nếu Google Contacts chỉ được sử dụng để điền dữ liệu vào CRM, thì hầu như không có lý do gì để cho phép các chỉnh sửa từ CRM được chuyển ngược lại vào Google.
Việc đồng bộ hai chiều chỉ có ý nghĩa khi nhân viên thực sự cập nhật thông tin liên lạc trong cả hai hệ thống.
Nó cũng đưa ra một yêu cầu mới: bạn cần các quy tắc để quyết định điều gì sẽ xảy ra khi cả hai hệ thống đều chứa các phiên bản khác nhau của cùng một liên hệ.
Điểm khác biệt chính rất đơn giản: đồng bộ một chiều giảm nguy cơ xung đột, nhưng không loại bỏ nguy cơ trùng lặp. Một bản ghi vẫn có thể bị trùng lặp nếu trình kết nối không khớp nó với một liên hệ hiện có.
Vì sao đồng bộ hóa tạo ra các bản sao và mất dữ liệu?
Hầu hết các vấn đề đồng bộ danh bạ đều xuất phát từ ba cơ chế: lỗi khớp bản ghi, chỉnh sửa xung đột và lan truyền xóa. Mỗi trường hợp đòi hỏi một cách khắc phục khác nhau, đó là lý do tại sao việc chỉ đơn giản là hợp nhất các bản ghi trùng lặp sau mỗi lần đồng bộ không giải quyết được vấn đề gốc rễ.
Chìa khóa trận đấu
Khóa khớp là trường mà trình kết nối sử dụng để quyết định xem hai bản ghi có đại diện cho cùng một người hay không.
Địa chỉ email được sử dụng phổ biến vì nó tương đối độc đáo. Vấn đề là nó không phải lúc nào cũng có sẵn hoặc không nhất quán.
Tại sao trận đấu lại thất bại?
Hãy xem xét một liên hệ tồn tại trong cả hai hệ thống:
- Danh bạ Google: [email được bảo vệ]
- CRM: [email được bảo vệ]
Một người có thể nhận ra ngay rằng cả hai bản ghi đều có thể thuộc về John Smith. Một trình kết nối sử dụng phương pháp đối khớp email chính xác không thể đưa ra giả định đó. Nó thấy hai giá trị khác nhau và có thể tạo ra bản ghi thứ hai.
Vấn đề tương tự cũng xảy ra khi:
- Một bản ghi không có địa chỉ email.
- Một hệ thống sử dụng email công việc, hệ thống khác sử dụng email cá nhân.
- Số điện thoại sử dụng các định dạng khác nhau.
- Bộ kết nối khớp với một trường mà người dùng thường xuyên chỉnh sửa.
- Các bản ghi trùng lặp đã tồn tại trước khi tính năng đồng bộ hóa được bật.
Định dạng số điện thoại có thể tạo ra kết quả đặc biệt khó hiểu. Ví dụ, +44 20 7946 0958 và 02079460958 có thể đại diện cho cùng một số nhưng sẽ không khớp nếu trình kết nối so sánh chính xác các chuỗi được lưu trữ.
Hãy sửa khóa trước khi hợp nhất.
Việc hợp nhất các mục trùng lặp chỉ hữu ích sau khi bạn đã khắc phục được vấn đề trùng khớp.
Nếu khóa khớp vẫn không nhất quán, lần đồng bộ tiếp theo có thể tạo lại các bản ghi trùng lặp mà bạn vừa xóa. Trình tự chính xác là:
Xác định lý do khớp không thành công → chuẩn hóa trường dữ liệu → hợp nhất các bản sao hiện có → chạy đồng bộ hóa có kiểm soát.
Đối với các cơ sở dữ liệu lớn hơn, cũng nên kiểm tra xem có bao nhiêu bản ghi thiếu khóa khớp đã chọn trước khi bật tính năng đồng bộ hai chiều.
Giải quyết xung đột
Xung đột xảy ra khi trình kết nối nhận diện hai bản ghi là cùng một liên hệ nhưng lại tìm thấy các giá trị khác nhau vì cả hai hệ thống đều đã được chỉnh sửa trước lần đồng bộ tiếp theo.
Các cách tiếp cận phổ biến bao gồm:
| Quy tắc xung đột | Điều gì xảy ra | rủi ro chính |
| Bài viết cuối cùng sẽ thắng | Phiên bản chỉnh sửa gần nhất được giữ nguyên. | Một bản sửa lỗi hữu ích trước đó có thể bị ghi đè. |
| Hệ thống ghi chép | Một hệ thống kiểm soát lĩnh vực này. | Những thay đổi trong hệ thống khác có thể không được giữ lại. |
| Quy tắc cấp trường | Các lĩnh vực khác nhau tuân theo các quy tắc khác nhau. | Cần nhiều công đoạn thiết lập và bảo trì hơn. |
Nguyên tắc "người chỉnh sửa cuối cùng sẽ được ưu tiên" rất tiện lợi nhưng có thể gây ra những thay đổi ngầm. Nếu ai đó sửa số điện thoại trong CRM lúc 9:00 và một nhân viên khác chỉnh sửa cùng một liên hệ đó trên Google lúc 10:00 bằng số điện thoại cũ hơn, thì lần chỉnh sửa sau có thể thay thế lần chỉnh sửa trước.
Đối với các lĩnh vực ảnh hưởng đến bán hàng hoặc dịch vụ khách hàng, hãy cân nhắc chỉ định một hệ thống ghi nhận dữ liệu riêng. Cấu trúc cơ sở dữ liệu CRM Có thể chứa thông tin không nên bị ghi đè bởi thao tác chỉnh sửa sổ địa chỉ.
Sự lan truyền của việc xóa
Việc xóa cần được xem xét riêng vì nó có thể xóa thông tin không hiển thị trong chính thông tin liên hệ đó.
Trong cấu hình hai chiều, việc xóa một liên hệ trong Google có thể vô tình xóa luôn bản ghi tương ứng trong CRM. Nếu bản ghi CRM đó chứa ghi chú, hoạt động, thông tin giao dịch hoặc liên kết đến hồ sơ khách hàng, thì tác động sẽ lớn hơn nhiều so với việc chỉ mất tên và số điện thoại.
| Hoạt động | Kết quả tiềm năng |
| Chỉnh sửa liên hệ | Một hệ thống khác nhận được giá trị mới. |
| Tạo ra liên lạc | Một hệ thống khác tạo ra bản ghi tương ứng. |
| Hợp nhất địa chỉ liên lạc | Một bản ghi có thể bị xóa hoặc thay đổi. |
| Xóa liên lạc | Việc xóa có thể lan truyền |
| Đổi cả hai phía | Quy tắc xung đột xác định giá trị còn lại |
Nếu trình kết nối của bạn cho phép tắt tính năng lan truyền xóa, hãy cân nhắc tắt tính năng này trừ khi quy trình làm việc của bạn yêu cầu cụ thể.
Thiết lập đồng bộ hóa an toàn
Các biện pháp kiểm soát hiệu quả nhất là những biện pháp được áp dụng trước lần đồng bộ đầu tiên. Khi hàng nghìn liên hệ đã bị trùng lặp hoặc ghi đè, việc dọn dẹp sẽ trở nên khó khăn hơn đáng kể vì bạn phải phân biệt dữ liệu gốc với những thay đổi do quá trình đồng bộ tạo ra.
Hoàn thành các bước kiểm tra này trước chu kỳ đầu tiên.
- Xuất cả hai hệ thống: Hãy lưu bản xuất CSV của Danh bạ Google và CRM ở cả hai hệ thống riêng biệt. Điều này sẽ cung cấp cho bạn điểm khôi phục nếu lần đồng bộ đầu tiên gặp sự cố.
- Xóa các mục trùng lặp hiện có: Việc đồng bộ hóa cơ sở dữ liệu đã chứa các bản ghi trùng lặp sẽ làm cho việc đối khớp trở nên khó khăn hơn và có thể làm trầm trọng thêm vấn đề.
- Kiểm tra phạm vi phủ sóng của các thông tin quan trọng trong trận đấu: Hãy tìm hiểu xem có bao nhiêu liên hệ thiếu thông tin mà bạn dự định sử dụng để đối khớp, đặc biệt là địa chỉ email.
- Chuẩn hóa số điện thoại: Hãy sử dụng một định dạng duy nhất cho cả hai hệ thống để sự khác biệt về định dạng không cản trở việc đối khớp.
- Bắt đầu với đồng bộ một chiều: Trước tiên hãy điền dữ liệu vào CRM và kiểm tra kết quả trước khi cho phép thay đổi được thực hiện theo cả hai chiều.
- Vô hiệu hóa tính năng lan truyền xóa: Ngăn chặn việc tự động di chuyển các thao tác xóa giữa các hệ thống trừ khi có lý do vận hành rõ ràng để cho phép điều đó.
- Thử nghiệm với một nhóm nhỏ: Hãy bắt đầu với 20 liên hệ thay vì toàn bộ cơ sở dữ liệu của bạn. Một nhóm thử nghiệm là đủ để phát hiện ra các lỗi trong việc ánh xạ trường và quy tắc đối sánh.
Kiểm tra kết quả sau chu kỳ đầu tiên.
Đừng ngừng kiểm tra khi báo cáo đồng bộ hóa đầu tiên cho biết "hoàn tất". Một số trình kết nối thực hiện thêm các chu kỳ đối chiếu sau khi chuyển dữ liệu ban đầu. Cơ sở dữ liệu trông có vẻ chính xác ngay sau lần chạy đầu tiên có thể thay đổi một lần nữa khi chu kỳ xử lý bản ghi tiếp theo theo lịch trình.
Một phương pháp xét nghiệm an toàn hơn là:
Chu kỳ đầu tiên → kiểm tra bản ghi → chờ chu kỳ tiếp theo → kiểm tra lại → mở rộng nhóm đồng bộ.
| Đừng bỏ qua điều này: Nếu nhóm thử nghiệm tạo ra các bản ghi trùng lặp, hãy dừng đồng bộ hóa trước khi mở rộng nhóm. Việc sửa lỗi khóa khớp và ánh xạ trường ở giai đoạn này dễ dàng hơn nhiều so với việc khắc phục cùng một vấn đề trên hàng nghìn bản ghi. |
Khắc phục sự cố đồng bộ hóa
Nếu quá trình đồng bộ đã ghi đè hoặc xóa danh bạ, hãy dừng đồng bộ trước khi cố gắng dọn dẹp. Nếu không, trình kết nối có thể tiếp tục áp dụng cùng một quy tắc trong khi bạn đang cố gắng đảo ngược tác động của nó.
Quá trình phục hồi nên tuân theo trình tự sau:
- Tắt tính năng đồng bộ.
- Xuất trạng thái hiện tại của cả hai hệ thống.
- Xác định thời điểm những thay đổi không mong muốn bắt đầu.
- Hãy sử dụng lịch sử khôi phục hoặc bản sao lưu hiện có.
- Sửa chữa các bản ghi trùng lặp và không chính xác.
- Sửa cấu hình đồng bộ.
- Hãy chạy thêm một bài kiểm tra nhỏ nữa trước khi kết nối lại toàn bộ cơ sở dữ liệu.
Những gì Google có thể khôi phục
Google Contacts cung cấp một Hoàn tác thay đổi Tùy chọn này cho phép khôi phục danh bạ về trạng thái trước đó trong vòng 30 ngày. Google cho biết việc khôi phục có thể đưa danh bạ trở lại trạng thái tại một thời điểm được chọn trong khoảng thời gian đó.
Khoảng thời gian 30 ngày đó rất quan trọng vì nó giới hạn thời gian bạn có để đảo ngược những thay đổi lớn về danh bạ từ phía Google. Trước khi khôi phục, hãy xuất danh bạ hiện tại của bạn vì những danh bạ được thêm vào sau điểm khôi phục đã chọn có thể bị xóa khi bạn khôi phục trạng thái cũ hơn.
Google cũng lưu ý rằng các liên hệ đã bị xóa vĩnh viễn khỏi Thùng rác không thể được khôi phục thông qua quy trình khôi phục này.
Những điều không được quy định trong khung thời gian 30 ngày
Cửa sổ khôi phục của Google chỉ áp dụng cho Danh bạ Google. Nó không tự động khôi phục dữ liệu đã bị ghi đè hoặc xóa trong CRM của bạn.
Ví dụ, nếu quá trình đồng bộ hóa thay đổi số điện thoại trong CRM và CRM không có lịch sử phiên bản cho trường đó, chức năng hoàn tác của Google không nhất thiết khôi phục lại giá trị trong CRM.
Điều tương tự cũng áp dụng cho thông tin được đính kèm vào bản ghi CRM. Tên và email của một liên hệ có thể dễ dàng khôi phục từ bản xuất dữ liệu, nhưng các ghi chú, hoạt động, cơ hội và tương tác khách hàng liên quan có thể không thể khôi phục được trừ khi CRM lưu giữ chúng riêng biệt.
| Nguồn phục hồi | Nó có thể giúp phục hồi những gì | Giới hạn |
| Hoàn tác trong Danh bạ Google | Trước đó, Google đã liên hệ với tiểu bang của bạn. | Giới hạn trong 30 ngày |
| Thùng rác Danh bạ Google | Danh bạ đã xóa gần đây | Thùng rác đã bị xóa vĩnh viễn không thể khôi phục lại. |
| Thùng rác CRM | Các bản ghi CRM đã bị xóa | Tỷ lệ giữ chân khách hàng khác nhau tùy thuộc vào hệ thống CRM. |
| Kiểm toán/lịch sử CRM | Giá trị trường trước đó | Tùy thuộc vào hệ thống CRM và tính năng theo dõi được bật. |
| Xuất CSV | Ảnh chụp nhanh thông tin liên hệ | Chỉ chứa những gì đã được xuất khẩu |
| Nếu mọi việc đã trở nên tồi tệ: Hãy tắt tính năng đồng bộ hóa trước khi hợp nhất các bản ghi trùng lặp hoặc khôi phục bản ghi. Sau đó, xuất trạng thái hiện tại, xác định thời điểm sự cố bắt đầu, sửa chữa dữ liệu, điều chỉnh các quy tắc đồng bộ hóa và chỉ kết nối lại sau khi đã thực hiện kiểm tra có kiểm soát. Nếu không, cấu hình lỗi tương tự có thể tái tạo lại sự cố trong khi bạn đang khắc phục nó. |
Đồng bộ danh bạ với Vtiger One
Vtiger One kết nối dữ liệu Google Workspace với hồ sơ CRM để các nhóm có thể làm việc với danh bạ, email, lịch, tệp và cuộc họp mà không cần duy trì các hồ sơ khách hàng hoàn toàn riêng biệt.
Điểm khác biệt quan trọng nằm ở chỗ điều gì xảy ra sau khi thông tin liên hệ được lưu trữ trong CRM. Một thông tin liên hệ trong CRM có thể được liên kết với các cơ hội bán hàng, các trường hợp hỗ trợ, các hoạt động, ghi chú và các tương tác với khách hàng. Ngữ cảnh đó không tương đương với thông tin liên hệ cơ bản được lưu trữ trong sổ địa chỉ.
Đây là lý do tại sao việc đồng bộ danh bạ cần được xem như một quy trình quản lý dữ liệu chứ không chỉ đơn thuần là kết nối giữa hai ứng dụng.
quản trị quan hệ khách hàng Thông tin liên hệ trên Google vẫn sẽ hữu ích ngay cả khi chỉ chứa tên, số điện thoại và địa chỉ email. quy trình quản lý khách hàng tiềm năng Bổ sung ngữ cảnh bán hàng mà sổ địa chỉ không có.
Số lượng bản sao cần đối chiếu ít hơn
Càng nhiều hệ thống lưu trữ bản sao thông tin khách hàng riêng của chúng, thì bạn càng phải duy trì nhiều quy tắc đối sánh và xử lý xung đột hơn.
An nền tảng CRM tất cả trong một Có thể giảm thiểu sự trùng lặp đó bằng cách giữ cho các nhóm bán hàng, tiếp thị và hỗ trợ sử dụng cùng một hồ sơ khách hàng. Google Workspace sau đó có thể đóng vai trò là lớp năng suất trong khi CRM vẫn là hệ thống lưu trữ lịch sử khách hàng và hoạt động kinh doanh.
Kiểm tra thiết lập thực tế
Nếu bạn đang cấu hình Google Workspace với Vtiger, hãy xem lại các mục này trước khi bật tính năng đồng bộ hóa hàng loạt:
- Phê duyệt Đồng bộ ứng dụng Google Tùy chọn và chỉ kích hoạt các dịch vụ mà nhóm của bạn thực sự sử dụng.
- Xác nhận Tích hợp Google CRM hướng trước lần đồng bộ đầu tiên.
- Rắc bột Kiểm soát bảo mật CRM Dành cho những người dùng có thể quản lý hoặc kích hoạt các tích hợp.
- Hãy coi việc nhập khẩu số lượng lớn lần đầu tiên như một... lập kế hoạch chuyển đổi CRM Tập luyện thay vì thay đổi thói quen thường ngày.
- Nếu Gmail đóng vai trò trung tâm trong quy trình làm việc của nhóm, hãy đánh giá xem liệu... CRM được xây dựng dành cho Google Giảm số lượng hệ thống riêng biệt mà nhân viên cần cập nhật.
Mục tiêu không phải là loại bỏ mọi sự tích hợp. Mục tiêu là làm rõ hệ thống nào sở hữu từng phần thông tin khách hàng, trường thông tin nào có thể được chuyển giữa các hệ thống và điều gì xảy ra khi hai người dùng cùng chỉnh sửa một bản ghi.
FCác câu hỏi cần thiết
Tại sao hệ thống CRM của tôi liên tục tạo ra các liên hệ trùng lặp?
Vì quá trình đồng bộ không thể khớp bản ghi mới với thông tin liên hệ hiện có. Việc khớp thường sử dụng địa chỉ email, do đó, các liên hệ không có email, các liên hệ có email khác nhau trong mỗi hệ thống hoặc các liên hệ có định dạng không nhất quán có thể được coi là bản ghi mới.
Liệu đồng bộ một chiều có ngăn chặn việc trùng lặp dữ liệu không?
Không. Đồng bộ một chiều ngăn ngừa xung đột do cả hai hệ thống cùng chỉnh sửa một bản ghi, nhưng nó không ngăn ngừa việc khớp không thành công. Nếu trình kết nối không thể xác định được liên hệ hiện có, nó vẫn có thể tạo bản sao trong hệ thống đích.
Hệ thống nào sẽ thắng thế khi thông tin liên lạc thay đổi ở cả hai hệ thống?
Kết quả phụ thuộc vào quy tắc xung đột được cấu hình cho trình kết nối. Một quy tắc mặc định phổ biến là "ghi mới nhất sẽ thắng", trong đó bản chỉnh sửa gần nhất sẽ thay thế giá trị trước đó. Nếu một trường cụ thể phải được kiểm soát bởi một hệ thống duy nhất, hãy cấu hình hệ thống đó làm nguồn dữ liệu chính xác cho trường đó nếu trình kết nối hỗ trợ.
Tôi có thể khôi phục danh bạ sau khi đồng bộ hóa không thành công không?
Google Contacts cho phép hoàn tác các thay đổi được thực hiện trong vòng 30 ngày trước đó. Các liên hệ đã bị xóa vĩnh viễn khỏi Thùng rác không thể khôi phục bằng chức năng hoàn tác của Google. Khả năng khôi phục dữ liệu bị ghi đè hoặc bị xóa trong CRM phụ thuộc vào thùng rác, lịch sử kiểm toán, lịch sử phiên bản hoặc các bản sao lưu có sẵn của CRM đó.
Tôi có nên tắt tính năng đồng bộ hóa xóa không?
Đối với hầu hết các nhóm, việc tắt tính năng lan truyền thông tin xóa là lựa chọn an toàn hơn trừ khi quy trình làm việc yêu cầu cụ thể điều đó. Nếu không, thao tác xóa có thể được chuyển từ Google sang CRM và xóa bản ghi, đồng thời có thể xóa cả lịch sử giao dịch liên quan.
Tôi cần chuẩn bị những gì trước khi bật tính năng đồng bộ danh bạ?
Xuất dữ liệu từ cả hai hệ thống, xóa các bản sao hiện có, kiểm tra phạm vi bao phủ của khóa đối sánh, chuẩn hóa định dạng số điện thoại, bắt đầu với đồng bộ một chiều, tắt tính năng lan truyền dữ liệu khi xóa và kiểm tra chu kỳ đầu tiên với một nhóm nhỏ trước khi đồng bộ toàn bộ cơ sở dữ liệu.
Tại sao lại xuất hiện các bản ghi trùng lặp sau khi quá trình đồng bộ ban đầu có vẻ diễn ra chính xác?
Một số trình kết nối thực hiện đối chiếu trong các chu kỳ đã lên lịch sau đó. Do đó, lần chạy đầu tiên có thể có vẻ thành công trước khi chu kỳ tiếp theo xử lý thêm các bản ghi. Hãy kiểm tra lại nhóm đồng bộ hóa sau một chu kỳ đã lên lịch khác trước khi mở rộng nó.
Khóa khớp trong tính năng đồng bộ danh bạ là gì?
Khóa đối sánh là trường mà trình kết nối sử dụng để quyết định xem một bản ghi trong hệ thống này có đại diện cho cùng một người với một bản ghi trong hệ thống khác hay không. Địa chỉ email thường được sử dụng. Nếu trường này bị thiếu hoặc không nhất quán, trình kết nối có thể tạo một liên hệ mới thay vì cập nhật liên hệ hiện có.
