Help - Admin - Triggering

Background

Task triggering allows you to benchmark your performance and your perform a process.  Each night at 3:00 am, the system calculates the Estimated dates for each task in each open process.  If a task has no triggering information, the Estimated date will never be filled out.  If the task does have a trigger, the Estimated date will be filled out as described below.  Estimated dates can only be filled out by the system via task trigger or javascript.  Users are never allowed to enter Estimated dates.  See Help - User Guide - Tasks for more information on the difference between an Estimated, Projected an Actual date.

Triggering can be established in two places:  Design - Processes - Tasks, or in Design - Tasks.  Triggering information established in Design - Processes - Tasks overrides the triggering established in Design - Tasks.  This is useful as follows:

• In Design - Tasks, we can create a task "Acknowledgement of Work", and set it's triggering to be based upon the task "Work Order Received" + 1 day.  This means that whenever a processes include an "Acknowledgement of Work" task, by default it will be triggered to be due one day after a "Work Order Received" task.  Of course, this implies that the process must also include the "Work Order Received" task.
• In Design - Processes, we can override this default for a single process.  For example, if you have a process (Build Spacecraft) that requires extensive quality control of work orders, you might desire to allow 3 days before acknowledging a work order.  In this case, from Design > Processes > Build Spacecraft > Benchmarking, you can override the default trigger of 1 day to be three days.
• Geek Speak:  Design > Tasks updates the Task table.  Design > Processes > Benchmarking updates the ProcessTask table.  When calculating triggers, the stored procedures use ISNULL(ProcessTask.StopTrigger, Task.StopTrigger) to determine trigger dates.

Example 1: The basics.

Assume we have process that comprises five tasks, and they should be performed in the timeframes specified below:

Task Name	Trigger	Estimated	Projected	Actual
Task A	(no trigger)	Not Set	Not Set	12/15/99
Task B	within 10 days of Task A	Not Set	Not Set	Not Set
Task C	within 5 days of Task B	Not Set	Not Set	Not Set
Task D	within 8 days of Task C	Not Set	Not Set	Not Set
Task E	within 10 days of Task C	Not Set	Not Set	Not Set

When the system calculates Estimated Dates, the following steps are taken:

1. Task A:  no trigger, so the Estimated date is left alone
2. Task B:  Task A + 10, so Task B = 12/15/99 + 10 = 12/25/99
3. Task C: Task B + 5, so Task C = 12/25/99 + 5 = 12/30/99
4. Task D: Task C + 8, so Task D = 12/30/99 + 8 = 01/07/00
5. Task E: Task C + 10, so Task E = 12/30/99 + 10 = 01/09/00

Important:  note that by the time we reach step 3, Task B has already been changed from Not Set to 12/25/99.

Thus, after the calculations, we have:

Task Name	Trigger	Estimated	Projected	Actual
Task A	(no trigger)	Not Set	Not Set	12/15/99
Task B	within 10 days of Task A	12/25/99	Not Set	Not Set
Task C	within 5 days of Task B	12/30/99	Not Set	Not Set
Task D	within 8 days of Task C	01/07/00	Not Set	Not Set
Task E	within 10 days of Task C	01/09/00	Not Set	Not Set

Example 2: Overriding estimated dates with projected dates.

While benchmarking is good in theory, it rarely is accurate on a case-by-case basis.  Workflow allows users to over-ride Estimated dates by entering a Projected date.  This does NOT mean that Projected dates "erase" Estimated date; rather, if both a Projected and an Estimated date exist, we pay attention to the Projected date.  Likewise, if we have Estimated, Projected and Actual dates, the Actual date "wins".  So, from our example above, let's fill out a Projected date for Task C and see what happens:

Task Name	Trigger	Estimated	Projected	Actual
Task A	(no trigger)	Not Set	Not Set	12/15/99
Task B	within 10 days of Task A	12/25/99	Not Set	Not Set
Task C	within 5 days of Task B	12/30/99	01/02/00	Not Set
Task D	within 8 days of Task C	01/07/00	Not Set	Not Set
Task E	within 10 days of Task C	01/09/00	Not Set	Not Set

When the system calculates Estimated Dates, the following steps are taken:

1. Task A:  no trigger, so the Estimated date is left alone
2. Task B:  Task A + 10, so Task B = 12/15/99 + 10 = 12/25/99
3. Task C: Task B + 5, so Task C = 12/25/99 + 5 = 12/30/99. 
   However, C ALSO has a Projected date, which "wins" over the Estimated Date
   Thus, Tasks D and E will ignore C's Estimated date, and use the Projected Date.
4. Task D: Task C + 8, so Task D = 01/02/00 + 8 = 01/10/00
5. Task E: Task C + 10, so Task E = 01/02/00 + 10 = 01/12/00

Thus, after the calculations, we have:

Task Name	Trigger	Estimated	Projected	Actual
Task A	(no trigger)	Not Set	Not Set	12/15/99
Task B	within 10 days of Task A	12/25/99	Not Set	Not Set
Task C	within 5 days of Task B	12/30/99	01/02/00	Not Set
Task D	within 8 days of Task C	01/10/00	Not Set	Not Set
Task E	within 10 days of Task C	01/12/00	Not Set	Not Set

Rule of Thumb 1:  A task should be as close to it's trigger as possible.

There is a tendency when setting up triggers to base all triggers on one date.  People are used to thinking this way: "My process should take a month, starting with Task A.  Task B should occur within 10 days of Task A, and Task E should occur within 30 days of Task A."  While this is allowed, it is often incorrect. Here's why:

