Free cookie consent management tool by TermsFeed

Adding a New Task Type

This content applies solely to Connected Onboarding, which must be purchased separately from the Appian base platform. This content was written for Appian 23.3 and may not reflect the interfaces or functionality of other Appian versions.

Adding a new task type

Task types control what type of interface the user will see when completing a task. In order to add a new custom user input task, integration, or kick off an RPA process, you need to add a new task type. Once added, the new task type will be able to added to workflow templates and . The task types are stored in the AS_IO_R_TASK_BEHAVIOR_TYPE table. In order to add a new task type, you first need to add it to this table.

To add a new task type to the table:

  1. Insert a new row into the AS_IO_R_TASK_BEHAVIOR_TYPE table.
  2. Update each column with the following information.
    • BEHAVIOR_TYPE_CODE: The behavior type of the task. Valid values:
      • AUTOMATED The task does not have a front-end interface associated with it, and it will be automatically completed by the system via a process model. For example, the Consolidated Screening Check task.
      • DATA_ENTRY The task has a related user interface for data entry. For example, the Document Upload task.
      • CHECKBOX The tasks can be completed by selecting a box. For example, a Confirmation task will require the user to affirm that the task is completed before submission.
        • Note: You probably won't have to create another task type with CHECKBOX for the BEHAVIOR_TYPE_CODE.
    • BEHAVIOR_DISPLAY_NAME - A unique name for the new task type that displays to end users. Each BEHAVIOR_SUBTYPE_CODE should have a unique display name.
    • CREATED_BY: Your Appian username.
    • CREATED_DATETIME: The current timestamp, in the format YYYY-MM-DD HH:MM:SS.
    • MODIFIED_BY: Your Appian username.
    • MODIFIED_DATETIME: The current timestamp, in the format YYYY-MM-DD HH:MM:SS.
    • BEHAVIOR_SUBTYPE_CODE - A unique code for the new task type.
    • CONFIGURATION_LEVEL_CODE - Determines how tasks are added to an Onboarding by users. See the following table for a breakdown of where these tasks are available. Valid values: SYSTEM, TEMPLATE, PROCESS_SETUP, and AD_HOC.
    • ICON: The styled icon to display in the task grid. For example, thumbs-o-up.
    • COLOR: The hex color for the icon. For example, #F96502.

task_types.jpg

SYSTEM

What it is

This type of configuration is generally for automated tasks that can only be kicked off from a process model.

When you would use it

You would use this type of task when:

  • You want the task to be automatically kicked off using a process model.

And when an end user would never need to add this type of task:

  • To the task library in FS Settings.
  • As a custom task when completing the Process Setup task.
  • As a custom task from the Home page or as a related action.

Example

After a user creates a new Onboarding, the task is automatically kicked off using a process model. However, end users do not have access to add this type of task when adding a default task to the task library or when adding a custom task to an Onboarding.

TEMPLATE

What it is

This type of configuration is for tasks that you want to be available to FS Settings users for use in Onboarding templates, but you don't want to be available to regular users when adding a custom task to an Onboarding.

When you would use it

You would use this type of task when you want the task:

  • To be automatically kicked off using a process model.
  • To be added to the task library in FS Settings.

And when an end user would never need to add this type of task:

  • As a custom task when completing the process setup task.
  • As a custom task from the Home page or as a related action.

Example

Out of the box, there are no tasks with this configuration.

AD_HOC

What it is

This type of configuration is for tasks that would be sent out by client onboarders from the Home page or as a related action. When sent out like this, the onboarder is kicking off the task right away, rather than waiting for the task to be kicked off by a precedent or a process model.

When you would use it

You would use this type of task when you want the task:

  • To be automatically kicked off using a process model.
  • To be added to the task library in FS Settings.
  • To be available as a custom task when completing the Process Setup task.
  • To be available as a custom task from the Home page or as a related action.

Example

Review task - Can be added as a new task in the task library, as a custom task during the Process Setup task, or as a custom task from the Onboarding record.

Feedback