I want to build a report which shows who is current assignee of the task and who was previous owner of the task.

Are you using the out of the box reassign, Ambrish?

I was planning to use task services shared component to build a reassign functionality process and wanted to report on the data.

It doesn't look like Lizzie has updated that since 2012 - I haven't tried it on recent versions. But, based on what I remember, it actually cancels the task and creates a new one when you reassign it via the plugin; so you could include cancelled tasks in your report, perhaps.

I do remember that since it essentially cancels and recreates the task, the "clock" on the task is restarted. So, be careful using it if the task needs to be completed within a certain timeframe.

That being said, you may be better off creating an exception flow that can do a database write prior to reassigning anyway, so you can keep that information for a longer time.

@ambrishs I don't think there is a capability in the product as of now to report on the previous owner of the task, rather a current owner can be shown. And this capability can't be provided by us if we go with the OOTB 'Reassign task' option(which is present in the left hand pane of 'Tasks' tab when a Task is accessed). Because there isn't a way to capture the 'Reassign task' event.

Previous owner can be captured if Reassign Task functionality is provided by us on the Form (Let's say a button called 'Reassign Task' is added on the form, and clicking this button will surface the reassign options and thereby save the necessary task attributes in the database) or on the Task Report. But this way, we are re-writing the Task Reassign functionality and also we are delegating some logic to database which might seem cumbersome when compared to OOTB process reporting. We have to bear in mind that, we need to disable OOTB 'Reassign Task' functionality for this, as performing it skips the updates which we have to do upon reassigning.

Those are all valid points, @sikhivahans, but the smart service Ambrish is referring to allows an external party to reassign a task. For instance, someone goes home sick, so the manager wants to reassign that individual's tasks to someone else.

Other than the smart service, you could use exception flow that is triggered by a variable getting updated via a process-to-process message. It would essentially do the same thing as the smart service, but you would have more control over the process steps prior to the task getting re-assigned.

Hi, the way we handled similar requirement was build an Appian plugin and expose the API via smartService. The details on the task details is available at below link but for the previous owners on the task it may be something that you have to maintain at persistent layer (database).
forum.appian.com/.../

@staceyw I understood that, but what I am trying to say is, the previous owner (as coined by @ambrishs) can be captured only when we make use of the Reassign Task built by us and the value holds valid only when OOTB 'Reassign Task' is disabled.

For instance, let's say we have reassigned a task using the functionality which is built by us by using the Reassign Task smart service. By doing so the previous task owner can be easily captured. Now let's say the user who is performing the task now, did some work and reassigned the task by using the OOTB 'Reassign Task' functionality. In this case if we go back to the Reassign Task functionality built by us, it still shows the previous owner as the person which is captured when we interacted with the functionality (but not the latest) and it definitely misses the person who has just now done some work and reassigned it.

Also may I please know if your idea is to trigger the exception also when the OOTB 'Reassign Task' is used?

No, the trigger would come from a separate action, not the OOTB Reassign Task, @sikhivahans. You are right to point out that the OOTB Reassign Task should be disabled regardless of how Ambrish decides to design the functionality; I misunderstood that was the crux of your statement in your first comment.

@staceyw No problem, just wanted to make it clear re the effect of OOTB 'Reassign Task' in the current implementation.