Automatic Personalization

Question

I found this line in BPM Server Side Scripting documentation:
If only one person is assigned to a work item, the personalization is done automatically.
Well, it isnt.
I got a work item with only one performer (set per script) and still the performer has to click a button to take over the task (which is at least annoying because one of the actions in that activity the user can decline taking over that task).

I tried setting the personalizer in BeforeStartActivity and tried to call the lockWorkitem rest-service, but the worklist is not in the right state when running this eventhandler.

Is there any way to automate the personalization?

Answer 1

Hi Jürgen,

thank you for your mentioning of this part of the documentation.

We deliberately removed this functionality, since it caused some trouble in projects. They come from the fact, that while browsing your inbox the scripts on woritems that are personalised by you are executed. In combination with the fact, that script based field manipulations are very common this leads to a even more annoying behavior.
Since after script execution fields are often set just after opening the forms, the browser prompts the user about unsaved changes, when leaving the form.

This way you can't propperly cycle throug the possible workitems anymore.

Given this behaviour, I suggest you check if automation of personalization is really desierable, in you scenario.

In parallel I will check back if and how your desired behaviour can be scripted.

Comments

Thank you, would be great if there was a script to do this.

Answer 2

Hi Jürgen,

could you please present the use-case you are working on and let us know why is such behavior desired?

Overall concept of the engine and client is to have workitems that are assigned to one or more users (performers) that then can accept the workitem to work on it, or even return it back to the previous set of performers if person cannot finish the task.
Following this concept, the personalization is deliberate action of a user (since user commits to working on the workitem) and is thus bound with user context (user clicks a button in client) and not with server context (personalization takes place in a script).

best regards
Bratislav

Comments

It is a rather simple process:
A dispatcher starts the process, assigning an object to one user. The recipient of the task / document can accept or refuse working on that document.

The problem with the personalization step ist, that there ist no way for the recipient to actively refuse working on the task, the only thing for him to do ist not click the "Aufgabe übernehmen" button. The dispatcher on the other hand will never know, if the recipient refused or if he just didn't look into his inbox.
To solve this, the available actions in the users activity are "Refuse" or "Accept". So, if the recipient is not the right one, he has to accept (personalization step) to refuse (activity) - I wouldn't want to explain that to any user.