Hi Dennis,
One thing I would strongly recommend is separating the problem into two layers:
- How to extract/sync the content from the external KB
- How to expose that content to Genesys Cloud in a supported and maintainable way
From the Genesys side, today the most stable/native integrations are really ServiceNow, Salesforce and SharePoint through Knowledge Fabric. Because of that, many teams end up using SharePoint as an intermediary repository instead of trying to build a fully custom runtime integration directly into Copilot/Knowledge.
The challenge usually is not the Genesys integration itself, but maintaining synchronization, metadata consistency, IDs, permissions, article lifecycle and reindexing from the source platform.
I've seen some projects initially trying:
- direct API sync
- custom middleware
- pushing articles dynamically into Genesys Knowledge
but over time they started facing problems with:
- renamed articles
- duplicate documents
- stale embeddings/indexes
- broken references
- sync conflicts
- deletion handling
especially when the external KB was not designed for incremental synchronization.
Using SharePoint as an intermediate "normalized repository" can simplify a lot of this because:
- Genesys already supports it natively
- indexing/reprocessing becomes easier
- document structure is more predictable
- Copilot behavior tends to be more stable
If the external platform exposes APIs or webhooks, one good architecture is:
External KB → Middleware → Normalize Metadata → SharePoint → Knowledge Fabric
In larger environments, I would also strongly recommend keeping a persistent external document ID instead of using titles as identifiers. Titles changing over time is extremely common and can easily break synchronization logic if they are treated as primary keys.
The GitHub connector sample shared above is a good starting point technically, but for production I would pay special attention to:
- incremental sync
- idempotency
- delete handling
- versioning
- retry/reconciliation jobs
- observability/logging
because the operational side of KB synchronization usually becomes the hardest part long term, not the initial integration itself.
------------------------------
Gabriel Garcia
NA
------------------------------