Common pitfalls / bad practices in Kaizala solutions

In this post, I will be talking about a few commonly observed pitfalls / misconceptions / bad practices that I have come across to help you detect them early and design accordingly. I hope to keep adding to this as I come up with more, will probably have a section that captures the updates to the end of this post (if I happen to update).

Background

In order to easily discuss the areas, I will re-use the old diagram that I had used in the Introduction to Kaizala Extensibility post. (In case you have not read that, suggest you read it for context.)

Fig-1: Kaizala Extensibility overview

Broadly, I would like to draw your attention to the blocks in the above diagram:

  • Green blocks: custom components that you would be building / writing code for. Client side customization is through custom actions and service side integration is made possible using REST APIs and WebHooks.
  • Yellow block: any 3rd party service (could be your line of business application, SAP, CRM, HRM, etc.).
  • Blue blocks: Kaizala components that are involved.
  • Orange arrows: The calls your code would be making (or your code getting called in case of WebHooks).

The KASClient.js is the Action package SDK that allows you to call / tap into the native functionality of the device (like location, device locale, network calls, barcode scanner, etc.) and also abstracts the action package from the underlying platform making it platform agnostic. Kaizala runtime and the mobile app are there for the sake of completion.

On the other end is the Kaizala Service which serves a host of functionality like the management portal, creating / maintaining connectors, reporting, etc. In the scope of this post, we are interested in the REST APIs the Kaizala Service supports and the WebHook callbacks that you could subscribe to.

Pitfalls / misconceptions

This section captures common mistakes that are made and how they could be averted. Some of them (not all) result in erroneous behavior. Others result in risking security of your solution. Below is a picture to demonstrate the pitfalls:

Fig-2: Common mistakes, bad practices or pitfalls while designing a Kaizala solution

A) Calling Kaizala Service from within an action package

Accessing Kaizala API from within an action package will need you to hard code the token, application secret and application id – which can result in your credentials being compromised. As far as possible, rely on the functionality provided by KASClient SDK. If there is a need to access a functionality from the Kaizala Service, have your custom service that will implement this functionality and secure it with the Kaizala Integration Service token.

B) Using native HTML controls in action package

HTML controls that tap into the native platform will not work within a custom action package. Rather, find a method in the KASClient SDK that can help you achieve the same. For example, in html, the below snippet will result in file picker being launched.
<input type=”file” name=”myFile”>

However, if you want to launch in file picker, use the showAttachmentPickerAsync API in KASClient SDK.

C) Accessing 3rd party services from action package

Third party services typically require authentication and providing the client credentials from within the custom action will compromise security. Rather, have your custom service that will implement this functionality and secure it with the Kaizala Integration Service token.

D) Calling your service from action package

Calling your service from custom action package is not bad. However, make sure you have secured your service. A good way to do this would be with the Kaizala Integration Service token.

E) Modifying custom actions created from portal

Kaizala Management Portal has an action designer that you could use to build your custom actions. But downloading this package and customizing survey.js for achieving your functionality could be cumbersome. If not much, you could build your own custom action using HTML / JS. We also have a bunch of cards that you could pick and customize (if they suit your needs) shared as business solutions here and a couple in my post here.

F) Incorrect connector permissioning

While granting all permissions to a connector is a bad practice, also make sure your connector has the requisite permissions that you are trying to access. Not having the requisite permissions in the connector will result in Unauthorized error.

G) Calling WebHook endpoint

Due to unfamiliarity with WebHooks, sometimes folks call the WebHook endpoint to get the data. The beauty of WebHook callbacks are that the data of interest comes in the callback payload in the request body itself.

H) Trying so send a directed message in a flat group

Directed message / message targeted to a specific user is possible only in a Hub & Spoke group (or Public group). In other groups, like a flat group or hierarchical group, setting the sendToAllSubscribers flag to false has no effect and will result in message / action being sent to everyone in the group.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s