Getting object properties for Microsoft Groups

Implement custom condition transitions in Task Transitions to enable dynamic decision-making in workflows, based on the properties of a Microsoft Group.

Module Overview

💡 Certain properties of Microsoft Group objects impact what integration (or what API) we'll use to add someone to that group or remove them from the group. Storing the Group object in a data alias enables custom conditions in transitions to guide the workflow toward the correct integration.

Video (8:47 Minutes)

Step 1: Adding the "Get Group" Action

1. Add the "get group" action from Microsoft Graph to the top of the workflow.

   • Turn on the "snap to grid" feature for easier alignment

2. Rename the action to delete "get_group", deleting "microsoft_graph"

3. Select the Jinja Editor for the Group ID field

   • Enter {{ CTX.group_id }} and close the Jinja Editor

4. Add a data alias to the "on success" transition

   • Key: group

   • Value: {{ RESULT.result.data.value }}

Step 2: Using a Noop for Decision-Making: What "Path" Do We Take From Here?

1. Add a noop below the "get_group" action

2. Rename the noop "check_group_type"

3. Add 2 more transitions to "check_group_type"

4. Label the three transitions and place them in the follow order from left to right:

   • Dynamic

   • Graph

   • Exchange Online

5. Select the Dynamic transition and add the following custom condition: {{ "DynamicMembership" in CTX.group.groupTypes }}

6. Select the Graph transition and add the following custom condition: {{ "Unified" in CTX.group.groupTypes or not CTX.group.mailEnabled }}

7. Connect the Graph transition to the "add_or_remove" noop

Action Item

• Store the group object in a data alias for easier data management.

• Implement a noop to control the workflow's flow, determining the appropriate action based on the group type.

Navigation

Go to the previous module: Introduction to workflow logic (Microsoft APIs)

Go to the next module: Creating a Microsoft Exchange Online path in the workflow