• State Not Answered
  • Replies 7 replies
  • Subscribers 63 subscribers
  • Views 1631 views
  • Users 0 members are here
Options
Related

Workflow to get membership of multiple groups

jody gilbert
11 months ago

I'd like to create a workflow that starts when a member is removed from any group with an admincount of 1.

The reason for this is I want to check if the removed member is a member of any other groups with an admincount of 1, if the member isn't I need to update the admincount to 0 on the user account.

I know how to configure the initial workflow to detect the changes, but I cannot work out how I check the memberOf field against multiple groups without doing a lot of copy/paste for each group.  I'd prefer not to manually add the groups as our groups get updated with admincount on a regular basis so I need a way to find all the groups and check the membership accordingly.

I can do this easily in code but I cannot get my head around how to do this in a workflow.  Any suggestions would be much appreciated.

I must admit, I find it considerably easier to write scripts and use the workflows to trigger them but I'm not sure if that's going to cause me issues elsewhere in the future, so I'm trying to use the workflow logic.

Parents
  • 0 11 months ago

    I would suggest you create a Managed Unit who's membership rule gathers together your "admincount 1" groups

    Each time your workflow fires, enumerate the contents of that MU (from a script) and store in a variable (array).

    Iterate through the removed group members list from the $Request and check each removed member's memberships to see if they are a member of any of your "admincount 1" groups.

    'Hope that's a good starting point for your approach?

  • 0 9 months ago in reply to JohnnyQuest

    Thanks for all the responses and apologies for not responding sooner.

    I kept everything in a script that a workflow triggers, as it was simpler for me to implement that way.

    It does make me wonder though, almost everything I see in a workflow I find much simpler to implement with PowerShell so I tend to create a script and use a workflow to trigger them on a scheduled basis.

    The only exception is for tracking change to objects/properties, although for that I've found policy scripts easier.

    Are there any issues with using Workflows to only schedule scripts?

Reply
  • 0 9 months ago in reply to JohnnyQuest

    Thanks for all the responses and apologies for not responding sooner.

    I kept everything in a script that a workflow triggers, as it was simpler for me to implement that way.

    It does make me wonder though, almost everything I see in a workflow I find much simpler to implement with PowerShell so I tend to create a script and use a workflow to trigger them on a scheduled basis.

    The only exception is for tracking change to objects/properties, although for that I've found policy scripts easier.

    Are there any issues with using Workflows to only schedule scripts?

Children
  • 0 9 months ago in reply to jody gilbert

    If it's only scheduling you want and the scripts don't need access to in-process transaction properties, you can just use AR's task scheduler to fire your scripts.

    In my practice, I tend to try and use the codeless Activities in workflows as much as possible as they are self-documenting and easier to explain to customers.  Saying that, I still run into situations where I need to use a script to provide the activity with some business-rule-calculated piece of information (an example would be the container for an object creation).  And of course, there are situations where the required business logic is so specific that using a workflow activity just isn't practical.

    Depending on the requirements, I build a mix of Change Workflows and Automation Workflows - the latter being used to perform actions on collections of objects that I have "queued" up into Managed Units for "out of band" processing as I have suggested here.