7 Replies Latest reply on Sep 19, 2012 3:38 PM by Jon-Eric

    Is it necessary to Claim task? Seems to work without doing so

    Jon-Eric
      I deployed a task form with the APPROVE and REJECT buttons active and assigned the task to a group. When I logon the worklist as a member of that group I see APPROVE and REJECT buttons along with CLAIM. I can click APPROVE or REJECT and see that the task seems to complete successfully.

      Since the activity of clicking CLAIM, waiting for the task list to refresh, selecting the task again then taking the appropriate action is somewhat cumbersome for these easy-to-answer tasks, is there any reason I can't just deploy my "real" task form this way? If this is acceptable I'll just instruct my users to use the action buttons (or the action menu) after selecting a task from the list and ignore CLAIM altogether.
        • 1. Re: Is it necessary to Claim task? Seems to work without doing so
          Dan Atwood
          Claim is useful when an end user is working on a work item instance and they want to make sure that no one else assigned also tries to work on the same work item instance. End users do not have to claim tasks in the Workspace, but it's useful to keep another end user from working on the same work item instance that they had already started working on.

          Once claimed, a work item instance can only be viewed and worked on by the user who claimed it and anyone assigned to the Process Owner role (it is shown in the Process Owner's "My Staff Tasks" tab - not in their "My Tasks" tab).

          The instance could be returned back into the general Department Manager queue by clicking the Actions dropdown and clicking Release.

          Dan
          1 person found this helpful
          • 2. Re: Is it necessary to Claim task? Seems to work without doing so
            Jon-Eric
            Thanks, Dan. That matches my understanding of the "Claim" process. However, my question is as follows: "Is there any consequence to not requiring users to Claim before clicking Approve or Reject?" In my case, the actions are all just that quick and often don't require research (i.e. they just click Approve or Reject). Also, the tasks are logically divided by region so each person is only looking at the tasks they "care about" so we don't really have situations where two people might want to work the same task.

            My concern is whether I could cause inconsistencies in the SOA data (or elsewhere) if users never use the Claim step. If there's no techical reason why we can't do it I may move forward but thought I'd put the question out there for others to comment on.
            • 3. Re: Is it necessary to Claim task? Seems to work without doing so
              Dan Atwood
              End users do not have to claim the work item instance task. It is seldom done and doing or not doing it won't result in any inconsistencies.

              The only issue that will result is when an end user claims the work item instance and then forgets about it. The process owner would then need to reassign it when this occurs. A timer / a deadline and an escalation would resolve this without the manager's intervention if you'd prefer.

              Dan
              • 4. Re: Is it necessary to Claim task? Seems to work without doing so
                Jon-Eric
                The point you make about claiming then forgetting is another reason I'd like to not require the Claim step. I'm glad to hear I can proceed without requiring Claim to process tasks. That will make my users very happy!
                • 5. Re: Is it necessary to Claim task? Seems to work without doing so
                  Jon-Eric
                  A consultant I worked with recently commented that if I do not require Claim then two users could act on the same task as the same time (unintentionally) and both "updates" will be processed with the first update being overwritten by the latter. Have any of you experiences this situation?

                  Also, I noticed that the task response has systemattributes/acquiredBy set to the user ID of the person who acted on the task even if they did not claim it. It's as though the claim is implied.

                  JE
                  • 6. Re: Is it necessary to Claim task? Seems to work without doing so
                    Dan Atwood
                    The way this works is that if more than one end user selects a task that has not been claimed at the same time, the first one to submit the task will be the one that gets committed.

                    While I'd agree that it's not perfect, the second one (who also had the form displayed for the task when they simultaneously selected the same task) will not be able to submit the task. The second one sees this rather cryptic message when they try to submit the form:

                    +"Insufficient privileges to access the task information for this task. User 9616d414-d4bc-4573-9d39-cc100fda7391 cannot access the task information for task: {1}. Ensure that the user has been granted appropriate privileges to access the task information for this task."+

                    This might be an argument for making the case that end users should "claim" their tasks before working on them, but for most customers this simultaneous selection of the instance by more than one end user won't happen that often and I deal with it as a training issue for end users.

                    The first one to submit wins.

                    Dan
                    1 person found this helpful
                    • 7. Re: Is it necessary to Claim task? Seems to work without doing so
                      Jon-Eric
                      Thanks, Dan. The cryptic message is unfortunate but, in our situation, it is rare that two users will want to work the same task. Each task is logically "assigned" to a user by means of the data in the task so my users are only looking for "their" tasks to process. Given that we can probably proceed without the concern of seeing this cryptic message (but at least I'll know what it's from if anyone reports seeing it!).

                      JE