Activities and tasks

Together with casetypes, activities are at the heart of the applications you build with Grexx Platform. Casetypes represent the types of objects and processes that you handle via your application, such as customers, products, dispatching orders, or adding users.

You add activities to casetypes to define what you can do with cases of each type. Activities can be initiated and completed by your application users or they can be executed automatically as a result of other events taking place in your application.

You can use activities to:

• Set or change the attributes of an existing case. For this, you use a form activity.
• Create new cases, such as adding a new product or order, or sending an email. For this, you use a casetype activity.
• Prompt users to do things at specific points in time or configure your application to perform tasks automatically at specific times. For this, you use an event activity.
• Close or reopen cases. For this you use a process block activity.

You can also chain multiple activities together to create more sophisticated functionality. For example, in a system for managing employee expenses, you might add triggers both to send emails automatically when claims are approved and to set deadlines for supplying more information if the claim is queried.

Tip:

As with casetypes, you define activities in your Grexx Studio and users perform those activities in your application (in the Development, Testing, Acceptance, or Production environment). When an activity is generated for a particular case in your application it is referred to as a Task.

Types of activity

There are four main types of activity in Grexx Platform, each suited to different use cases.

Form activities

You can use form activities to set or edit the attributes of an existing case. For example, if you want your application users to be able to edit the details of existing customers, you can use a form activity to specify the form you want to use and to control which users can view and submit it.

Each form activity is associated with a form belonging to the same casetype. The form defines the GUI that users fill out and submit when they perform the activity. A form can contain fields for the case attributes that you want to set or edit, and additional fields that you can use to implement conditional logic within the form (such as a gating question to control whether certain attribute fields are displayed).

You can add mappings to a form activity to populate some or all of the fields on the form automatically. For form activities that users perform manually, you can use mappings to pre-populate fields with data and either make the fields editable or read-only.

You can also use triggers to execute and submit form activities automatically (i.e. without any user input). For example, in an ecommerce application you might want to record a courier's tracking number against each order case when the order is dispatched, without requiring a user to enter the data manually. When performing form activities automatically, mappings allow you to populate the form fields with data from the case or an inline template, among other sources.

For information about configuring form activities, see Edit case details.

Casetype activities

Casetype activities allow you to add new cases to your application. For example, you can use casetype activities to create new customers or products, send an email, or invite a user.

