Refer to the legend to help complete this exercise.

Scenario

We’d like to give employees the ability to easily add users to groups in Azure. From a technical standpoint there are some challenges. The Azure API expects you to know the Group ID in addition to the User ID. Luckily Moveworks can make this easy by:

1. Understanding the Groups by an action lookup and holding the context within the conversation. No need to save variables in storage for later use.

2. With Moveworks’ inherent knowledge of the user, developers won’t need to do relational lookups.

3. If users are already part of the group, developers can leverage error handling to control what happens in these instances

   

Steps

We will need to build 2 different actions and release them as plugins.

📘

Visit the Developer Legend for details on how to make the following API requests.

👉 https://help.moveworks.com/docs/moveworks-developer-legend

1. Leverage the Graph API to lookup the existing groups within Azure
2. Use the Graph API to add a user to that group (Can be done with User Resolution)
3. Build error handling in the case that the user already exists in that group (this will return a 400 error code)

There is a connector already setup for you - you’ll find it here:

Tip:
When building plugins for operations that create, change, or update something in a system, it’s always advised to check the “User Consent Required” checkbox. This will ensure the bot has accurately captured all of the information before performing the action.

Note:Your unique Microsoft Graph ID has been given to you along with your login credentials for when you want to test your action. If you haven’t received that or can’t find it, please let us know.

User Resolution
Moveworks has inherent knowledge of users that exist in a given environment across many systems. These fields can be leveraged in Agentic Automations. This also allows developers to pass in a “User” object to Compound Actions instead of having to do so field-by-field.

The User object within Moveworks is made up of custom attributes as well as attributes from your system of record. The demo environment looks like this:

You can then reference any user field within your script editor.

For example, if we’re writing a script to receive the group_id and user from the above screenshots it would look like this

“custom_data” refers to additional information Moveworks knows about the user. This is inclusive of things like geo–location, designation or any other attributes that can be read from IDAM systems in addition to system_ids in other systems.