Overview

Actions are the core executable units in compound actions, think of them as your agent’s “doers”. Use this expression to invoke predefined actions.

Key concepts

Action Types: Supports three types callable via action_name: HTTP actions (for API calls), script actions (for custom logic), and Compound Actions (for reusable workflows).
Execution Flow: The expression runs the specified action, storing results in an output key variable for downstream use. Delays handle asynchronous behaviors pausing the execution of the flow.
Dynamic Elements: Pass variables from prior steps or user data using Moveworks Data Mapping; outputs capture full API responses or script results.

Low-Code Editor

Add an action step to the editor, then use the right-hand panel to wire it up. Below, follow the annotated steps to build a simple feature request update (e.g., via an HTTP action). Follow the steps to build a simple action expression.

Select Action: Choose from your predefined actions. Tip: If it’s a new action, define it first.
Set Output Key Variable: Name a variable to capture the result. This stores the API response or script output for later steps. Tip: Use descriptive names like update_output to avoid debugging headaches.
Set Dynamic Inputs Map inputs via code editor fields such as feature_request_id: data.feature_id. Common Pitfall: Ensure vars exist upstream.
Set Execution Updates Customize user-facing messages for pending (“Updating feature request, please wait…”) and complete (“The feature request has been successfully updated!”) states.
Delay Action Execution Add a wait (e.g., 3 seconds) via units like seconds or minutes.

Syntax Reference

Schema

action:
  action_name: ACTION_NAME*  # str: HTTP/script/compound action ID (e.g., 'fetch_user_details')
  output_key: OUTPUT_VAR*    # any: Variable to store results (e.g., 'user_details')
  input_args:                # dict: Dynamic params (uses Data Mapping Syntax)
    key1: VALUE_EXPR         # e.g., data.user_id or static '''abc123'''
    key2: VALUE_EXPR
  progress_updates:          # dict: User messages (optional)
    on_pending: 'PENDING_MSG'  # e.g., "Fetching details..."
    on_complete: 'COMPLETE_MSG' # e.g., "Success!"
  delay_config:              # dict: Wait time (optional; DSL number expr per unit)
    seconds: 'DSL_EXPR'       # e.g., "10" or "data.delay"
    # Other units: minutes, hours, days
    # Max delay: 30 days (enforced across all units combined)

Fields

Field	Type	Mandatory	Description
`action_name`	string (action identifier)	Yes	Specifies the HTTP, script, or Compound Action to run.
`output_key`	string	Yes	Name of variable storing the action’s result (e.g., API response).
`input_args`	dictionary	No	Key-value pairs for action parameters
`progress_updates`	dictionary `{on_pending: string, on_complete: string}`	No	Messages shown to user during pending and completion states.
`delay_config`	dictionary of DSL number expressions	No	Time units (seconds, minutes, hours, days) for pre-execution wait. Capped at 30 days total.

Delay limit: 30 days max

The combined delay across all units (seconds, minutes, hours, days) cannot exceed 30 days.

Static values (e.g., days: "45"): The editor validates these inline and blocks you from saving.
Variable values (e.g., days: "data.wait_days"): The platform can only validate these at runtime. If the resolved value exceeds 30 days, the delay step fails with a runtime error when it executes.

If you drive the delay from user input or upstream data, clamp the value in a prior script action to avoid runtime failures.

Practical Examples

Example 1: Basic HTTP Action

Retrieve user info via API, with progress feedback

action:
  action_name: fetch_user_details  # HTTP action
  output_key: user_details
  input_args:
    user_id: data.user_id     # Dynamic from input args
  delay_config:
    seconds: "5"                  # Brief pause before executing
  progress_updates:
    on_pending: "Looking up your profile..."
    on_complete: "Profile loaded!"

Expected Output

data: {
  user_details: {
    "user_id": "abc123",
    "name": "Jane Smith",
    "email": "jane@example.com"
  }
}

The API response is stored in the user_details output key defined above and is now available in the data bank for any downstream steps.

Example 2: Script Action

Run a script action that add two strings together

Python script

return str1 + " " + str2

Action

action:
  action_name: add_two_strings     # Script action
  output_key: concatenated_strings
  input_args:
    str1: meta_info.user.name
    str2: '''is an AI Engineer'''

Example 3: Nested Compound Action

Run a compound action that approves and notifies a ticket

Nested Compound Action

# approve_and_notify
steps:
  - action:
      action_name: approve_ticket  
      output_key: approved_ticket_output
      input_args:
        ticket_id: data.ticket_id
        status: '''approved'''
  - action:
      action_name: notify_team
      output_key: notified_team_output
      input_args:
        team_id: data.approved_ticket_output.team_id

Action calling nested compound action

action:
  action_name: approve_and_notify  # Compound action
  output_key: ticket_status
  input_args:
    ticket_id: data.ticket_id
  progress_updates:
    on_complete: "Ticket approved and team notified!"