History for
Task
(history as of 1/1/2014 12:28:21 PM)
This page allows you to view and potentially change a single Task for the Online Mooring Task Engine (aka, the "Task Robot.") A Task is a rule that tells that the robot to do something, when something else happens, to one or more applications. To see some examples of the tasks you can create, please visit the Tasks help page.
Each task definition consists of four parts:
- GENERAL information about the page
- WHEN to perform the task
- What to DO
- Which applications to do it TO
GENERAL
- Task Name - This name is only used on the Tasks page to help you identify each task
- Disabled - If this is checked, this task will not be performed even if the Task Robot is working. This allows you to temporarily disable a task without permanently deleting the definition of the task.
WHEN
- Trigger Type (and Trigger Subtype) - A task is performed, or "triggered", when something happens. These fields allow you to specify what is going to trigger the task. Some Trigger Types require to specify a subtype, and some don't. The available Trigger Types are:
- Once, on a specified date.
- Annually, on a specified month and day.
- Monthly, on a specified day.
- On an application status change. There are two subtypes:
- When status starts. When the status of an application changes TO your specified status, the task will occur.
- When status ends. When the status of an application changes FROM your specified status to something else, the task will occur.
- On a berth status change. There are two subtypes:
- When status starts. When the status of a berth changes TO your specified status, the task will occur.
- When status ends. When the status of a berth changes FROM your specified status to something else, the task will occur.
- On a berth reservation status change. There are two subtypes:
- When status starts. When the reservation status of a berth changes TO your specified status, the task will occur.
- When status ends. When the reservation status of a berth changes FROM your specified status to something else, the task will occur.
- On payment event. There are four subtypes:
- When received. When a payment is recorded in the database, the task will occur.
- When rejected. When a payment is rejected, the task will occur. This only happens for Online payments.
- When refunded. When a payment is refunded, the task will occur. This only happens for Online payments.
- When disputed. When a payment is disputed by the payer, the task will occur. This only happens for Online payments.
- When dispute resolved. When a payment disputed with the payer is resolved, the task will occur. This only happens for Online payments.
- On application action event. There are three subtypes:
- When inserted. When the action is added to the database, the task will occur.
- When updated. When the action is changed, the task will occur.
- When deleted. When the action is deleted from the database, the task will occur.
- When effective. When the action becomes effective, the task will occur. This can be useful when there is a delay between when the action is performed, and when it becomes effective (for example, you might approve a boater to be at a berth starting the following day). Be careful with this subtype, and consider using the Application Status change / start option instead. For example, if you use this to send a notice when an applicant's reservation is effective, this will go out even if the reservation was subsequently canceled.
- When expired. When the action expires, the task will occur. Be careful with this subtype, and consider using the Application Status change / end option instead. For example, if you use this to send a notice when an application deadline has passed, this task would occur even if the application had submitted an application.
- On berth action event
- When inserted. When the action is added to the database, the task will occur.
- When updated. When the action is changed, the task will occur.
- When deleted. When the action is deleted from the database, the task will occur.
- When effective. When the action becomes effective, the task will occur. This can be useful when there is a delay between when the action is performed, and when it becomes effective (for example, you might approve a boater to be at a berth starting the following day). Be careful with this subtype, and consider using the Application Status change / start option instead. For example, if you use this to send a notice when an applicant's reservation is effective, this will go out even if the reservation was subsequently canceled.
- When expired. When the action expires, the task will occur. Be careful with this subtype, and consider using the Application Status change / end option instead. For example, if you use this to send a notice when an application deadline has passed, this task would occur even if the application had submitted an application.
- On service provider change request
Add Days -
Add Hours -
Date -
Month -
Day -
Application Type -
Action Type -
Payment Type -
Application Status -
Berth Status -
DO
- Task Type -
- From -
- To -
- Template -
- Action -
TO
- Target Type -
- Application Search -
Navigation
You get to this page by clicking on a task on the Tasks page.
Security
To view this page, you need to have Administrator View rights.
To create a new task, you need to have Administrator Add rights.
To update a task, you need to have Administrator Edit rights.
To delete a task, you need to have Administrator Delete rights.
|<< Back |