本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Kustomer 限制
<a name="kustomer-connection-limitations"></a>

以下是 Kustomer 的限制或備註：
+ 不支援 `Customer Searches` 實體，因為 Kustomer API 文件尚未為其宣告任何端點。
+ 不支援對 `Klasses` 實體進行篩選和增量傳輸。
+ 單一請求中的多個適用欄位可支援排序依據。

  不過，對於某些組合，已觀察到 SaaS 終端的多個欄位的排序依據功能行為不一致。其無法預測，因為有可能顯示不正確排序結果的 'n' 個組合。例如：

  對於 `Customers` 實體，按 `progressiveStatus desc, name asc` 排序不會產生正確的排序結果。其只會根據 `progressiveStatus` 順序排序。如果發現此類行為，可以使用單一欄位進行排序。
+ `Conversations` 和 `Messages` 實體僅支援欄位 'id' 的排序依據作為查詢參數。例如：https://api.kustomerapp.com/v1/conversations?sort=desc (這會以遞減順序按照 'id' 對結果進行排序。)

  此外，任何其他欄位上的篩選條件或排序會轉換為將 API 端點作為 POST 的 POST 請求內文 https://api.kustomerapp.com/v1/customers/search 若要允許在 `Conversations` 和 `Messages` 中依 'id' 排序，應該只存在依 id 排序，或在任何其他適用欄位存在任何其他篩選條件和/或排序依據。
+ 無論是已篩選還是未篩選的請求，Kustomer 允許擷取最多 10K 筆記錄。由於此限制，持有超過 10K 筆記錄的任何實體都會遺失資料。可以執行兩種可能的解決方法，以部分緩解此問題：
  + 套用篩選條件來擷取一組特定記錄。
  + 如果已套用的篩選條件具有超過 10K 筆記錄，請在新的後續請求中套用連續篩選條件值，或在篩選條件中套用範圍。例如：

    第一個請求的 filterExpression：`modifiedAt >= 2022-03-15T05:26:23.000Z and modifiedAt < 2023-03-15T05:26:23.000Z`

    假設這會耗盡 10K 筆記錄限制。

    可以使用 filterExpression 觸發另一個請求：`modifiedAt >= 2023-03-15T05:26:23.000Z`
+ 作為 SaaS 行為，Kustomer 中的 `CONTAINS` 運算子僅支援對完整字詞進行比對，而不是對字詞進行部分比對。例如："body CONTAINS 'test record'" 將比對 'body' 欄位中具有 'test' 的記錄。不過，"body CONTAINS 'test'" 不會比對 'body' 欄位中具有 'testAnotherRecord' 的記錄。