• State Not Answered
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 1399 views
  • Users 0 members are here
Options
Related

Workflow SavedObjectProperties for multiple results (users)

infra_2020
over 2 years ago

Hi, 

I have a scheduled workflow that filters users based on a VA and then searches for users with this VA in a specific OU and then runs some PowerShell scripts for various things. 

I've used both of the commands below but neither seems to work, so i guess my question is how do I refer to "workflow Saved object properties" for multiple users without needing a For Each?

Script 1: $useremail = $workflow.SavedObjectProperties("searchforobjects").get("mail")

Error: At line: 11 char:5. Exception calling "SavedObjectProperties" with "1" argument(s): "The given key was not present in the dictionary."

Script 2: $useremail = $workflow.FoundObject("searchforobjects").get("mail")

Error: At line: 8 char:5. Exception calling "Get" with "1" argument(s): "Object reference not set to an instance of an object." 

Parents
  • 0 over 2 years ago

    One thing I do sometimes to make things easier to manage is I will create a Managed Unit populated with the search criteria that I might otherwise place into a Search Activity.  That way I can always see what objects are "in scope" if you will.

    Then, in my Scheduled Workflow, instead of using a Search Activity, the first thing I do (usually in a script) is enumerate the contents of the MU.  

    Then my script does what it needs to do with the returned objects.

    Granted, the disadvantage to this approach is that everything has to be in one script OR each script in the scheduled workflow needs to re-enumerate the MU.

    But, it does get you around the problem of not knowing what a Search Activity is (or isn't) returning.

    Food for thought.

Reply
  • 0 over 2 years ago

    One thing I do sometimes to make things easier to manage is I will create a Managed Unit populated with the search criteria that I might otherwise place into a Search Activity.  That way I can always see what objects are "in scope" if you will.

    Then, in my Scheduled Workflow, instead of using a Search Activity, the first thing I do (usually in a script) is enumerate the contents of the MU.  

    Then my script does what it needs to do with the returned objects.

    Granted, the disadvantage to this approach is that everything has to be in one script OR each script in the scheduled workflow needs to re-enumerate the MU.

    But, it does get you around the problem of not knowing what a Search Activity is (or isn't) returning.

    Food for thought.

Children
No Data