nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

multiple reviewers

lucille_arkenst

After much reading I have a better understanding but I am still a bit confused. I have two simple questions:

1. Can you start an advanced workflow upon upload of a document to a space? (This is the basis of simple workflow, but I want to start advanced workflow like this)

2. When doing parallel review, is there a way to get three reviewers to look at the document? In other words, I want to assign the group but I don't want it to disappear from the other people in the groups' task list.

Thanks in advance

Find more posts tagged with

Comments

invictus9

I have played only a little bit with this.

1) You can start an advanced work flow on incoming documents, but there are several parameters that have to be provided, specifically the list of reviewers, the percentage approval required and the due date. You can provide all of that from a Javascript attached as an action to the space, that is triggered on INCOMING documents.

You can approach the list of reviewers a couple of ways. The first way I thought of was to create a custom aspect which was a list of usernames and attach this aspect to the space. The second way might be more natural, and that is to have the list of people invited explicitly as collaborators (or consumers) to the space. Either list can be queried by your script.

The percentage approval would either default to 50% (or something else you put in the script), or you add a custom aspect to the space with the parameter attached.

Similarly, for the due date, you can decide not to set one, or you can hard code the due date or a duration into your script. Alternatively, create a custom aspect that specifies either the duration or a date and add it to the folder.

2) Parallel reviews come in 3 types: parallel list, parallel group, and parallel pooled. I think you are referring to parallel pooled in your example, as the former two will keep the task on everybody's screen.

lucille_arkenst

Thank you, Invictus. I do want to keep the task on everybody's screen. Imagine if I send an email out to several people to review the document. And then once x out of y people approve it, the document moves on to their supervisor for final approval.

sethatrothbury

Then you'd want to use Invictus's option 1. Have a look at the submit_processdefinition.xml it allows for either a serial or parallel list review, when it's parallel it assigns the task to everyone in the assignees list and then waits for a certain number of reviewers to approve.

lucille_arkenst

Thank you, Seth. I appreciate your explaining the part about when it's parallel it assigns the task to everyone in the assignees list. I did look at submit_processdefinition.xml following our previous conversation, and I have to admit I was having a bit of trouble understanding it. I found it difficult to follow all the transitions and keep track of their intent. If you were me, how would you go about following the flow? I tried plugging the code into the Eclipse jBPM plugin, but the diagram that came up… let's put it this way… the tool didn't understand the code either! I printed the code, wrote numbers in the margins, and I still got lost. (You can imagine how overwhelmed I feel attempting to write one of these things myself.) Could you offer a recommendation?

Thanks again.

sethatrothbury

Sorry Lucille, I totally forgot that there is a "parallel only" version of the submit_processdefinition.xml. Look at the "parallelreview_processdefinition.xml" that is in the same folder. It has the stripped down version of a parallel list review.

That workflow asks you for a certain percentage as you start it and then pushes the review task off to everyone in the bpm_assignees list using the ForEachFork. As each reviewer approves or rejects, they are added to the total approvalCount. Once everyone has reviewed, the workflow checks to see if that wf_requiredPercentage has been met to deem the workflow Approved or Rejected.

lucille_arkenst

OK thanks. I'm going to read though this and look up everything I don't understand. Now, is there a book or a reference out there that just explains it all? For example, I'm reading through this and I see <start-state name="start">… OK I get that… But then it instantiates a "task"… only to "transition" to "startreview". Why do we need a task? Why not just transition to startreview? Is there anything out there that just explains how to write these? Or is the correct way to go about this to look at the code and look up each item that you don't understand?

invictus9

There is a decent tutorial on jBPM at jboss.com; I found other sites with tutorials as well – Google is your friend

http://www.jboss.com/products/jbpm/docs/tutorial/
http://www.mastertheboss.com/en/jbpm/51-jbpm-tutorial-part-1.html