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.

• 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 five 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 (such as an installation, inspection, etc.).  There are five 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 service provider change request.  There are four subtypes:
    • When requested.  When this change request is submitted by the inspector, this task will occur.
    • When approved.  When the change request is approved, this task will occur.
    • When rejected.  When the change request is rejected, this task will occur.
    • When deleted.  If the change request is deleted, this task will occur.
• Add Days -  In some cases you may want to have the task run earlier or later than the date on the trigger.  Using this field you can make the task happen a specified number of days earlier or later than the date specified by the trigger type/subtype.  If you want the task to run later, enter how many days later you want the task to run.  If you want the task to run earlier, enter how many days earlier you want the task to run by entering a negative number.  For example, if you wanted to send out a reminder notice to a boater 7 days before a renewal deadline, you would pick the application status / when status ends trigger type/subtype, and then add -7 days.
• Add Hours -  In some cases you may want to have the task run earlier or later than the date on the trigger.  Using this field you can make the task happen a specified number of hours earlier or later than the date/time specified by the trigger type/subtype.  If you want the task to run later, enter how many hours later you want the task to run.  If you want the task to run earlier, enter how many hours earlier you want the task to run by entering a negative number.  For example, if you wanted to send out a thank you notice to a boater 1 hour after their reservation has ended, you would pick the application status / when status ends trigger type/subtype, and then add 1 hour.  You can specify both the Add Days and Add Hours fields if desired.
• Date - If you picked the trigger type to run the task once, enter the date when you want the task to run.
• Month -  If you picked the trigger type to run the task annually, enter the month when you want the task to run.
• Day -  If you picked the trigger type to run the task annually or monthly, enter the day of the month when you want the task to run.  If you want the task to run monthly, you can pick and day between the 1st and the 28th (since February only has 28 days).
• Application Type - This field appears for certain trigger types, and allow you to specify which application types this task applies to.   If you leave it blank, it will apply to all of your application types.
• Action Type -  This field appears for certain trigger types, and allows you to specify the action type that this applies to.  For example, this lets you specify that the task only applies to Renewal Submitted actions.
• Payment Type - This field appears for the payment trigger type, and allows you to specify which types of payments this task applies to.  If you leave it blank, it will apply to all payment types.
• Application Status - This field appears for the application status trigger type, and allows you to specify which application status this task applies to.  If you leave it blank, it will apply to all application statuses.
• Berth Status - This field appears for the berth status and berth reservation status trigger type, and allows you to specify which berth status this task applies to.  If you leave it blank, it will apply to all berth statuses.

• Task Type -  This lets you define what you want to happen when this task is triggered.  The options are:
  • Send an e-mail
  • Send a text
  • Add an action
• From - If you pick the option to send a communication, you can specify who the communication should come from.  You can pick pre-defined values: from the provider (you), from the applicant, or from the inspector.  You can also specify any other value that you like.  
• To  - If you pick the option to send a communication, you can specify who the communication should be sent to.  You can pick pre-defined values: from the provider (you), from the applicant, or from the inspector.  You can also specify any other value that you like.  You can specify multiple e-mail addresses, separated by semicolons.
• Template - If you pick the option to send a communication, you specify which communication template you want to send.
• Action - If you pick the option to add an action, you 

• Target Type -
• Application Search -

|<< Back |