You can add casetype activities to both page casetypes (such as your application's homepage) and to standard casetypes. For example, you might add an activity to the homepage so that users can add new customers to your application. Equally, you might add a Create expense claim activity to an Employee casetype so that users can create a new Claim case for existing employees.

By adding mappings to a casetype activity you can populate some of the details of the new case automatically and reduce the need for manual data entry. For example, you might want to populate a new expense claim with the employee's case ID and other details.

You can also use triggers to perform a casetype activity automatically. For example, you might want to create a Send welcome email case each time a new customer is added to your system. Rather than requiring users to initiate the activity by clicking a button in the application, you can trigger the Send welcome email casetype activity automatically each time the manual Create customer activity is performed by a user.

For information about configuring casetype activities, see Add cases.

Event activities

Event activities are performed automatically at a specific point in time. There are four types of event activity:

• Deadline: Use this option to define what happens if the deadline of another activity (such as a form activity or a casetype activity) is reached before that activity has been performed. For example, you could configure a deadline activity to send an email to remind the assignee to complete the required activity.
• Login: Use this option to trigger one or more activities each time a user logs in to your application. Note that login activities are only available on the User casetype.
• Timed: Use this option to define what happens at a particular date and time. For example, you could configure a timed activity to generate a task for a customer's account manager a number of weeks before their contract renewal date.
• Queued task: Use this option to force automated activities to be performed in a particular order. This is an advanced option and is useful when restructuring casetypes and migrating data.

Event activities are designed to be used in conjunction with activities of other types. You can use event activities to chain multiple activities together into a sequence of jobs. For example, in the Studio tutorial, you set a deadline for uploading new employees' contracts and used a deadline activity to trigger an email reminder activity, which in turn created a new Send email case.

For information about configuring event activities, see Chain activities together and the associated guides.

Process block activities

Process block activities are performed automatically as soon as they have been triggered. There are several types of process block activity:

• Dummy: Use this option to configure logic that determines when one or more activities run separately from the particular form, casetype, or event activity. This is useful if you want to reuse logic to create different sequences of activities. Separating logic into process block activities also makes it easier to manage and debug more complex sequences. For information about creating a sequence of activities, see Chain activities together.
• Close case: Use this option to close a case. For example, you might add an activity to close a claim automatically once it has been paid or rejected. Note that cases can remain open indefinitely.
• Reopen case: Use this option to reopen a closed case. For example, you may want to provide the option to reopen a claim if the decision is appealed or to reinstate an inactive user.
• Recalculate: This is useful for casetypes that have computed attributes.
• AND, OR, and N-Join: Use these options to require one or more triggers to be completed before starting the current activity. For more information, see Trigger one activity from multiple parents.

Features of activities

Lifecycle

All activities go through a series of stages from when the activity is first initiated or triggered to when the activity is completed. When you configure an activity, you can apply mappings, triggers and other logic to one of more of these stages:

• On trigger: This is the point when an activity is generated by another activity automatically. This includes a mandatory task that is initiated by another activity (using an Execute trigger) or a deadline event that is generated (using an Execute and submit trigger) whenever an activity with a deadline is initiated. For example, in the Studio tutorial, we added a mandatory Upload employment contract activity to the Employee casetype and triggered it when an employee was added. Each time a new employee was added, the Upload employment contract mandatory task was created, and that task remained in the Trigger stage until a user opened the form to start the activity.
• On start: The point when a user begins the task. You can only configure rules for the Start stage for form and casetype activities. Usually this stage begins when a user clicks a button in the application and involves a form being displayed for the user to complete. You can configure mappings to populate some of the form fields automatically. If no further user input is required, you can choose to populate all fields automatically and hide the form completely. You can also use this stage to trigger other activities each time an activity is started, regardless of whether it is submitted.
• On submit: The point when a user submits the form to complete the task. You can only configure rules for the Submit stage for casetype activities. You can use mappings to set attribute values on the new case - either as part of a manual process (whereby the user may be able to view and edit the values) or when creating new cases automatically. You can also use this stage to trigger other activities each time a new case is created.
• When done: For form, event, and process block activities, this stage indicates that all processing from previous stages is complete. For example, when a form activity is completed, all data from the form fields is mapped to case attributes by default.
  For casetype activities this stage is reached when the case that was created by the activity is closed. For example, you might use a casetype activity to initiate a process, such as performing an annual review. When the process is completed and you close the Perform annual review case, you could add a mapping to record the date the case was closed on the associated Employee case and/or trigger a timed event to remind the manager to set up the next annual review in 12 months' time.

Mappings

Mappings allow you to populate data for activities automatically. Using mappings avoids the need to re-enter data manually, thereby reducing the room for error, saving time, and ensuring consistency.

You can add mappings to each stage of an activity. For example, you can use mappings to populate fields on a Start <casetype> form with data from the parent case, such as recording the customer case ID when placing a new order.

When configuring a mapping:

• To indicates the form field or case attribute that will be populated.
• From indicates the source of the data. This could be the parent case, a dataset, a specific value, or another case that is related to the parent case.

For information about when to use mappings, see Populate case details automatically.

Triggers

You can use triggers to control or make changes to other activities automatically. Triggers allow you to chain activities together into a sequence of steps. Depending on the activity, some steps may require user input while others may be completed by the system automatically. You can add triggers to different stages of the activity lifecycle, according to what you want to achieve.

For example, each time a new product is added to your application, you may want to generate an activity to require users to upload images. To achieve this, you could add an Execute trigger to the When done stage of the Start Product activity to generate the mandatory Upload images task. If you set a deadline for uploading the images, you could use an Execute and submit trigger and perform a Send email activity automatically if the deadline is reached but the Upload images task has not been performed.

For information about creating a sequence of activities, see Chain activities together.

Logic rules

In addition to mappings and triggers, you can configure conditional logic for each stage of an activity using standard logical operators.

For example, if you are building an application to process employee expense claims, you may want to process claims under a certain value automatically and require manual review of claims over that threshold. You can configure this by adding If... then... else... logic, so that claims with a value below the threshold automatically execute the next activity, and everything else triggers an activity that requires user input.

For information about using adding conditions to activities, see Apply conditional logic to activities.

Rights

Rights define whether users in a particular role are required to perform an activity (i.e. the activity is mandatory for them) or whether they can choose to do so (i.e. the activity is optional for them).

If a user role is granted the Request right, the activity is optional. This means that users in the selected role can initiate the activity from the application, providing a suitable widget has been added to a page or view. For example, to allow employees to open expense claims, you would grant employees the request right on a Create claim activity and include a button to initiate the activity from the application homepage.

If a user role is granted the Execute right, the activity is mandatory. Mandatory activities are designed to be triggered by another activity. For example, you might have an optional Add customer casetype activity so that users can add new customers as required, and use this to trigger a Set up onboarding call activity. The trigger ensures the mandatory task is generated each time a new Customer case is created. Granting users in the Customer service role Execute rights on the activity ensures that those users can only perform the activity after it has been generated by the system.

For information about triggering one activity from another, see Chain activities together. For information about adding uses to roles, see Manage users and permissions.

Next steps

Before starting to develop your application with Grexx Platform, it is worth taking the time to consider the activities you will need to add to your casetypes and how to break them down into reusable components. For more information see Design your application.