Parameters are the information that the assistant collects from the conversation with the user and sends to the external service. Proper parameter management is essential for the effective functioning of Actions.
Types of parameters
Required parameters
- Definition: Essential information without which the Action cannot function
- Behavior: The assistant will explicitly ask for this data if missing
- Examples:
- User email for sending communications
- Problem description for support tickets
- Product ID for availability check
- Date and time for bookings
Optional parameters
- Definition: Useful but not essential information
- Behavior: The assistant can proceed even without this data
- Utility: They improve service quality or provide additional information
- Examples:
- Phone number in a contact form
- Ticket priority (with default value)
- Additional notes for a booking
- User specific preferences
Parameters with default values
- Definition: Parameters that have a predefined value if not specified
- Utility: They simplify user experience and ensure sensible values
- Examples:
- Ticket priority: "normal" if not specified
- Communication language: "english" as default
- Problem category: "general" if not categorized
Defining parameters in the interface
Basic information for each parameter
- Parameter name: Unique identifier (e.g., "user_email", "problem_description")
- Descriptive label: Understandable name for the administrator
- Data type: String, number, date, boolean, etc.
- Description: Explanation for the AI about what this parameter represents
- Required/Optional: Whether the parameter is necessary or not
Advanced options
- Default value: Value used if the parameter is not provided
- Validation: Rules to verify that the value is correct
- Required format: Pattern or example of expected format
- Allowed values: List of options for parameters with limited choices
Parameter configuration examples
Action: Support ticket creation
Name | Type | Required | Default | Description |
---|---|---|---|---|
customer_email | String | Yes | - | Email of the customer requesting support |
subject | String | Yes | - | Title/subject of the problem |
description | Text | Yes | - | Detailed description of the problem |
priority | Option | No | normal | Priority: low, normal, high, urgent |
category | Option | No | general | Category: technical, billing, general |
Action: Appointment booking
Name | Type | Required | Default | Description |
---|---|---|---|---|
customer_name | String | Yes | - | Full name of the customer |
Yes | - | Email for appointment confirmation | ||
preferred_date | Date | Yes | - | Desired date for the appointment |
preferred_time | Time | No | 14:00 | Preferred time |
phone | String | No | - | Phone number (optional) |
notes | Text | No | - | Additional notes or special requests |
How AI extracts parameters
Automatic extraction from conversation
The assistant automatically analyzes the conversation to identify parameter values:
User: "I have a login problem, my email is mario.rossi@email.com"
AI identifies:
- customer_email: "mario.rossi@email.com"
- category: "technical" (deduced from "login problem")
- subject: "Login Problem" (extracted from message)
Requesting missing parameters
If required parameters are missing, the AI will ask explicitly:
AI: "I understand you have a login problem. Can you describe in more detail what happens when you try to log in?"
Purpose: To get the "description" parameter which is required
Validation and quality control
Format validation
- Email: Verify it's a valid email address
- Phone: Check numeric format and length
- Dates: Validate it's a real and future date (if necessary)
- URLs: Verify it's a well-formed URL
Logical checks
- Future dates: For appointments, verify the date is not in the past
- Values in range: E.g., priority must be among allowed options
- Text length: Descriptions not too short or too long
- Related fields: If there's a phone, verify consistency with country
Parameter error handling
Invalid parameters
What happens when a parameter doesn't pass validation:
- User feedback: "The email you provided doesn't seem valid. Can you repeat it?"
- Correction request: The AI asks for a new version of the parameter
- Suggestions: "The format should be name@domain.com"
Ambiguous parameters
When the AI is not sure about the extracted value:
- Confirmation: "I understand your email is mario@email.com, is that correct?"
- Clarification: "By priority do you mean high or urgent?"
- Multiple options: Present choices when not sure
Best practices for parameter definition
Clear parameter names
- Use descriptive names: "customer_email" instead of "email"
- Avoid ambiguous abbreviations
- Maintain consistency between different Actions
- Use naming conventions (snake_case, camelCase, etc.)
Effective descriptions
- Clearly explain what the parameter represents
- Include examples when useful
- Specify required format if particular
- Indicate when the parameter is used
Smart default values
- Use values that make sense for most cases
- Don't set defaults for personal information
- Consider the usage context
- Document why you chose that default
Parameter testing
- Completeness test: Verify that all necessary parameters are collected
- Validation test: Try with invalid values to verify checks
- Conversation test: Simulate real dialogues to see how parameters are extracted
- Edge cases test: What happens with limit values or special situations