Workflow Sample: Smooth Reporting by Telecommuters

Instead of having telecommuters access the company's server and create an "opening" in the firewall all the time, it's better to keep a certain amount of data "on the Cloud" to reduce repeated access. Remember, when you prioritize everything as "important data," you may not be able to protect the truly pivotal stuff. (Ancient Japanese castles during the Sengoku period had inner and outer moats, and apparently castles with "wide inner moats" cost a lot more for security!)

Today's workflow is a spin-off of yesterday's "Of course! Approving Request Of Telecommuting Should Be Through Cloud Computing." The workflow is for registering work schedules in batch—because work schedules are something you can keep within the outer moat.

By the way, it's convenient to be able to register your work schedule in batch, but unlike individual workflows it may be harder to report completed work within a sequence. (Or so it seems.) In this case, you can just separate the "registering workflow" and "reporting workflow" in a [1:n] relation.

<Tasks>
1. Request, 2. Approval, 3. Action against Send Back

[Telecommuting <Register Schedule in Batch>:
Message Throwing Intermediate Event (HTTP) Setting]

Title (Ex: May 16 Ichiro Sato (Name will be inserted automatically)

<<Telecommuting days>>

Approver (user)
Telecommuter (user)
Telecommuting 1 (date)
Telecommuting 2 (date)
Telecommuting 3 (date)
Telecommuting 4 (date)
Telecommuting 5 (date)

<<Approver control>>

Approve? (Select: OK / No)
Correspondence (discussion)

With the above workflow, you can register a whole week of telecommuting. (5 days)
For all the days registered, one "reporting" process is initiated (below), so the telecommuter can report work for everyday he/she works.

<Tasks>
1. Report, 1b. Report, 2. Confirm, 3. Respond to Questions