Add Implementer to Manual Activity

Peter_Settle

I was just wondering if anyone had ever created a runbook to do this and would like to share their knowledge.

I have an issue with people creating Standard (pre-approved) Change Request records and not entering a value for the implementer into the manual activity. Thus when the CR progresses through the automatic approval stage, the manual activity does not fire off an Approved email to the implementer.

What I would like to do, with help is , insert a runbook into the CR to take the Assigned To from the CR and insert it into the Implementer in the manual activity.

This runbook would be the 1st event in the activity chain.

Is this even possible?

Adam_Dzyacky

Yes.

Get the CR, get the relationship from the CR to an Active Directory User where the Relationship Class is "Affected User", Get the Relationship between the CR and Activities (optionally filter here based on the name of the Manual Activity, the sequence of the Activity, etc.). Finally, Create a New Relationship between the user object you discovered earlier and the Manual Activity.

This relationship is Manual Activity/Active Directory User with a relationship of Assigned to User (i.e. Activity Implementer).


The basic idea is seen below:

Peter_Settle

Adam_Dzyacky  Thanks for the quick response, I will attempt to work out how to do this tomorrow and let you know how I get on. Am not the best with orchestrator but will give it a go.

Jeff_Lang

Personally we went with adding a new 'Submit' button after the save and apply at the bottom of the screen. when they click this button, it asks for the name of the implementer, and post implementation reviewer (among other names we need). We then run a Powershell Workflow in the back end that gets those names and automatically adds them to the implementation/review activities etc.

We went this way as the person putting the change request in may not always be the one to implement the change.

Until they click the Submit button we do not allow the change

Peter_Settle

Jeff_Lang  That sounds like a brilliant idea and if I had any idea of how to implement it on our system it would be fab. However I don't so looks like I wont be going with your option lol. Our Change Requestors do actually complete the Assigned To field on the CR record, they just don't transfer the info to the Activity.

Adam_Dzyacky

So once you've got the CR...



The "Get Relationship" following obtaining the "Get CR" should be looking for an Object Class of "Change Request" with an Object GUID of the CR that was obtained in the "Get CR" step, and a related class of "Active Directory User". The "Get Object" following this activity is looking for the Active Directory class with an SC Object Guid as discovered in the previous get relationship step.

So then what have I taken a screenshot of that is of significance in this whole process? The link arrow between "Get Relationship (CR to AD User)" and the "Get CR Creator". When you double click the arrow you'll open up further filtering conditions. While "Get Relationship (CR to AD User)" will return all users found on that CR (Created, Assigned, Related Config Items, etc.) we only need one to update the Implementer on the MA. This Link Property/Condition will allow us to narrow down its results. Here on the Exclude tab I've said "Relationship Class from Get Relationship CR to AD does not equal Created By User" - which is a bit of a roundabout way of saying "Only pass a single user object from these results that is the Created By User". This could easily be altered by changing it to "Assigned User"

Adam_Dzyacky

Yes.

Get the CR, get the relationship from the CR to an Active Directory User where the Relationship Class is "Affected User", Get the Relationship between the CR and Activities (optionally filter here based on the name of the Manual Activity, the sequence of the Activity, etc.). Finally, Create a New Relationship between the user object you discovered earlier and the Manual Activity.

This relationship is Manual Activity/Active Directory User with a relationship of Assigned to User (i.e. Activity Implementer).


The basic idea is seen below:

Peter_Settle

Adam_Dzyacky  Thanks for the quick response, I will attempt to work out how to do this tomorrow and let you know how I get on. Am not the best with orchestrator but will give it a go.

Jeff_Lang

Personally we went with adding a new 'Submit' button after the save and apply at the bottom of the screen. when they click this button, it asks for the name of the implementer, and post implementation reviewer (among other names we need). We then run a Powershell Workflow in the back end that gets those names and automatically adds them to the implementation/review activities etc.

We went this way as the person putting the change request in may not always be the one to implement the change.

Until they click the Submit button we do not allow the change

Peter_Settle

Jeff_Lang  That sounds like a brilliant idea and if I had any idea of how to implement it on our system it would be fab. However I don't so looks like I wont be going with your option lol. Our Change Requestors do actually complete the Assigned To field on the CR record, they just don't transfer the info to the Activity.

Peter_Settle

Adam_Dzyacky  I must be doing something wrong already, can not find Affected User , probably my mis-understanding of what I should be doing .           

Adam_Dzyacky

So once you've got the CR...



The "Get Relationship" following obtaining the "Get CR" should be looking for an Object Class of "Change Request" with an Object GUID of the CR that was obtained in the "Get CR" step, and a related class of "Active Directory User". The "Get Object" following this activity is looking for the Active Directory class with an SC Object Guid as discovered in the previous get relationship step.

So then what have I taken a screenshot of that is of significance in this whole process? The link arrow between "Get Relationship (CR to AD User)" and the "Get CR Creator". When you double click the arrow you'll open up further filtering conditions. While "Get Relationship (CR to AD User)" will return all users found on that CR (Created, Assigned, Related Config Items, etc.) we only need one to update the Implementer on the MA. This Link Property/Condition will allow us to narrow down its results. Here on the Exclude tab I've said "Relationship Class from Get Relationship CR to AD does not equal Created By User" - which is a bit of a roundabout way of saying "Only pass a single user object from these results that is the Created By User". This could easily be altered by changing it to "Assigned User"

Marek_Lefek

I have a general question, how do you organize work with request (IR, SR, CR) and activities. 
When we start with SCSM we have use and work only without Activies and all request were assigneed to proper anlitycs, but quickly we have need do add even one activity to each requests. 

When we work with activity we has a problem with assiging analitycs, couse ServiceDesk has to assing both Request and Activity to the same analitycs. This double work. 

Now we tryto use @Adam_Dzyacky runbook that will copy user to request to all activity related to the request. Is that a proper way? Mayby you have better solution? Eg. assign request to manager of analitycs assigned to Activity?

Peter_Miklian

@Peter_Settle here's discussion about how to fill activity implementers on complete: Setting "Activity Implementer" on Completion of Activity You might be interested in it, too.

@Adam_Dzyacky once again gorgeous and elegant Orchestrator solution. One note/question: you say "Get the CR, get the relationship from the CR to an Active Directory User where the Relationship Class is "Affected User", ..." but we know that CR doesn't have the Affected User only Created By by default (there are other discussions about this e.g. here). You probably meant Created By or current Assigned To user to fill into MA implementer field.

@Marek_Lefek I think there's no general rule. Every company is handling SRs + MAs its own way. Use it as it best fits your processes and analysts :)