Product Update - May 2018

In the latest version of the product, we have focused on making it easier for you to debug flows while simultaneously improving the way we handle personally identifiable data in the debug logs. We have merged the functionality of the erstwhile 'wait for event' node with the 'receive' node and also introduced a new 'Branch' node that helps you implement branching logic within flows without the need to write custom code. Finally, we have introduced some exciting updates in our SDKs to support threads within in-app messaging and enhance the way geofencing works.

Debug mode in flows

We have made several changes to how data is captured, stored, and presented at various stages in the platform. This also includes encryption of the transaction logs accessible in the debug mode. In this release, we have made changes to ensure that you are able to debug flows with ease even with the encrypted logs. We have reorganized our logging process to further improve data security by splitting the information captured within debug logs into 3 levels based on the sensitivity of the data being captured.

Level 1 - Flow summary logs

Available to all IMIconnect users, flow outcome is surfaced for each run of a flow allowing users to quickly scan through and identify sessions that ran into issues. This view also shows the total time taken for running the flow and the trigger that initiated the flow. Users can drill down into any transaction and view the transaction sequence summary.

Level 2 - Transaction sequence summary

This view lists the complete sequence of nodes executed for that particular transaction. It also lists time taken to execute each step and the outcome of each step. 'Step' here refers to the run-time execution of a particular node.

This allows users to verify the flow business logic without having to go into technical details.

🚧

Encryption

The level 1 and level 2 logs (which are both summary logs) do not contain personally identifiable information (PII) and are therefore not encrypted. However, the details of node execution may contain PII in which case the PII is encrypted. Only those users who are authorised by the client admin and have a 'data decryption password' can decrypt these detailed logs to view them in plain text.

Level 3: Node execution detail

Node execution detail is available only to users authorised by client admin and upon supplying a valid 'data decryption password'.
This view, by default, shows PII data in encrypted form. However, basic information such as the outcome of the node and the execution parameters such as start time are available to all users in plain text.

📘

Debug Logging

To capture the node execution detail logs, user must enable 'Debug logging' under 'Service - General settings'.

In the following example, without supplying the data decryption password, users can verify that the 'send' node was configured to wait for delivery report and the node successfully received a DR at 2018-05-23 12:11:41.431, and it took 8.257 seconds for the delivery report to land on IMIconnect. However, the details of the message itself are encrypted.

The user can click on 'DECRYPT LOGS' at the top right hand corner at which point the user is prompted to enter the data decryption password. Upon supplying the data decryption password, the full context of sending the message is available to the user as shown below. Complete details allow the user to get to the root cause of a problem effortlessly.

New 'Receive' Node

The new 'receive' node provides greater flexibility in handling events that need responses from end customers and it also combines the receive functionality with the ability to wait for external events to resume a flow. With this change, the previous 'wait for event' node has now been deprecated. Flows that already use the 'wait for event' node will remain unaffected.

Following capabilities have been added:

• Cross channel support - Receive messages on any channel supported by IMIconnect which includes: SMS, Voice, Messenger, Twitter DM, E-mail, In-app & WeChat

• Wait for more than one event: Now a flow can simultaneously wait for more than one event. For example when using Messenger, simultaneously wait either for an inbound message or a post back event.

• Simplified configuration: The condition for resuming a flow session is now configured in the context of an event, instead of setting a 'session key'. For example, if a SMS response is expected, the waiting condition must include 'From number' & 'To number'.

• Added support for custom event v2 along with v1

  • The new 'receive' node supports inbound web-hooks (custom event v2)
  • Users can additionally configure conditions for resuming a flow. One or more parameters within the event post data can be set to match for resuming a flow. For example, resume flow only when a qualifying 'ticketID' is updated in a 3rd party system.
  • An open ended condition system allows for greater flexibility in resuming a flow.
  • Both v1 & v2 support conditionally resuming a flow

📘

'Wait for event' node merged

