Introduction of and first steps in Kofax Total Agility

Kofax Total Agility (KTA) is one and probably the leading product in the First Mile™ strategy of Kofax. This strategy implies a simplification and improvement of the first steps of a business case. You can see KTA as a versatile workflow platform which provides solutions for customer interactions and has additional strengths for any cases of input management and digitization.
In addition to the benefits of reacting to disruptive markets and continuously changing requirements for business processes, which a workflow engine provides, KTA contains an integration of mobile devices, reporting and powerful tools for classification, separation and extraction of documents.
The already well-known products of Kofax Capture (KC) and Kofax Transformation Modules (KTM) are included in KTA. There are also features and interfaces to integrate Sharepoint, e-signatures and Robotic Process Automation (RPA / Kofax Kapow) available. According to the analysts of Forrester, Kofax is on the pole position in Multichannel Capture (MCC) and in the leader group of Smart Process Applications (SPA).
This article will give you a first glance at KTA, following articles will take a closer look at different detailed aspects of it.

Working in KTA – scenario

A typical first step is to define a workflow for your purpose. In our scenario we will show how to recognize an incoming email similar to Kofax Import Connector (KIC), take the attachments of it and start a job based on a defined workflow. After this you can work with these document information however your business case requires it.

Recognizing and importing emails – one of the possible ways to import data

After logging in you will see this portal.

• The “Process Designer” is for designing the workflows and cases.
• The menu entry for the “Form Designer” is for all topics related to the UI. Here you can create forms, particularly automatically based on your designed workflow steps and customize them also.
• “Resources” handles all topics about authorization schemes. You can configure user groups here, restrict access for processes or parts of the workflow.
• In “Data” you can create general (global) entities and especially classification- and extraction- groups, which will become important in the following articles for document recognition and extraction.
• “Business Monitoring” is mostly about reporting, but not only. You can create events and use them in workflows, too.
• “Integration” contains even more interfaces to external systems than written in the description.
• Additionally to the description in “System Settings” you can define job schedules and system tasks. We often use this for keeping the system clean in a way of deleting jobs and documents after a defined time range automatically.
• “Packages” is used for deployments and delivery. There are some ways to move a version of a workflow to another system, but using a package means you provide every dependency and a versioning, at least you have the option to do so.

Choosing the process type – the first decision

In KTA you differ between the two general types of workflows – a business case or a business process (job). These types are also named project types.

To compare them and be able to decide which you should use, you can look at and weight these criteria.

1. Is the process mostly automated? If yes, use a business process.
2. Is the process knowledge-driven and unpredictable, because you need input from users? If yes, use a case process.
3. Is the process defined at design time? If yes, use a business process.
4. Is the process probably lasting longer in the system? If yes, use a case process.
5. Is the process re-usable? If yes, use a business process.
6. Is the process very clear mandatory in another process? If yes, use a case process.

The attentive reader notices that there are some more entities: “Case fragments”, “Skins” and “Business Rules”. They are a kind of subtypes of the general project types.
A “Case Fragment” is an optional or mandatory part of a process, which is not reusable and it is tied to its case definition.
A “Skin” is a process which inherits all settings like SLA, variables and the process definition itself from a process, which is marked as Template. If needed you can change then single aspects of it for this variant. This is often used, when you think of country, branch or even department related processes. Most of the things are similar, perhaps there are small differences, so you do not need to create a new process, just define a “Skin”.
A “Business Rule” is a fully automated process, which gets an input, generates an output / result and provides it to the caller. There is no user interaction in this “Business Rule”. Internally it will be compiled for performance. Examples for a “Business Rule” may be a validation routine up to a complex decision making in a process. It is reusable in processes and in forms, too.

Workflow elements – feels familiar, doesn´t it?

While designing a workflow you just have 4 general elements:

1. Start point
2. Decision node
3. Workflow node / step
4. End point

Ok, ok, if you want to be very precise then you can count the line to connect elements and show dependencies as the fifth element. 😉

After creating a new process exactly these elements are directly available. When you are already experienced with some kind of business process model notation (BPMN) or “event – controlled process chain” (eEPK), the appearance will be nothing new for you.

Working with KTA – the first workflow

