Dynamic Knowledge Base

[greenhows]

Hi just a query around knowledge bases. We are creating a digital bot flow using the inbound message flow.

We have a scenario where we may have the same type of flow but need to alter the branding and the wording to fit specific clients.

To avoid having to duplicate the same bot flows multiple times, we've used a custom attribute a part of the messenger deployment to tag the different client deployments. Then we can use a datatable to use the same digital bot flow, but present the specific branding and wording to a particular client.

The question is how you would you go about using a digital bot flow in the same manner using the knowledge base tool. Lets say we want one digital bot flow but depending on where we have the messenger deployed we may want to point to different knowledge bases to give a custom view.

For example we might have a knowledge base that says "types of fruit"
Client A- Apples
Client B - Pears

Knowledge Base -
Types of Fruit - Client A. Answer = Apples
Types of Fruit - Client B. Answer = Pears

Digital Bot Flow = receives custom attribute from deployment of "Client A" then uses the knowledge base Types of Fruit - Client A to bring back Apples based on the response from the customer and which website they are on.

Hopefully that makes sense, any one came across something like that before?

[jacobshaw]

@greenhows
The best solution I can think of from an Architect standpoint would be to have two bot flows with different knowledge base contents. The upstream flow would route to the bot flow based on client type.
From an API standpoint, the bot flow is using POST /api/v2/knowledge/knowledgebases/{knowledgeBaseId}/documents/search internally, and there are ways to filter based on things like labels using that resource, but that would require implementing your own knowledge base handling instead of using the build in component.

[greenhows]

Thanks Jacob appreciate the response, that makes sense.

So we'll in effect need to create duplicate versions of our bot flows but amend them so they point to the different knowledge bases. But we could still have the single inbound message flow and route to the relevant digital bot flow based on client from our deployment metadata.

Agree yeah we could go down the API route to bespoke the solution to make it more elegant, but I think we'll try to keep to the core product where possible.

Thanks again