Scenario

In this case we will build the ability for a user to give feedback to another employee in Workday

NOTE: You will be provided access to a Workday Sandbox instance in order to do this. Once you request access through Moveworks, you see an "Workday User Consent Auth" connector in Agent Studio that has already been setup to make API calls. You will also be granted a login to the Workday instance in the Okta Portal indicated by this icon.

Architecture

The diagram you are seeing above will be helpful to visualize what you are going to build in this exercise. The components. When finished, this is what you're use case will look like as it pertains to Agent Studio.

What you will experience as a developer

1. User Consent Authentication

   Moveworks natively supports user consent authentication, more specifically Authorization Code grants. This ensures that the user's permissions will be respected / mirrored as far as what they can do in Workday.

2. User Data Type
   Data types are powerful when it comes to Agentic AI. When an LLM understands data types as objects rather than fields/values, it can inherently perform flexible lookups, disambiguate for clarification, and reliably hold context in memory to perform actions. The User data type is available to use out-of-the-box, and is arguably the most common data type when it comes to employee support.

3. Workday API support
   Workday has 4 types of API specifications - REST, SOAP, WQL and RaaS. Moveworks is flexible enough to use any integration methodology - in this lab we will use SOAP. There is also WQL being used in this lab in order to lookup up your unique Workday ID.

Components

1. Connectors - The authorization and Base URI for the system we are connecting to. Once built, connectors can be re-used to build Actions.
2. Actions - Individual API calls to that system for a specific purpose. These building blocks can be used to resolve data types (in this case, account) or as part of a conversational process where one or more actions can be sequenced together to perform a complex operation.
3. Data Types and Resolvers - Once a data type is established, it can be resolved in many ways by adding more Resolver Strategies. This guarantees we can choose the correct object no matter how the user refers to it, and disambiguate when there are similar traits.
4. Conversational Process - The business execution of Actions and Data Types. One or more Actions can be sequenced together to perform complex tasks.
5. Plugins - The packaged output of the Conversational Process. The plugin is configured by providing positive and negative examples in order to fine-tune plugin selection, as well as who within the organization will have access to this plugin.