Home Advanced Request Offering

Runbook & ARO with @autocomplete

alex_kokinalex_kokin Member IT Monkey ✭

Do you have to do something different to get the Initialize Data function in orchestrator to pull from user picker fields that are configured with @autocomplete instead of using the Affected User?

I have a runbook to add a Manager to a AD User. I have a UserName and Manager user picker and cannot get the runbook to grab those.

Best Answer

  • alex_kokinalex_kokin Member IT Monkey ✭
    Accepted Answer

    Ok I had set the exclude to not equal to Created By User

Answers

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    Do you have to do something different to get the Initialize Data function in orchestrator to pull from user picker fields that are configured with @autocomplete instead of using the Affected User?

    As far as I know, you can't do this because the runbook mapping input is coming directly from SCSM. So you'd need a way to pass from SCSM into SCO. In which case it would have to be Text or an Integer per SCO's Initialize Data activity.

    BUT! That's okay here because of how you've already designed the runbook. Since you have the core concepts at play here (Get the Runbook, Get the SR, Get the User, etc. etc.) you actually just need to pull the Properties (username) from your Get User Activity.

    Another way of thinking about this, once the SR is submitted your Runbook really needs to "setup the chess board" if you will. Get the objects you are going to need to play with first (you've mostly already done this. I'd make dedicated Get Object activities for retrieving the two users in question) then using those SCSM Objects, get their Active Directory object equivalents. Then perform the actual AD update. Finally send out your notification with whatever properties you need as they now all exist upstream.

    One last thing - I'd advise against setting the Status of the SR through SCO. Just let SCSM's native out of box workflows handle this for you.

  • alex_kokinalex_kokin Member IT Monkey ✭

    Thank you, I will give this a go...

  • alex_kokinalex_kokin Member IT Monkey ✭

    Well tried it and did't work for me. Am I configuring this right?



  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited July 15

    Almost -

    But it could just be the result of Orchestrator terminology/how I phrased this above:

    • Orchestrator refers to each of these items as "Activities" which perform individual actions across systems
    • The SCSM Integration Pack has an item called "Get Activity" which retrieves things like SA, PA, MA, RA, etc. out of SCSM


  • alex_kokinalex_kokin Member IT Monkey ✭

    ok I removed those, would this be the correct config to get the username and manager inputs?


  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    Get User (which immediately follows Get User Relationship) only needs a filter of the Related Object Guid from Get User Relationship.

    And I'm not sure how you've configured it, but the Link Condition between these two activities may require some filtering so the Get User Relationship only produces a single object so that Get User object successfully runs.

  • alex_kokinalex_kokin Member IT Monkey ✭

    Ok all but the Manager is working, It keeps grabbing the same as the user. I need it to grab the manager input. What am I missing? and thank you for your help by the way, I really appreciate it.



  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited July 15

    Hey, progress is progress!

    Alright so don't forget how you configured the Request Offering (also highlighting here because I myself don't know)

    When you map selected objects in SCSM, the very last step is configuring WHICH relationship you are saving those objects to and WHICH templates (ignore the fact I have both checked and saving to the SR. I just wanted to make them not-gray in for the screenshot). I highlight this in the event that in your runbook you are perhaps looking in the wrong place?

  • alex_kokinalex_kokin Member IT Monkey ✭

    hey have I mentioned that I hate orchestrator? Manager is still grabbing the affected user info.



  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited July 15

    Alright so...

    • the Employee to change = related to the SR and the RB
    • the Manager to set = related to the SR and the RB

    The "Get Relationship" and "Get Object" combo is actually pulling both of these users. But your link condition above says "Only Get me the User in the Affected User" relationship. In which case the many (user) objects returned, becomes only a single (user) object - The Affected User. If you turn up logging on the Runbook and examine the steps you should be able to see what I'm referring to here.

    So you need another Get Relationship with a different link condition for retrieving the User that is part of the "Related Items" relationship or the "Impacted Config Items" relationship.


  • alex_kokinalex_kokin Member IT Monkey ✭

    looks like the issue now is with the link for Manager. It is getting the user input and the manager input. What do I need in there so it only grabs the manager?



  • alex_kokinalex_kokin Member IT Monkey ✭
    Accepted Answer

    Ok I had set the exclude to not equal to Created By User

  • alex_kokinalex_kokin Member IT Monkey ✭

    Crap false hope.... the get user was actually using the affected user and the manager was actually using the created by user.

    When I tested by using my own account as the user, with my managers name for the manager. It change the Manager attribute to my own name.

  • Peter_MiklianPeter_Miklian Customer Advanced IT Monkey ✭✭✭

    What about writing this whole thing in PowerShell runbook activity where you'd have complete control of what's going on and could test/debug in favorite ISE for 1 testing SR?

  • alex_kokinalex_kokin Member IT Monkey ✭

    I am open to entertaining it, how do I get the PowerShell to take the two variables that I need from RO inputs?

Sign In or Register to comment.