Converted Issues to Tasks Not Retaining Original Requestor Information on the Task

[TerryHy]

This one has me stumped for today and hoping someone can let me know what I am possibly overlooking or not thinking of. Here is the situation: A user submits a request through a request queue. The request is routed to an Agile Team (Scrum). The team manager vets the request, and then converts the request to a task, which resides in a larger bucket project. However, once the request is converted to a task, there is no information on the task that indicates who the original requestor was. The task now only indicates that the team manager is the 'requested by' person. (It does not carry over any system update information from the original request either, to show who the requestor was.) So, if this task gets reassigned to another person on the agile team, they have no way of knowing who the original requestor was, in case there is a need to follow-up with that person. Right now, the team manager leaves a note in the task update as to who the original requestor was but sometimes this gets overlooked to do. In my admin settings, I have indicated for Tasks to keep the original issue and tie its resolution to the task, and allow primary contact to have access to the task. Is there some setting that I am missing that would allow original requestor information to be carried over automatically to the task? Thanks! Terry Terry Hynd EBSCO Information Services

[VicAl]

Hi Terry, No I don't think you're missing anything. There is no Primary Contact (or equivalent field) on a Task and thus the information is not currently brought over (as far as I know). We ran into this problem a couple of years back and used our API to solve it. We have it convert the Issue to a Task and add the Primary Contact name to the beginning of the Description field so we know who the original requestor is. WF may have added something to solve this problem by now, but I haven't seen anything indicating that.

[DaleWh1]

Isn't this the converted issue originator? I noticed that column recently, and I thought that is what that set of fields was. Dale Whitchurch Arthrex Inc

[bpilarski]

You're correct,Terry. We use Converted Issue Originator Name in our custom view so the user can see who submitted the original request, but do wish that the Primary Contact name would stay with the request when converted. Barb Pilarski Pittsburgh Penguins

[DaveKo]

Hi Terry, The approach we use to ensure that the original requester name is not lost follows: 1) We add custom fields to a request custom form that is associated with the request (Custom Form type = Issue) 2) A custom field named Requestor Name is created and set to Owner.Name See image below. 3) After the Issue Custom Form is finalized we create a Project and a Task copy. This ensures that the data follows the path from request to task or request to project. Hope this helps. Dave Dave Koch

[TerryHy]

SIGH. Wish there was a way that this was done automatically out-of-the-box when converting items…but thanks to all for your comments and suggestions. Will definitely be testing the suggestions out. Terry Hynd EBSCO Information Services

[ChristineZh]

Was there ever a solution for this? We are converting requests into tasks as well and our artworkers need this info to know who to route proofs to once they're at that stage. Ideally, they'd be able to pull this info directly from the brief/custom form on the task rather than having to find it elsewhere.

[ThomGeerM]

I've just built a calculated field for the form that one of our BUs uses on both the issue and task level. It pulls the primary contact field from the converted issue for the same reasons you were asking for. Calculation is {convertedOpTask}.{owner}
Hopefully that helps 

[TheShawn]

asking solution for same issue in 2023