FireStart releases version 2019.4
An article by Sean Hickey
Behold, FireStart Version 2019.4 has been released and boy do we have some updates for you. For 2019.4 our savvy devs focused on five specific areas of improvement to make your lives easier and, of course, more efficient! Namely, we’ve increased the authentication and search providers, added an external data search function to our forms, increased oversight with additional responsible persons, created a people picker to extension fields, and, finally, developed a selection filter for workflow forms.
Authentication with FireStart Identity Server
All new customers conducting a first-time installation, will have the ability to choose from two additional authentication and corresponding search providers:
- Azure Ad with Graph
- SAML with an External Search Service (or ActiveDirectory for ADFS)
The FireStart Identity Server handles user logins and searches for users and groups that are used in FireStart. In order for FireStart to find users who log in through the search provider, it is important that the authentication and search provider match.
Changing search providers on an already running system is currently not supported. As such, existing customers will stay with their current Active Directory.
External Data Search
Forms are now fancier! With External Data Search you can select multiple items from an outside data source with a REST API and create a CSV, which includes the values of all selected items. This functionality consists of an autocomplete text box and a list box underneath where you can view already selected items. It works with every REST API that has a JSON response and one of the followed supported authentication schemes: Anonymous, Basic, NTLM, or FireStarts Internal Access Token.
Once configured in the FireStart Form Builder, simply use JSONPath to select specific data from the JSON response and bind its output CSV to a business entity. This allows you to further process the data in a relevant workflow and streamlines your operations since the external data is now synced with FireStart.
Previously, there was only one type of responsible, the Model Owner, who was responsible for all actions in the model and workflow. As it is often not the case that one person is singularly responsible for all of the steps in a process, we’ve added two additional responsible options: Model Responsible and Workflow Responsible. The result is that you can now distribute responsibilities appropriately and efficiently, such that should errors occur, the right person is notified to handle and correct the error.
When you first create a model, the model creator is set as both the Model Owner and Workflow Responsible. If no Model Responsible is set, the Model Owner is chosen by default. After upgrading to version 2019.4, Model Owners of existing models will be set as Model Owner and Workflow Responsible. All responsible persons can be changed in either the Meta-information section of the property panel or model settings. Additionally, the responsible persons are visible during execution and in the Process Portal.
The Model Owner is often a department or team lead who has created the model but may not play more than a supervisory role. The Model Responsible, on the other hand, is commonly a team or department member and is accountable for the components and implementation of a model. The Workflow Responsible oversees model execution and therefore receives all user-failed and activity-failed tasks where a User in Charge has not been set. The Workflow Responsible is typically a person from the IT department.
Extension fields are now updated and welcome new field types ‘Single User’ and ‘Multiple User’ to streamline your searches. You can now search quickly and directly for users and groups and add them to a model without having to manually type in e-mail addresses or usernames each time.
In order to configure this, simply add an ExtensionField for each new Type, select the Users for the chosen ExtensionField and the users should be displayed in both PFC (Property Panel, WordExport) and FPP (Property Panel, SummaryView).
Selection Filter: Cascading Lookups
The new selection filter allows you to easily restrict available entries based on a condition. Of course, Business Entity Relations are always considered out of the box, which allows you to use Cascading Lookups within your forms, even without an additional condition. What this does is enable your workflow user to select the correct data entry quicker and easier. Once the form designer has defined a filter using the condition editor, the workflow user only sees the relevant data displayed for that selection, enabling him or her to choose the correct data. This filter works for pre-defined values set in previous workflow steps, as well as those in the current form.
Since the results are filtered according to parameters set by the form designer, the workflow user can make the correct decision faster. This results in not only a drastically reduced task size, as large selections are made much more targeted, but also increases efficiency and reduces the chances of an error occurring.