The 'wait for event' node capability has been merged into the new 'receive' node. The merger facilitates flow wait options across channels events and custom events simultaneously. Existing flows are backward compatible with the old 'wait for event' node.

Here, the flow will simultaneously wait to receive any of the 9 receive events namely:

• Inbound SMS from customer on the configured MSISDN (or)
• One of the Facebook Messenger events from the customer
  • Incoming message (or)
  • Post back (or)
  • Account linking (or)
  • Authentication (or)
• Referral (or)
• Inbound Twitter DM from customer (or)
• Inbound email from the customer (or)
• Inbound custom event on event ID 3766 where the post key value pairs match the set data i.e. Name as 'IMI' and userID as '66'

The complete context for resuming the flow is configured within the 'receive' node.

New 'Branch' Node

With 'branch' node, users can execute conditional operations without having to write JavaScript. Users can setup multiple branches, with each branch satisfying a logical condition. The node is aimed at users who do not need the full flexibility of writing custom code, but need to perform simple logical operations to make decisions within a flow.

For example: In an NPS survey (On a scale of 5), the 'branch' node can process the customer's response using the expression builder without the user having to write any Java Script. In this case, configuration would be as follows:

• Branch 1 condition: Score Less than / equals 3, request detailed customer feedback
• Branch 2 condition: Score 5, update Salesforce
• Default branch: Everything else other than configured conditions, i.e. any other response apart from 0-5
  Here is a look at how this branching logic is setup in the 'branch' node.

For a set input, the 'branch' node evaluates each of the conditions and exits the node whenever a branch condition is met. Conditions are evaluated top-down sequentially.

Currently, following operations are supported:

• Equals
• Not equals
• Less than
• Greater than
• Less than or equals
• Greater than or equals

Following additional operations are planned for the next release, which include:

• RegEx (Support for regular expressions)
• Equals.ignorecase
• Contains
• Contains.ignorecase
• In
• Not in
• Starts with
• Ends with
• Between (range)

Testing branch node configuration

Branch node has a built in 'test' option to verify the node outcome for a given input. Users can simulate different 'input variable' values and see the outcome while setting up branch conditions. Test mode automatically picks up all variables needed as input for running the conditions setup.

Upon running a simulated test, the branch with the condition matching the simulated input is highlighted on the same branch node configuration.

Hub signature for call-backs

Hub signature now allows users to select base64/hex/text as input type for the key. The option is available under 'settings' and is optional for receiving call-backs.

Once configured, the key is used to create a hash signature of the JSON notification which is then sent using X-Hub-Signature in the request header and can be verified by the receiving web-hook.

Here is an example of the request headers when hub secret is configured.

New reports for email and push notifications

A new report added to the current email reports provides you with an option to see the average time difference between the delivery and click of an email in cases where the email is clicked. This could be a good metric to track for notifications such as appointment reminders or delivery notifications, and benchmark against your customer support volumes.

In addition, failure count for push notifications is now available as a table. Users can see the reason and the number of push notifications that failed because of a specific reason. A list of status codes for push notification failures is available here

Multiple geofence support

This update enables users to create multiple geofences together by either selecting the location of interest one by one or by uploading the list of locations in a .xls file.

To use these geofences, users have to create a rule with one of the app location events as the trigger and select the geo-fence in the conditions.

🚧

Geo-fence creation

Geo-fences need to be created under Tools before they are available for configuration within Rules.

One can optionally add a list of 'app users' to the rule. If such a list is added, the rule will be applicable for only those users whose 'app user ids' are included in the file.

Threads for in-app messaging

In-app messaging now supports threaded messaging. There are two types of threads that can be created to serve a variety of use cases.

We also have new APIs and SDK methods to create and manage threads. Threads are available to all our current users and the documentation is available here.

Changelog

• added: Debug mode in flows
• added: Multi-channel receive node
• added: New branch node
• improved: Hub signature for call-backs
• added: New reports for email and push notifications
• improved: Multiple geo-fence support
• improved: Threads for in-app messaging