For advanced use cases, we would like to introduce a new data type — array.
With this data type, you can make your automations more powerful and cut repetitive nodes in the flows without impacting the functionality.
In this article, you will learn how to create and modify arrays and get some real use cases. Note that Arrays aren't available in Flow actions and can be used only through API.
Creating Arrays
Manychat arrays can contain texts and numbers.
There are two ways how to create arrays:
- UI - In-product
- API
For creating an array via UI follow these steps:
- Navigate to Settings →Fields.
- Click on "+New User Field" button. Add the field name and choose "array" from the dropdown list, then click "create" button.
At this moment we support arrays only for User Fields (but not Bot Fields).
For creating arrays programmatically, use this method /createCustomField and specify array as a type in the body:
{
"caption": "My array",
"type": "array",
"description": "This field can store array"
}Reading arrays
Custom user fields with array type are accessible via:
- UI - In-product
- API
To get the list of already existing CUFs, navigate to Settings, then Custom Field menu. All CUFs are shown in a table format. You can check the type of a CUF in the column "Type":
You can retrieve the same list using method /fb/page/getCustomFields
Each CUF object contains type
CUF values associated with a particular contact are stored in a contact card. Here is an example, by the default Manychat shows the number of elements, upon click you can access all elements of the array:
The equivalent API endpoint is /fb/subscriber/getInfo
The response contains all CUFs with their type and values 
Modifying arrays
Modifying data in CUFs with array type is possible via:
- External request mapping
- Application action mapping
- API
- UI
Note that array type cannot be saved via the API, It will say "Type not supported: '160" via api setcustomfield
Via interface the Array types are not clickable under subscriber data, and thus cannot be edited manually here either
For mapping, the mechanism is the same. You specify the JSON path to the array, and Manychat saves this array into CUF. Below you can find an example based on real service/API:
This is the JSON response from Shopify Order API. Each order is unique and may contain a different number of items. With arrays, you can store all SKUs into 1 CUF. There is no need to parse and prepare a response for storing each SKU within its own CUF.
API endpoints setCustomField and setCustomFields can be used for saving arrays as well. Below you can find a few body examples:
- set non-empty value
{
"subscriber_id": {{subscriber_id}},
"field_id": {{field_id}},
"field_value": [1, 2, 3, "apples"]
}- set empty value
{
"subscriber_id": {{subscriber_id}},
"field_id": {{field_id}},
"field_value": []
}- clear CUF with array type
{
"subscriber_id": {{subscriber_id}},
"field_id": {{field_id}},
"field_value": null
}UI capabilities are slightly limited, but if necessary, you can clear CUF in the audience menu.
Select contacts you want to modify, click on "Bulk Actions" button and then choose "Clear contact Custom Field". After applying, CUF will be cleared.
Use cases
Arrays can be used for multiple use cases. The thing that unites them all: arrays are great when the data you work with contains an unknown number of elements. For example:
- E-commerce - every cart and order is unique. Orders may contain any number of items. You can assume that an average order contains 2 or 3 items and map each item individually, but in this case, you can lose some data if your customer ordered more items than you foreseen in your mapping.
- NLU / NLP based bots - services like [wit.ai] (http://wit.ai) analyze user input and send back intents and entities. And again, each user input is unique. Arrays work perfectly no matter how many entities the service sent back.
- Multiple-choice questions - if you use forms / surveys to qualify your contacts, you might be familiar with multiple choice question. The number of options each contact can select varies. It's easier to store them in arrays rather than parse data and create a separate CUF for each answer.
Below you can find two flows demonstrating a simple e-commerce case.
In the flow named "Array", as expected, CUF with array type was used. The mapping and condition block is easier and faster to setup, no risk of losing data as arrays are designed to store as many elements as necessary.
In the flow named "Multiple CUFs", the same flow was built but without arrays, only with simple one-element CUFs. Building this flow requires a bit more time (more mapping elements, more condition node settings) and may lead to losing some data.