Skip to main content

Users actions

In general, the interactions that a user can perform in a process are defined by the Workflow itself that models the implemented business. That is, the main interaction of a user with the process is performed through the tasks defined by the Workflow and in which the user has been defined as a possible candidate to perform the task. However, let's imagine a use case in which a user wishes at any time in the process cycle to invoke an action that allows him to obtain a report generated from the process data. Or for example, a use case in which the user wants to download a ZIP file with all the files uploaded to the different tasks of the process. As another example, a user may want to execute an action at any time that sends an email to all the users that have interacted in the process to inform them of certain facts.

The casuistry of types of actions to be carried out is unlimited and of any nature. That is why KuFlow provides a mechanism that allows process administrators to configure different actions that trigger customized behaviours. We call this mechanism "User actions" and it is configured on the process administration page.

User action types​

There are different types of "User actions" that process administrators can choose when configuring their process. These actions are configured in the "User actions" section of the "Processes" menu in the administration section.

Once configured, the actions are available to the process instances through a drop-down menu on the process detail page.

The actions displayed in this menu are subject to permissions evaluation so that if they are not satisfied for a particular user, then they are not displayed. For each "User action" it is possible to choose whether it is available for Initiator, Process Manager or both. In addition, the evaluation of permissions depends on the type of user action configured as we will see later. For example, if we have a "User action" of type "Start related process", then it would only be displayed for users who can start a process of the defined type.

The action catalog is constantly evolving, so we recommend that you keep up to date on new action types that are introduced in KuFlow.

Downloadable​

This type of action allows us to invoke a Temporal workflow whose purpose is to provide a file that will be displayed as a download to the user. For example, let's imagine a use case where we want a user to be able to download the invoice associated to the corresponding process. In this case we define a user action of type "downloadable" and generate a worker that implements a flow that generates the corresponding invoice and uploads it to KuFlow through the Rest Upload and save a document in a user action method. You can use the utility libraries available in our GitHub repository to interact with this method without the need to implement a Rest client.

Configuration:

  • Code: Unique code to identify each user action type inside the process.
  • Name: Name of the User action, this text will be used to display the action in the drop-down menu of the process detail.
  • Type: User action type: Downloadable
  • Workflow Type: Name of the Temporal Workflow implemented by the Workers.
  • Task Queue: Temporal queue used by the workflow specified.
  • Availability Expression: jq expression that is evaluated to determinate if a user action is shown to the user. More info

The defined "Downloadable" type actions will only be available to users with Process Manager permissions on the process in question.

This action allows the option of executing a new KuFlow process that is related to the process from which this action is invoked. For example, imagine that we have a process that manages the submission of applications for a grant or scholarship, and now we need to implement a new process that manages the provision of additional documentation to our process. In that case, we first define the process of providing new documentation based on our needs. Then, we go to the administration of our "grant application" process and add a new User action of type "Start related process" that allows us to invoke the newly defined process.

Configuration:

  • Code: Unique code to identify each user action type inside the process.
  • Name: Name of the user action, this text will be used to display the action in the drop-down menu of the process detail.
  • Type: User action type: Start related process
  • Related process: Process that invokes the action
  • Availability Expression: jq expression that is evaluated to determinate if a user action is shown to the user. More info

The defined "Start related process" actions will be shown in the action menu only if the user is Process Manager in the current process and has Initiator permission on the process defined in the action.

Start a workflow on demand​

This action allows to execute a workflow of type KuFlow Engine, that is, a workflow based on Temporal. This gives you a higher degree of flexibility by being able to execute additional logic outside the main order of the original workflow.

For example, we have a process that implements a budget approval flow within a company. At a certain point, we want to obtain a digital signature of the documentation added to the process. For this, the customer has developed a WorkFlow Worker in Temporal that obtains the documents of a certain process and signs them digitally. It then creates a new task in the process with the signed documents.

Configuration:

  • Code: Unique code to identify each user action type inside the process.
  • Name: Name of the user action, this text will be used to display the action in the drop-down menu of the process detail.
  • Type: Start a workflow on demand
  • Task queue: Task queue name.
  • Workflow type: Name of the Workflow implemented by the Workers.
  • Availability Expression: jq expression that is evaluated to determinate if a user action is shown to the user. More info

Create unrelated task​

Sometimes it can be interesting to have the possibility to create tasks on user demand without the need for their creation to be controlled by an underlying workflow. With this type of User action, a user with the appropriate permissions can create tasks within a process in a free way.

Let's imagine the following case study: you have a process that manages the entire cycle of a supplier's goods until they are delivered. During the life of this process, different unforeseen incidents may occur that generate documentation that must be attached to the process. For this purpose, a User action of type "Create unrelated task" is created, which allows at any time to create an task in which the user can attach the documentation related to it.

Configuration:

  • Code: Unique code to identify each user action type inside the process.
  • Name: Name of the User action, this text will be used to display the action in the drop-down menu of the process detail.
  • Type: User action type: Create unrelated task
  • Task: Task to create when the user invoke the action
  • Availability Expression: jq expression that is evaluated to determinate if a user action is shown to the user. More info

For now, the defined "Create unrelated task" actions will be shown in the action menu only if the user is Process Manager in the current process.

Availability Expression​

The availability expression allows us to choose when the user action is shown to the user. This expression will be a boolean expression written using the jq syntax and must be surrounded with the following ${ ... }.

The model passed to jq to be evaluated follows the next json schema:

{
  "$id": "https://kuflow.com/schemas/user-action",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "process": {
    "type": "object",
    "properties": {
      "state": { "enum": [ "RUNNING", "COMPLETED", "CANCELLED" ] },
      "createdAt": { "type": "string", "format": "date-time" },
      "lastModifiedAt": { "type": "string", "format": "date-time" }
    },
    "required": [ "state", "createdAt", "lastModifiedAt" ]
  },
  "tasks": {
    "type": "object",
    "additionalProperties": {
      "type": "object",
      "properties": {
        "state": { "enum": [ "READY", "CLAIMED", "COMPLETED", "CANCELLED" ] },
        "createdAt": { "type": "string", "format": "date-time" },
        "lastModifiedAt": { "type": "string", "format": "date-time" }
      },
    "required": [ "state", "createdAt", "lastModifiedAt" ]
    }
  }
}

For example, if we have this model:

{
  "process": {
    "state": "RUNNING",
    "createdAt": "2022-01-01T00:00:00Z",
    "lastModifiedAt": "2022-02-01T23:45:50Z"
  },
  "tasks": {
    "TASK_0001": {
      "state": "READY",
      "createdAt": "2022-01-01T00:05:00Z",
      "lastModifiedAt": "2022-01-01T00:05:00Z"
    }
  }
}

If the expression is:

 ${ .process.state == "RUNNING" }

Then the result will be true and the user action will be shown to the user, click here to see it in action.

But if the expression is:

 ${ .process.state == "COMPLETED" }

Then the result will be false and the user action will not be shown to the user, click here to see it in action.

Permissions​

It is possible to configure which users have the possibility to execute the defined User action. That is, the user actions will be shown only to those users who satisfy this permission restriction and of course, the availability expression if any.

Initiator​

Only the user who is listed as the initiator of the process can invoke the action.

Viewer​

Only those users who have the "Viewer" permission in the process can invoke the action.

Manager​

Only those users who have the "Manager" permission in the process can invoke the action.

Kuflow Logo
Legal
Copyright © 2024 KUFLOW, S.L.