Quickly assigning job to Analyst (can we expose the 'Assign to Me' task in individual ROs?)
Paul_Dalkin
Member IT Monkey ✭
Hi All
Is there a way to use the [logged in user] token as the Assigned User when designing a Request Offering in the portal? When mapping user responses to SR fields, Assigned To user doesn't appear in the list of options to map to the work item.
Seems to be a limited number of uses of this token - even including the AD > User query list there appears to be no way out of the box to map the results to this field.
This is to make logging and assigning to themselves as quick as possible (at point of gathering info from customer) without a second visit to the work item to assign it to themselves once it's been saved.
If not, can we expose the Cireson portal Assign to Me as a task in specific forms?
0
Best Answers
-
Joe_Burrows
Cireson Devops Super IT Monkey ✭✭✭✭✭
Hi Paul
There is no way to expose the task (that im aware of) on the request offering form. A sugguest the analysts use the "New" drawer rather than the service catalog to raise incidents, but this would depend on process\habit.
The token itself can be used in a query result if you have it in the format of DOMAIN\USERNAME, if you set this on a property in the AD user class (A few blogs online that have solutions for setting this in the CMDB) then you can query on TOKEN: Username.
Hope that helps, let me know if you have any more questions or if I have mis-interpreted your request.
Cheers
Joe
1 -
Jeff_Lang
Customer Ninja IT Monkey ✭✭✭✭
@Paul_Dalkin
using the same idea for service requests, you could add the check box, then have the first activity on SR's as a Cireson PowerShell Activity, which checks the checkbox and then sets the assigned user if checked. thus achieving the same result without orchestrator
6
Answers
There is no way to expose the task (that im aware of) on the request offering form. A sugguest the analysts use the "New" drawer rather than the service catalog to raise incidents, but this would depend on process\habit.
The token itself can be used in a query result if you have it in the format of DOMAIN\USERNAME, if you set this on a property in the AD user class (A few blogs online that have solutions for setting this in the CMDB) then you can query on TOKEN: Username.
Hope that helps, let me know if you have any more questions or if I have mis-interpreted your request.
Cheers
Joe
I can't seem to find a reasonable solution to this (although I haven't been looking for a whole year!) would it involve extending the user class with the authoring tool or without the use of Orchestrator?
https://community.cireson.com/discussion/671/allow-agent-picker-on-service-offerings#latest
I created a custom class extension bool1 for SR and IR. Created the template in SCSM with the runbook template on the work item. Published a Request Offering based on the template. The True/False field on the portal will allow our analysts to assign it to themselves or not. I am not sure if this helps but it is working great for us. The .NET script just checks the bool1 for True/False. The labels are generic on this but it just creates the Assigned To User relationship.
Runbook:
Offering:
Alas, this is an enduring problem for us as we do not have #SCORCH installed as part of our solution. This would solve it for us if we had.
using the same idea for service requests, you could add the check box, then have the first activity on SR's as a Cireson PowerShell Activity, which checks the checkbox and then sets the assigned user if checked. thus achieving the same result without orchestrator