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.

Kofax 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.Interfaces contained in Integration
  • 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.

Process types

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.

Workflow creation

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:

decision node

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:

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:

defining 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”

set the email information

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).

transform any attachment internally to 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.

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”.

variables of the destination process 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.


generate forms automatically

When you look at every node you will see that some of them have an icon for a personperson icon or an automated activityactivity icon. 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:

Forms Designer

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

create 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):

standard scan form

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.

overwrite the standard setting in the form

The standard login form would look like this:

standard login form

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.

change standard login in form designer

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:

updated Login form

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.



  • Arsh

    How can we skip validation? Can we create a childjob and skip validation for all valid documents?

    • Daniel Brodka

      30. June 2019 von Daniel Brodka

      Hello Arsh,

      when you are in validation the focus jumps automatically to non – valid fields / documents.
      But when all documents are valid, you have on folder and document level some attributes like “valid”, which you could check in a condition.
      If you want to check additionally, if the classification was confident, I would probably recommend a business rule, which checks in a loop all documents
      for this attribute (Classification confident), too.
      A business rule is better here instead of a simple childjob, because it is faster. A business rule is always usable, when you have no user interaction within it.

      Hope this helps.
      Regards Daniel

  • Arsh

    3. July 2019 von Arsh

    Thanks Daniel. I implemented this solution. I was facing some challenges for moving all valid documents into a new job (skipping validation) and invalid documents into the parent job (validation). In KTM it’s very straight forward but here it’s a little complex.

    • Daniel Brodka

      3. July 2019 von Daniel Brodka

      Hi Arsh,

      yes. I am also still searching a configuration option like “show me validation, when any error / invalid field” appeared.
      I think I do not understand the use case, because I am wondering, why you want to create a subjob.
      Anyway, if you do that and you want to move x – documents to another job, I would recommend to create a new folder (CaptureDocumentService -> CreateFolder), use the move – operation (CaptureDocumentService -> MoveDocument)
      and pass the folder as input variable to the new subjob. But this would mean you split the job (the batch in KTM) into two and it will be hard to figure out the history in case of maintenance, right?
      Hint: When you do that, do not not forget to reduce the loop counter by one for each moved document.


  • Arsh

    3. July 2019 von Arsh

    Use case : We have developed solution using transformation designer. We need to skip validation activity for all valid docs and invalid docs should go through validation. For example if a job created with 10 docs and in the extraction activity if 9 docs became valid and one doc is invalid then 9 valid docs should go to export activity and an invalid doc should goto validation.
    As you mentioned above I created a folder for valid docs and then a loop and decision to check if the doc is valid or not. If it’s valid then in create new job activity a process to move the valid doc to new folder. Yes i am using counter for reducing moved doc.

    • Daniel Brodka

      7. July 2019 von Daniel Brodka

      Hi Arsh,

      got it.
      Sounds like you can cover the whole case now, right?
      Test were successfully already?



Your email address will not be published. Required fields are marked *