View submitted tasks is too technical for end-user to consume... This has come up many times before.
But here's a simplified view of the actual service request screen (below), it's listed within the services category that doesn't require access to view submitted tasks screen (above)
The crux of the issue is the disconnect between end user vs. service desk personnel or system managers roles within the UI. A simplified interface is needed to display service requests status (above), searchable by unique id of the service and mutually exclusive to the view submitted tasks section, within the UI.
submitted task id is too complicated, it is a time consuming support nightmare for end users and help desk staff because all the screens are too technical.
Currently Identity manager doesn't provide human readable tracking numbers for service requests, making supporting end users cumbersome because they have no 8 digit service request tracking number.
Essentially anyone tasked with supporting workflow delays or escalations with service requests will likely want to have access to view submitted tasks, however end users should only have access to the simplified request status, provided within the services module category. Also providing a human readable tracking number for the request is needed, as well as a search screen for unique service request ids. Task session id is unacceptable because it's unnecessarily complicated and long. Having a simple interface to search service requests by 8 digit tracking number, with a simplified view of the status of the request, will decrease help-desk calls and simplify the entire process for end users. especially in deployments strictly utilizing identity manager for service request.
Linking service request screens to view submitted tasks, for service fulfillment task, will provide a holistic understanding of the entire submission and the state all things tied to it within the database, but a simplified tracking ID (unique_name) can now be utilized to track the request and link back to details about the task, if necessary. Without this linkage documented within a report, it will be impossible for system managers to link service fulfillment tasks with the actual services requested, via the IdM UI, without looking at the database. The only way to correlate this linkage currently is via the identity manager db object store, using the below query, to get the unique service requests tied to the task id;
(Replace TASKSESSIONID with the service fulfillment tasksessionid to discover the service’s unique_name)
Select UNIQUE_NAME, TAG from [DB].[dbo].[FWSERVICE] where FRIENDLYNAME like '%' + (SELECT right((SELECT description FROM [DB].[dbo].[tasksession12_5] where tasksessionid='TASKSESSIONID’),CHARINDEX(',',(SELECT description FROM [DB].[dbo].[tasksession12_5] where tasksessionid='TASKSESSIONID’))-1)) + '%'
**above query demonstrates linkage between the task submitted within MyAccess and the actual unique service / application request, enabling access to all the particulars about the request, including lah entered during the service request.