Action Parameters

Parameters are the inputs an action needs to do its job. Each parameter has a type that controls how its value gets filled in when the action runs.

The following parameter types are supported:

1. AI Text (default, most common)

The AI freely generates a value from conversation context, or asks the user for more detail if needed.

Example: You want AI to create tasks in Asana based on a product roadmap. The AI reads the conversation and writes appropriate task names and due dates.

2. AI Structured

The AI generates a value that conforms to a custom YAML schema you define — useful when the output needs specific fields with specific types.

Example: You’re creating a Jira ticket with custom fields that differ across projects. You specify exactly which fields should appear and what type of data each should contain.

1
required: [name, age]
2
parameters:
3
  name:
4
    type: string
5
    description: User's full name
6
  age:
7
    type: number
8
    description: User's age in years

3. AI Multiple Choice

You provide a list of allowed values, and the AI picks the most appropriate one based on context.

Example: In Salesforce, when creating a new lead, you define Lead Source as “Website,” “Event,” or “Referral.” The AI selects one based on what it knows about the lead.

4. Predefined

The value is hardcoded — always the same whenever the action runs. Like User Context and Blank, the LLM never sees this field; the value is passed directly to the service.

Example: You always log bugs in the same Jira project. Set ProjectID = "Customer Support Issues" once and it never changes.

Advanced tip: to mix a fixed prefix with an AI-generated value, set the type to Predefined and embed dynamic parts using ${PARAM_NAME} syntax.

5. User Context

The value comes from properties of the user (or system) running the action — such as their email, name, or org — and is filled in automatically. Like Predefined and Blank, the LLM never sees this field; the value is passed directly to the service. Also used in multi-user approval workflows to prevent impersonation. See Credentials and Security for more on how user identity flows through actions.

Example: A user in Slack opens a Jira support ticket. The ticket holder field is automatically set to the email of whoever ran the action via CREDAL_USER_EMAIL.

6. Blank

Like the Predefined and User Context options, Blank completely excludes the parameter from the LLM — it is invisible to the model and will not be interpreted as a field to fill in. Only available for optional parameters.

When the action runs, the underlying service receives its native representation of “blank” for that field (not an empty value of zero characters). To send an empty value instead, use the Predefined option and leave the value unfilled.

Coming Soon

We’re actively developing advanced parameter capabilities. If you’d like early access, contact us at support@credal.ai:

• Conditional human-in-the-loop (HITL) approval rules: Trigger human approval only when specific parameter conditions are met (e.g., require approval for expenses over $10,000)
• Conditional execution rules: Parameter-based logic that determines whether an action should execute at all