Genesys Cloud - Developer Community!

I would think that this would be a simple question, but I am unable to find the answer and have tried for too long to make it work.

Can anyone provide a sample in Architect so a flow can call a common module or Bot and provide a JSON object as the input.
I have created a JSON data item, can reference it, load it, etc in the flow.   I have setup the Bot with the same structured JSON object and tagged it as input, but when I run the flow, the values do not arrive in the Bot or Common module.

Bruce, the way to handle this is to serialize the JSON object into a string, pass that string to the Common Module or Bot, and then parse it back into JSON on the receiving side before using it.
One thing to keep in mind is that Architect string fields have a limit of around 32K characters, so it's important to check the payload size. If the payload can get too large, then compressing the JSON, or using a different approach like passing only a correlation ID and retrieving the full payload elsewhere, should be considered.

I agree with Breno.

Serializing the JSON object into a string can be a good workaround when the object is not being passed as expected between the flow and the Common Module or Bot Flow.

The main point I would reinforce is the string size limit. Architect string variables have a limit of 32,000 characters, so this approach is safer for small or controlled payloads. If the JSON can grow over time, especially with customer data, arrays, history, or nested objects, it is important to validate the payload size before relying on this solution.

For larger payloads, I would avoid passing the full JSON through the flow. In that case, passing only the required fields, or passing a correlation ID and retrieving the full payload from an external system or Data Action, would be a cleaner and safer approach.

So, the string approach can work, but I would treat the 32K limit as an important design constraint.

More digging and the serializing the JSON is not always necessary.   Found a solution at least for single level JSON objects.

In calling flow, create a JSON (Update Data -> Added Variable of type JSON, Expression and define it).  For example:
myJSON 
{
  "active" : true,
  "someString" : "this is the string",
  "cntDays" : 365,
}

In the Bot, create a data element of type JSONcalling flow, create a Resource->Data element of type JSON, for example call it botJSON.    Edit that item and set it to Input (and possibly output).   It will then be referred to as Flow.botJSON

In the calling flow, call the bot you created, the input field will populate and put in the name of your object, (e.g. myJSON).

When you run this flow, inside the bot you can refer to the elements as Flow.botJSON.active.

Setting the responses back if the JSON is specified as an output variable too, requires an update prior to the exit of the bot.
That update can either be a complete redefine of the object, similar to setting above or you can update a single element in by a Update data with:

SetJsonObjectProperty(  Flow.botJSON, someString, "This is the new string" )

More testing needed for more complex JSONs.

Bruce, Interesting. I haven't used JSON inputs this way before.
Did you test only with a flat JSON, or also with larger/nested payloads, like arrays or multiple levels? For a simple one-level object this makes sense. I'm just wondering if it stays reliable with more complex or critical payloads, or if in those cases it's safer to use the string/correlation ID approach.

Just wanted to share a quick comment regarding one of the topics that Breno and Arthur mentioned.

They bot mentioned the 32K characters limit, and I just wanted to say that this MIGHT not be the current limit, but I didn't test it right now.

I simply remember a customer from about 1 year ago where we also thought this limit would be an issue, but during some tests we realized that this limit was no longer there, we were able to test strings with 90k+ characters if I remember correctly.

I don't recall what kind of Flow we were working on (Voice, Message, Bots, etc.), so I can't really confirm if this applies to all of them... But just keep in mind that the 32k characters might not be a current limitation for some scenarios.

Make sure to run some tests if the size is of importance for your solution!