To create a workflow, which can handle documents and work with them later you do not need to think about the source. Even if the workflow has in this case the name “Email retrieve”, the behavior of it could fit to any case of incoming documents.

This workflow starts and immediately checks, whether documents exist. If not, we send an email to a variable recipient.

The so called decision node is defined like that:

Only the „True Path“ is set, but if you have multiple conditions, similar to a programmatical switch, then use a “Branching rule” as type of a node.

To check, whether there are documents for this job or not, just set this condition text in the decision node:

KTA provides you help by the icons on the right hand top corner. These symbols help you to show the available:
1. Variables
2. Document sets or
3. Document types

By selecting one of these icons the navigation opens automatically for the selected type and allows you to drag the needed entity / parameter to the textbox. This way to navigate in KTA is available everywhere. Next to any input field you will find some icons, which show you which entity is expected and what kind of variables you can use.

In the case of no existing attachments, an email shall be generated and send by the system. This is easy to configure, just define a workflow node as type email:

In the configuration and advanced settings of this node you will be able to set the email information.  Note that you can work for every string content, recipient and so on with variables, like seen below in “To”

In the positive case of the decision in the job we want to transform any attachment internally to another format we can work easily with. (You are not limited to the chosen format, you can transform it later of course in another format).

To do so just define the related step as “Image processing” node, set the Input Folder, which is normally an internal defined entity / variable and set a defined  VRS – profile (virtual rescan).

The last step in our process is to create a subjob of this process instance.

You just select the target process or case and provide needed variables. You will see all variables of the destination process, which are marked as “Initialization”.

And what about user interfaces? – Automated creation of forms

Based on your definitions of the process and the single workflow steps or so called nodes, KTA is able to generate forms automatically. So every time when you define your node as a workflow step, which needs interaction with the user, you mark it by choosing the node type.

Example:

When you look at every node you will see that some of them have an icon for a person or an automated activity . Typical nodes for user interactions come from the capture topic: Scan, Validation, Classification and Verification, but by using the ordinary activity you can design a node always as a user interaction, when you need it.

To create forms you can navigate to the start, select “Forms Designer” and you will find this area:

Depending on your choice you can create one or all forms for an existing process:

By knowing the related process KTA can automatically associate every user action in the workflow to the generated form. After generating you will find these forms directly accessible and available in the process and the web browser.

A standard scan form looks for instance like that (should be very familiar to Kofax Capture user):

You can either define the language of your environment or you keep it generic. Then KTA asks your browser for the localization information and takes the correct descriptions. You can configure a default, which will be taken, if the requested language is not available or explicitly defined (perhaps you need to install some additional language packs).

Customizing and corporate identity  – Or how to change the frontend without any coding skills

The general access to KTA forms for customers is by using a given URL for a “Site”. This “Site” can be defined in KTA, you can define standards for its appearance, you can also distinguish between different devices (desktop, tablet or phone). In every form you can overwrite the standard setting. For instance you can decide to include the header form, use another header or even none.

The standard login form would look like this:

But of course you can change its appearance by using the internal tools of KTA. You can navigate to the form and open it with the form designer.

In the designer you can define controls, add them in the form, change its appearance and so on.

This is an updated Login form based on the standard, but changed totally in its appearance. When you look at the structure, it is a good approach to think in direction of a gridbaglayout or even more simple of a chess board. I would recommend to define rows and add cells to them. This allows you to work with separated units and you have a clear structure for later maintenance and changes. With these tools it is possible then to create something like this:

Conclusion – and perhaps a vision

KTA is not only a fully-blown business intelligence (BI) solution, dependent to the history of Kofax with KTA you have a platform, which has a strong focus at the input management. You do not need any programmatical skills (of course some JavaScript or C# would help though ?) to design your business solution from scratch. It is easy to integrate, but can be used as a single standing system, too. Without a big effort you can include robotic process automation, connect to external databases, Sharepoint, email (KIC) and so on. So you can see KTA is more or less a collection of already approved products of Kofax (KC, KTM and KIC), additionally to a grown up and advanced workflow solution which helps to design business processes for disruptive markets.

We already use KTA in different projects with particularly different toolsets and scopes. It is possible to communicate with this system both using a REST Service and directly using generated or self-written UIs. In the upcoming articles we will take a detailed look at every area of KTA.