[FEATURE] multi tenant dynamic flow

[niztal]

Describe the feature you'd like Create one bot who will support multi tenant customers.

Additional context I'd like to have one flow/bot which is similar to various customers which controlled by parameters.

For example, assuming I have sql query the only thing I'd like to change is a provided customer_id parameter. So let's say this bot is embedded in multi pages, each page differ by its provided params which will guide the bot to behave accordingly.

@HenryHengZJ how may I achieve such capability instead of duplicating that?

Thanks

[Jaredude]

@niztal You could accomplish that using overrideConfig. You'd have crossover issues. For example, what if accidentally place the customer_id 12345 on the website that's supposed to have customerId of 56789? But overrideConfig will allow you to pass vars that you can then ingest in the flow.

[chungyau97]

Hi @niztal, you want to achieve this using API or Embed Chat?

[niztal]

@chungyau97 via embed chat would be fine for me.

@Jaredude can you elaborate further about the override config, maybe provide some simple example? Not sure I'm following you..

Thanks

[Jaredude]

@niztal Using the embedded chat, you'd set your variable in the chatflowConfig < link to docs.

You would then use that variable in your flow to adjust your sql query accordingly

[niztal]

@Jaredude thank you so much

Can you please provide a very basic example how to provide dynamic param (e.g. 'customer_id') via this chatflowconfig entity?

It is not so clear from the documentation you mentioned above.

Thanks

[Jaredude]

This is an example using Postman and overrideConfig. chatflowConfig for the embed is a straight pass through to overrideConfig, so the concept would work the same with an embed.

It's just passing an object in with properties. You'd then just need to use $vars.customer_id within a node that has access to $vars (custom tool, custom js, if/then) and use it in your query.

[niztal]

@Jaredude awesome 😎

One last question, how about the log? Would I be able to differ that somehow via the provided param (e.g. customer_id)?

[niztal]

@Jaredude another question please,

How about Pinecone's namespace? Do you think it's doable to send an overrideConfig param which will override the Pinecone's namespace? For example:

"overrideConfig": {

... "vars": {"customer_id": "test", "pinecone_ns": "test_ns"} }

and over the pinecone's node I will put over the namespace field: $vars.pinecone_ns

Do you find it possible?

Thanks

[Jaredude]

@Jaredude awesome 😎

One last question, how about the log? Would I be able to differ that somehow via the provided param (e.g. customer_id)?

I'm not sure what you mean by log

[niztal]

I mean chat_messages table.

Assuming I have one bot which serves multiple customers, I'd like to differ those chat-messages by some unique ID

@Jaredude

[Jaredude]

@Jaredude another question please,

How about Pinecone's namespace? Do you think it's doable to send an overrideConfig param which will override the Pinecone's namespace? For example:

"overrideConfig": {

... "vars": {"customer_id": "test", "pinecone_ns": "test_ns"} }

and over the pinecone's node I will put over the namespace field: $vars.pinecone_ns

Do you find it possible?

Thanks

AFAIK that would not be possible given the current structure of the Pinecone node. The pinecone node would need to be modified to allow for replacement of the namespace via a $var value... or maybe a simple js formula that would allow for ternary like $vars.pinecone_namespace? $vars.pinecone_namespace: 'default_namespace'

[Jaredude]

I mean chat_messages table.

Assuming I have one bot which serves multiple customers, I'd like to differ those chat-messages by some unique ID

@Jaredude

@niztal I see what you mean... While the sessionId is unique, you want to have a field in the chat history that would allow for grouping so that you could see all chat history for a given tenant. That's an interesting use case. The chat history logging is currently a fixed schema. The chat memory nodes could be refactored to allow for a custom logging schema (defaulting to the existing schema for those who want to just use the existing loggin schema). Each node would need to be modified to support custom logging, and there would need to be failsafes to ensure that the schema meets the minimum (default) requirements.

Another use case I could see for custom logging would be for storing some sort of value based on the message content. For example, you have a bot that performs a database search for the user and you store a hash of that search in your database and have searchId returned by the bot. The custom logger could parse the bot response and include the searchId value in the custom log entry so that you don't have to parse the message every time to find the searchId values and can quickly reference them later when querying the DB for some sort of reactivation campaign. Another use case for the human input would be using a custom logger for real-time intent detection and logging that intent when the user sends a new message. This way, you can then easily use it for reinforcement learning (ie. the intent algorithm at time of message detected A and now the algorithm is better and detected X instead). Or even just basic input classification: e.g. The bot asks the user for their address and when they respond, you detect that it's an address and set a flag in the custom logger so that you can easily identify contact information.

@HenryHengZJ Is anything on the roadmap for custom logging for chat history? If not, are you open to contributions for that as a new feature?

[niztal]

@Jaredude that's a very interesting feature you're talking about.

I wonder if for the bare minimum we would just store the overrideConfig json as part of additional new column we'll add for the chat_messages table? This way anyone could query anything he would per his own dynamic schema and correct me if I'm wrong it may cover some/most of your cases above.

If you find it valuable I can do this feature.

[Jaredude]

@niztal storing the overrideConfig json in a new field for chat history would handle the original use case you mentioned. For the custom logging, it wouldn't cover any of the scenarios I mentioned, but the two are not mutually exclusive. A custom logger would extend any default schema. If the default schema changed to add an nullable field for overrideConfig, a custom logger would just be required to expand on the default schema. In other words, a complex custom logger feature is not dependent on an overrideConfig column and the overrideConfig column is not dependent on the custom logger.

[niztal]

@Jaredude appreciate your comment, so I think I'll work on storing the overrideConfig and the customer logger would be a different feature.

[niztal]

@Jaredude appreciate your comment, so I think I'll work on storing the overrideConfig and the customer logger would be a different feature.

@Jaredude https://github.com/FlowiseAI/Flowise/pull/1709 please review

[niztal]

This issue has been solved via PR https://github.com/FlowiseAI/FlowiseChatEmbed/pull/129