TL;DR:
Our grid enhancements are still underway, bringing new conditional formatting options for vertical and horizontal grids, text formatting, and better visual spacing in pivot grids. Additionally, we’ve expanded our API behavior to allow customers to more easily handle response errors.
Consider the Following:
Users have always wanted to build out detailed grid reports, often highlighting problematic or outlying values. With the use of our conditional formatting options, we’ve empowered our report designers with a variety of condition-specific formatting to help emphasize various data points within their tables. The 3.7 release introduces a new conditional formatting option, available at the Report Part Properties level, which will allow report designers to set multiple conditional statements that can influence entire rows, entire columns, and even a select of cells within each row.
We hope that with the introduction of this tool, users will be able to finally create the unique styling and highlighting they want within their grid report parts. While this is only currently available for horizontal and vertical grids, it will be available for pivot and drill-down grids in the near future. Outside of providing some improvements to conditional formatting setup, we’ve also introduced new types of conditional formatting: Text Formatting. With these options, you will be able to bold, italicize, or underline values in your grids based on the conditions that you are setting.
Aside from simply improving part of our report design process, we’ve also added improvements to how our API can handle various response messages, giving our developers the freedom needed to gracefully handle less than ideal scenarios. For example, if someone is attempting to utilize Izenda’s API to create users automatically, they may encounter a 401 if they have not properly authorized their requests. With these changes, we’re allowing you to inject your own logic to better account for these types of responses so that your workflow can continue uninterrupted.
Developer’s District:
When integrating Izenda, you have to define a configuration JSON element, configJson, which is often shown in our sample kits as a part of the larger Izenda.integrate.js file. Prior to the v3.7.0 release, you were able to add a value stating that you wanted to handle any unauthorized requests, shown in the same sample kits as OnReceiveUnauthorizedResponse. Now, we’ve expanded that set of functionality, developers can look to implement something similar to the below image:
While this is a simple example, developers can create a much more robust error handling method that is referenced inside of this configuration element. In each integration of Izenda, there is now the capability to handle unauthorized responses, server errors, and more so that your end users have a seamless experience without stuttering or failure. In addition, this will also allow developers to program effective error handling inside of their integration with Izenda, allowing them to gracefully catch and handle certain responses from our API interactions to keep the customer workflow moving smoothly.
For more information on our release in general, please see our release notes page: https://www.izenda.com/docs/release_notes.html
Continued Success,
Seth Hutcheson
Technical Product Manager, Izenda
