What are data types?

Data types define the structure and format of values that variables can hold. They ensure type-aware behavior, enabling the AI agents to handle data consistently, such as collecting inputs in conversational slots, passing values between actions, or rendering them in citations.

For a complete walkthrough that creates a custom Data Type from scratch, attaches a dynamic resolver strategy, and uses it in a conversation process, see Quickstart #2: Slots & Resolvers.

Available Data Types

Data types vary by context:

Actions: Currently limited to a fixed set of primitive and built-in types.
Slots: Include the same types as Actions, plus support for custom data types.

Data Types for Actions

Actions currently support the following built-in data types.

Type	Description	Example Value
`string`	Text or identifiers	`"alice@example.com"`
`integer`	Whole numbers	`42`
`number`	Decimals or floats	`3.14`
`boolean`	True/false flags	`true`
`object`	Key-value pair structures	`{ "role": "admin" }`
`User`	Moveworks user object	Check our User Attribute Reference
`Group`	A group or distribution list in your identity systems	See Group and Room
`Room`	A conference room in your organization’s room data	See Group and Room
`File`	File upload object	File data from user uploads
`Ticket`	Moveworks ticket object	Ticket data from integrated systems
`List[T]`	List of the selected type	`List[string] -> ["alice@example.com", "jdoe@example.com"]`

Usage Notes:

Use these types when defining inputs for actions.
For lists, specify the inner type (e.g., List[string] for a list of strings).
Group and Room appear in the data type list only for organizations where they are enabled. See Group and Room.

Group and Room

Controlled Availability

The Group and Room data types are being enabled for organizations individually. If they do not appear in your data type list, contact your Moveworks account team.

Group and Room are built-in data types, like User. Before they were available, a plugin that needed a group or a room had to collect a string and look the record up itself, or define a custom data type with its own resolver. Now you select the type directly, and the assistant resolves what the user said against your organization’s data with a built-in resolver strategy. You do not create or maintain the type, its schema, or its resolver.

Where you can use them:

Slots in a conversation process. The assistant resolves the user’s description to a Group or Room record before the process continues, and asks the user to choose when several records match.
Input arguments on compound actions. Pass a resolved record from a slot, or from an upstream step, into the compound action.
Resolver strategies for custom data types that return one of these types.

Once a slot or input argument uses one of these types, its fields appear in the Data Bank and in DSL autocomplete, so you can map them into later steps, for example data.room.building_info.floor.

Group

Represents a group or distribution list ingested from your identity systems, the same records the assistant uses for group access requests. The built-in resolver matches on the group’s name, email, or ID.

Field	Type	Description
`id`	string	Moveworks identifier for the group.
`name`	string	Display name of the group.
`email`	string	Email address of the group or distribution list.
`description`	string	Description of the group.
`external_id`	string	The group’s identifier in the source system.
`integration_id`	string	The integration the group was ingested from.

Room

Represents a conference room from your organization’s room data, the same records behind People & Places Lookups. The built-in resolver matches on the room’s name.

Field	Type	Description
`id`	string	Moveworks identifier for the room.
`canonical_name`	string	The room’s name as it appears to users.
`building_info.name`	string	Building name.
`building_info.address`	string	Building address.
`building_info.floor`	string	Floor.
`building_info.room_number`	string	Room number.
`room_info.capacity`	string	Seating capacity.
`room_info.room_amenities`	List[string]	Amenities, such as a display or video conferencing.
`room_info.phone_number`	string	Room phone number.
`room_info.area_size`	string	Room size.
`room_info.calendar_url`	string	Link to the room’s calendar.

Fields are present only when your source data provides them. Room images are not included.

Data Types for Slots

Slots, used in conversational processes, support all the data types available in Actions, plus custom data types. Custom types allow integration with business systems, enabling slots to handle complex, system-specific objects.

Built-in Types: Identical to those in Actions (see table above).
Custom Data Types: User-defined types representing objects from external systems, such as SalesforceAccount or JiraIssue.

Key Differences

Custom types are exclusive to slots for advanced data collection in conversations.
They enable natural language resolution (e.g., converting “my latest ticket” to a JiraIssue object).
Do not merge custom types across systems—create separate types for similar objects in different systems (e.g., SalesforceAccount and NetsuiteAccount).

How do I configure Custom Data Types?

Custom data types are configured exclusively for use in slots. Follow these steps to create and set them up in the Tool Studio.

Prerequisites

A JSON example of the data object from your business system (e.g., a sample API response).

Step-by-Step Configuration

Navigate to Data Types
Create a New Custom Data Type
1. Click Create
Set Name and Description:
1. Name: Must follow the convention u_<DataTypeName> (e.g., u_SalesforceAccount). This serves as a unique identifier.
2. Description: Provide a detailed explanation of the type, including its purpose and key fields.
Define the Data Type Schema
1. Use the Import JSON button in the top-right to paste a sample JSON object from your system.
2. A schema will be auto-generated based on the JSON structure.
3. Review and edit fields as needed (e.g., mark required fields or add validations).
Add Resolver Strategies
1. Resolver strategies convert natural language inputs to custom data type objects.
2. A single data type can have multiple resolver strategies — for example, a JiraIssue type might have resolvers for searching by issue key, by title, or by assignee. The AI agent picks the best method based on conversation context.
3. Defining resolvers here makes them reusable — every slot that uses this data type inherits these resolvers automatically.
4. For details on configuring static and dynamic resolver methods, see Resolver Strategies.
5. You can also configure resolvers inline on individual slots. See how slot resolvers work for the conceptual overview. Example Use Case: For a JiraIssue type, a resolver might map “this week’s most important bug” to a specific issue object.