How can I add the Caller field from the Incident table to the sc_task.list view

[Rick Schultz]

ServiceNow is setup so that a process user can go to "My Work" and "My Groups Work" to see all tickets assigned to them or their group.  However, it is not possible to see who the ticket is For (i.e. a field called Requested For in a Service Catalog RITM, or a field called "Caller" in an Incident) from the sc_task.list view.  Instead, the process user has to open the parent of the task in the list view.  This ultimately leads the process user not to look in one place for all their tickets. For example, if they want to see the name of the person in the Caller field of an Incident from a list view, they would have to go to the incident.list view (only being able to see Incidents, and not all tickets assigned to them.  

To try to resolve this, we tried to do dot walking from the Configure List Layout.  However, even when we try to dot walk via the Parent, we never get to the Submitter field for an Incident, or the Requested For field from a Requested Item.  We hoped that we could still add the column for the needed view, and if not applicable to the ticket, then the field would just appear blank if not associated with the row, but no such luck.

Does anyone have a work around so that all data points can be seen in one sc_task.list view for all ticket types in that view?

Thank you.

[Rajanmehta]

hi Rick,

One option I can think of is you will need to create database view combining both tables and then you will have all fields in list view.

Hope this helps.

Thanks.

Rajan 

[Stephen Sturde]

Hi Rick,

From 'sc_task', the requester's name is actually stored on the 'sc_request' table. Your will have to dotwalk to the REQ to get that value: sc_task.request.requested_for

You asked about navigating to the incident caller from the 'sc_task' table. Do you have a lot of incidents as parent records for catalog tasks? Since the user reference fields of 'caller' and 'requested_for' fields are not inherited from the 'task' table, there isn't a singular field to get them from. As @Rajanmehta stated in their response, the only way to accomplish that from the lower level would be a database view.