How to monitor tardiness of late status report submittals

  • 5 April 2005
  • 4 replies
  • 3 views

Badge
Hi Everyone,

Various types of Status reports need to be submitted to a centralized office. The status reports are due regularly on a monthly basis. Some status reports are due quarterly or annually. The status report is a simple web form that designated users fill in and submit on their OWN INITIATIVE. The designated users are responsible for submitting the forms on time, regularly, for example by month-end. However, when the users are late at submitting their status reports, I would like an email to automatically be sent to the user to notify them that their status report was late and to turn in their status report as soon as possible.

How do I use K2.net monitor this process? What process can I make in order to monitor whether or not the status report was submitted on time, or late? I don't have the typical situation where a user creates a request and then submits a form to start a workflow process.

Thank you kindly,
MP

4 replies

Badge +7
In order for K2.net to be used to monitor such a scenario, you would first need to have a process started on K2.net. That process would then be able to track who has actually submitted the report, and be able to raise reminder emails to persons who have not done so.

The process could be started automatically using the Task Scheduler service in Windows. Assuming that the submission period begins on the 25th of each month, you can schedule a simple program which uses K2ROM to start this process on K2.net. In the process, you would have an activity that uses a Client Event to present work items (as well as email notifications) to the users' worklist. When the user clicks on the workitem in their worklist, the report submission form will be launched for the user to fill and submit. As this is a simultaneous activity where multiple users get to work on their work items concurrently, a Succeeding Rule will be needed to tell K2.net that it should only complete the activity and proceed to the next, when all users have made their submissions.

I hope this brief description would help to point you in the right direction. Obviously, you will need to provide more logic into the process definition to cater for escalations, or any exceptional scenarios.

Cheers!
Badge +2
Hi,

I've got a similar problem, i.e. reminders & reporting monthly/quarterly/yearly and biyearly based on a date of the "Approval step" within the process. Isn't there a way of reoccuring the process without external server side app, whether a task schedule (not really relevant to my scenario) or custom written?

Thinking quickly, I will look into maybe the code modules within K2, but then concern would be that I might flood the poor server with either datafields or coding and coding and more coding (ok, maybe latter slightly exaggerated).

Sql triggers come to mind as well, but then again imagine all the trouble you will go through setting that up.

Hoping for some useful information in the quest of "Mission impossible 3, a client with a 110% satisfaction level".

O.M.
Badge +2
Hallo,

I've solved my problem, with actually minimal advanced input from K2. It is actually very simple and my solution goes something like this:

1. Activity with Server event that calc when other activities should trigger.
2. Activity for each interval, i.e. Monthly; Quarterly; Yearly; and Biyearly with a start rule based on the initial activity's calculated values.
3. Once activity fires, then the normal steps to follow, which are unique per interval (in my case).
4. Once completed, the once a again a Server event which calculate the new start date, and after calculation, direct flow to activity in step 2 (as above) which will fire again based on the new start date.

This seems to work for me. Not sure whether this is the best practise thinking in the line of CPU usage, etc. Time will tell. But for a version 1.1.1 to the reporting/reminder problem i recon it is a good base.

PS! in my example this is a never-ending loop, which is what the above solution is doing as well, minor modifications will be required should this not be the case for your scenario.

O.M.
Badge +13
How many process instances do you expect to be "waiting" for the next kick off once you implement this solution?

Let us know 3 months from now if it causes any issues.

Reply