Architect Best Practices

[Ana_Laia]

Greetings,

I’ve some questions related to architect best practices.

On our client IVR we need to pass information between flows. For instance, on a flow it’s set a value which the next flow will consult it.

Our question is: What are best practices to pass information between flows? Customized conversation attributes/participant data, data tables or if there are other forms?

Thank you in advance.

Best regards,

Ana Laia

[Jerome.Saint-Marc]

Hello,

I don't know if it is a best practice, but I would prefer conversation participant attributes to do this, unless you need to pass an extensive amount of data.

One reason why I would prefer Participant Data/Attributes may be that I "come from" the Genesys Engage platform, where there was the concept of User Data (list of Key/Value pairs attached to an interaction) and that you can compare to the Genesys Cloud Participant Data.
In order to exchange information between strategies (equivalent of Architect flows), Genesys Agent Desktop, ..., we were using this a lot.
Storing data in a database sometimes as well, but in general, using User Data by preference (unless there was something in the flow/integration/requirement which prevented from using it).

So why Participant Data?
Because there are available (native) actions/blocks in Architect flows to achieve this (Get Participant Data/Set Participant Data), and because it is also easy to extract them or to update their value in a Script (present at Agent level in the Genesys Desktop).
It is true that you can't remove Participant Attributes but you can still override their value (to reset it to something that would be understood in your flow as empty/no value) as Melissa explained in your other post.
Moreover, when you use the Get/Set Participant Data, this does not consume an API call (from an API rate limit point of view).

Another reason is that the info is easily available, in the conversation context - if I need it at Agent level (via a custom app using Platform API) or if I need to troubleshoot to understand what happened to a specific call/conversation.

But it depends a bit on the amount of data you need to pass from one flow to another (distinct variables/columns/attributes) and their size, or if you need this data to be confidential (and if nobody should be able to read it via API retrieving the conversation context).
In this case, data table might be an option.

Few things about Data Table that you may want to take into account.
From an Architect flow, there is a block/action to perform a Datable Lookup (based on a primary key).
But to write records, update records or delete records, you will need to create Genesys Cloud Data Actions to trigger the corresponding Platform API endpoints.
The data table follows a NoSQL model - so searching for a value in columns is not possible (you can only use the primary key to get access to a specific record). In this case, you would have to browse the table (technically possible) but that would not be easy to achieve this in an Architect flow.
As you'll rely on Genesys Cloud Data Actions to write/update/delete a record, note that these requests are subject to the API rate limit (not saying it is a showstopper - but depending on how many request you may have in parallel, it is something to keep in mind).

The other thing (more important) that you need to take into account with Data Table is how you will "clean" your data table. I mean how and when you will remove previous records/rows.
Triggering the delete from an Architect flow is not good enough. A customer/caller is always subject to abandon the call at any stage of your flow (In IVR/Architect flow, in Queue, ...).
So you would probably need to run a batch (periodically) to remove these so the data table doesn't grow too much (it has a limit - see here).

Personally, I'd use Participant Data, unless something does not fit with your use case/flow.
I use Data Tables when I want to store parameters/data that I'll use for all calls/conversations (or a subset).
I mean one record serving multiple calls (ex: to externalize some parameters used in the logic of an Architect flow - to make it easier to modify the distribution without having to edit/save/publish the Architect flow again).
In this situation, I don't need to worry about the delete of the rows. But that's a different scenario than yours.

Hope this helps a bit.

Regards,