Task Name	Trigger	Estimated	Projected	Actual
Task A	(no trigger)	Not Set	Not Set	12/15/99
Task B	within 10 days of Task A	Not Set	Not Set	Not Set
Task C	within 15 days of Task A	Not Set	Not Set	Not Set
Task D	within 25 days of Task A	Not Set	Not Set	Not Set
Task E	within 30 days of Task A	Not Set	Not Set	Not Set

When the system calculates Estimated Dates, the following steps are taken:

1. Task A:  no trigger, so the Estimated date is left alone
2. Task B:  Task A + 10, so Task B = 12/15/99 + 10 = 12/25/99
3. Task C:  Task A + 15, so Task C = 12/15/99 + 15 = 12/30/99
4. Task D:  Task A + 25, so Task D = 12/15/99 + 25 = 01/09/00
5. Task E:  Task A + 30, so Task E = 12/15/99 + 30 = 01/14/00

So far this looks okay.  However, when Task C takes several more days than expected, we have:

Task Name	Trigger	Estimated	Projected	Actual
Task A	(no trigger)	Not Set	Not Set	12/15/99
Task B	within 10 days of Task A	12/25/99	Not Set	Not Set
Task C	within 15 days of Task A	12/30/99	01/10/99	Not Set
Task D	within 25 days of Task A	01/09/00	Not Set	Not Set
Task E	within 30 days of Task A	01/14/00	Not Set	Not Set

The next time Estimated dates are calculated we have:

1. Task A:  no trigger, so the Estimated date is left alone
2. Task B:  Task A + 10, so Task B = 12/15/99 + 10 = 12/25/99
3. Task C:  Task A + 15, so Task C = 12/15/99 + 15 = 12/30/99
4. Task D:  Task A + 25, so Task D = 12/15/99 + 25 = 01/09/00
5. Task E:  Task A + 30, so Task E = 12/15/99 + 30 = 01/14/00

Task Name	Trigger	Estimated	Projected	Actual
Task A	(no trigger)	Not Set	Not Set	12/15/99
Task B	within 10 days of Task A	12/25/99	Not Set	Not Set
Task C	within 15 days of Task A	12/30/99	01/10/99	Not Set
Task D	within 25 days of Task A	01/09/00	Not Set	Not Set
Task E	within 30 days of Task A	01/14/00	Not Set	Not Set

In this case, the system followed the rules specified, but the rules allow Task D to be due BEFORE Task C has actually been completed.  In the real world this may be okay, but usually it is not.

Lesson learned:  if Task D cannot be completed before Task C, then the trigger for Task D should be Task C, not Task A.

Rule of Thumb 2:  A task should come AFTER its trigger

Frequently, Key Tasks are the milestones of a process, and should server a triggers for non-key tasks.  Occasionally, there is a desire to trigger a task based on a task that will happen in the future.  For example:

Task Name	Trigger	Estimated	Projected	Actual
Task A	(no trigger)	Not Set	Not Set	12/15/99
Task B	Task A + 10 days	Not Set	Not Set	Not Set
Task C	Task D - 10 days	Not Set	Not Set	Not Set
Task D	Task B + 15 days	Not Set	Not Set	Not Set
Task E	Task D + 10 days	Not Set	Not Set	Not Set

When the system calculates Estimated Dates, the following steps are taken:

1. Task A:  no trigger, so the Estimated date is left alone
2. Task B:  Task A + 10, so Task B = 12/15/99 + 10 = 12/25/99
3. Task C:  Task D - 10, so Task C = Not Set - 10 = Not Set
4. Task D:  Task B + 15, so Task D = 12/25/99 + 15 = 01/09/00
5. Task E:  Task D + 10, so Task E = 01/09/00 + 10 = 01/19/00

Task Name	Trigger	Estimated	Projected	Actual
Task A	(no trigger)	Not Set	Not Set	12/15/99
Task B	Task A + 10 days	12/25/99	Not Set	Not Set
Task C	Task D - 10 days	Not Set	Not Set	Not Set
Task D	Task B + 15 days	01/09/00	Not Set	Not Set
Task E	Task D + 10 days	01/19/00	Not Set	Not Set

In this example, BOTH Task C and Task E are triggered by Task D.  However, Task C is left as not set because when it's trigger was calculated, Task D has not been calculated yet.  Tasks are calculated in the order that they appear in a task list.

If we step through the calculation again, the problem appears to "fix itself" as follows:

1. Task A:  no trigger, so the Estimated date is left alone
2. Task B:  Task A + 10, so Task B = 12/15/99 + 10 = 12/25/99
3. Task C:  Task D - 10, so Task C = 01/09/00 - 10 = 12/31/99
4. Task D:  Task B + 15, so Task D = 12/25/99 + 15 = 01/09/00
5. Task E:  Task D + 10, so Task E = 01/09/00 + 10 = 01/19/00

If you absolutely must have a trigger based on a future task, this problem can be circumvented by running the triggering once for each layer of "forward-looking" tasks.

Working days

Workflow allows you to ignore certain days of the week or dates when calculating triggers. If not used then a task which is due 2 days after Friday will become due on Sunday. If you enable the working days function and tell workflow that Saturday and Sunday are non-working days then it will set the due date to Tuesday, 2 working days after Friday. To enable this functionality set the WORKDAYS system default to ON and set the WORKMON, WORKTUE, WORKWED, WORKTHU, WORKFRI, WORKSAT & WORKSUN to 'ON' or 'OFF', 'ON' meaning thats a normal working day, 'OFF' meaning you want triggering to skip over that day of the week

You may also ask workflow to ignore certain dates like holidays. To enable this functionality, set the WORKCALENDAR system default to 'ON' and enter the non-working dates in the calendar on the Admin menu page.

Welcome | Users | Business | Managers | Documents | Lookup | Administrators