Email notification task conflicted features

helloworld

The email notification task is conflicted with at least 2 teamsite features.
1. Work in Progress Module in CCStd
The CCStd user’s guide said that the module show the files that "You have modified and submitted, but that have not yet been approved by a reviewer."
2. Take task back in CCPro workflow
The CCPro user's guide said that "You can take back tasks after you mark them done and before the next task in the job starts."

The 2 features are not work, I think the reason is the email task running after each review task.

Have you had same problems? Please share your better approches in email notification. Thanks!

Adam Stoller

The email notification task is conflicted with at least 2 teamsite features. 1. Work in Progress Module in CCStd The CCStd user’s guide said that the module show the files that "You have modified and submitted, but that have not yet been approved by a reviewer." 2. Take task back in CCPro workflow The CCPro user's guide said that "You can take back tasks after you mark them done and before the next task in the job starts." The 2 features are not work, I think the reason is the email task running after each review task. Have you had same problems? Please share your better approches in email notification. Thanks!

Your choice of words is a bit confusing, but I'll assume that English is not your first (and perhaps not even second) language.
I presume you are talking about an email notification task that occurs after a user (author, content contributor, whatever) has indicated that they want their work reviewed - and prior to the actual reviewing taking place. Such email being sent to inform those who are responsible for reviewing work that there is something for them to review. Yes?

For item number 1 - it depends on who owns the email notification task and whether or not that task has the

lock=true

attribute set. In general, the email notification task for the above scenario should be owned by the user who is requesting the review process to start - not by the reviewers, and not by some system account. If that's handled correctly, the

lock=true

issue is a non-issue.

For item number 2 - you are correct. The take back task feature can only be used by the owner of a user-interactive task which transitioned to another user-interactive task (or an automated task that failed without a callback perhaps). In this case, a usertask is presumably followed by an externaltask to send the email, which will automatically transition to the next task (which is probably either a usertask or grouptask) - and so there is no way to retrieve the task after the email notification has occurred.

There are numerous ways in which one can code a workflow process - but it depends on requirements. You need to make sure you have a full set of requirements for the process before you design the workflow, and then you need to make sure your design supports all the requirements before you implement it (or clearly document why it will not support some requirements and get approval for such from the customer).

Since you have not completely stated your requirements here, nor whether you are actually designing a workflow or simply trying to use an OOTB workflow - there's little to go on to assist you here, other than (and I'm just thinking about this right now) using an iwat trigger script to handle sending email outside the workflow so that the transition "usertask" to "reviewtask" is direct and allows for issue #2 to be resolved (though it may not resolve issue #1? - I have not use CCStd very much)