1 of 1 people found this helpful
I have tried, and it is a bit tricky. If you do not upload an attachment, it evaluates, and always evaluates to true if there is nothing there, since technically ALL attachments are uploaded = true, since there are none uploaded. For instance, I had a wait for child block for a purchase order to have status of approved. But if the task to create the PO was complete before the PO was created, the wait for child block would go right through to success, since it did wait till...all...PO's had the status of approved...since there were none. One possibility would be to have a flag created in the SR, and when something gets attached, have that SR get flagged as containing an attachment, and then replace the "Wait for child" block with a standard Wait block. But they are indeed tricky.
Hope that helps.
I am trying to understand. When is the attachment being added to the Service Request? Is it being added after the submission by the Requester? If it is being added by the Requester up front why are you waiting?
Sorry, I am just a bit confused, as is usually the case. :-)
I'm using the wait for child successfully in response to the closure of tasks e.g. wait for all 19 tasks to be completed, rejected or other and then progress to an update block.
In adition to the above I assume you are only referring to attachments being added to the attachments tab and not those added into notes & emails?
It's good to hear that other people have had a similar issue. It is quite a strange one. It sounds as though we may need to go down the route of adding a flag or counter of attachments and use the standard Wait Block.
Thanks for your help
Due to the nature of the request we do not want to use the Attachment Form Control. The requestor is required to upload an attachment in order to progress the request. Some requestors may already know that this is a requirement so will do it as soon as the request is logged, however others will need to go away and download the file etc etc so it may take a day or two.
Have you done anything like this before?
Yes this particular issue is with attachments manually added to the attachments tab. We're only using service requests in quite a limited way at the moment but are aiming to launch the service catalog soon. Currently we have had no call to save attachments from emails sent into the service request. I'm assuming it works in the same way as Incident in that you must save the attachment and add it manually?
It's interesting that you are using Wait for Child to manage Tasks. We rely on the Task exits for this. Do you do this for any particular reason? Have you had issues with Tasks?
I've got about 200 request offerigns setup albeit most are quite simple. More recently I've built more complex workflows but our design has an attachment field in the form which puts the attachments into the attachment tab on initial submission. I've then customised the self service design and basically allowed the customer to add more attachments through self service. It is the same as incidents though where a user then logs in and add more atatchments from a ticket management pov.
The reason I have it designed this way is because a team had a requirement for an approval to be granted and then 19 tasks are setup which are assigned to individual people. There is no actual owner of the ticket just a team ownership. For this reason the ticket would have sat in limbo so I exited into a join, then into a wait for child with parameters to wait for all tasks to be closed in some way and then the final steps were to auto fulfil the ticket with notes, etc.
2 of 2 people found this helpful
I had this kind of issue with request offerings and tasks.
In the case where the workflow would create tasks, Wit for child would work fine.
But if some tasks are created manually (or not created directly within the worklow), this would make the system never detect those manually created ones and make your wait for child block wait until timeout.
In your specif situation Louise, I would try to create a specific object (like Attachment added, with a status or boolean field), insert it within the workflow with an insert child block, then update it when an attchment is added.
Then set up your wait for child block with a condition on that object and the triggering field.
I'm not sure we have any offerings that would need this but will bear it in mind going forward.
It sounds as though the way to go is to create a separate field to track if / how many attachments are added and use that as the criteria for a Wait block.
Thanks very much for your help.
This is a very good point - I have not taken account of manually added tasks and the closure of the request is based purely on the workflow tasks. A blind spot that I had not considered!