# Content Editor Action Flow: From Trigger to Execution

> **Note**: This document describes the action flow system specifically within Wallboard's Content Editor, where users configure interactive behaviors, event responses, and dynamic content updates through a sophisticated event-action architecture.

## Overview
When an event occurs in your digital signage content created in the Content Editor, it triggers a sophisticated chain of processes that determine which actions execute, in what order, and under what conditions. This guide explains the complete journey from initial trigger to final execution within the content editor environment.

## Content Editor Event Configuration

### Setting Up Touch Events
1. Select widget → Properties → Interaction → "EDIT TOUCH EVENTS"
2. Click "Add new"
3. Configure: Action type, Value origin, Final toggle
4. Optional: Input settings, Security (PIN)
5. Save

### Setting Up Data Source Events
1. Content → External Events → "EDIT DATASOURCE EVENTS"
2. Choose scope (Content/Page wide)
3. Configure: Bound value (data picker), Evaluation type, Value origin
4. Set action configuration
5. Save

### Setting Up Time-Based Events
1. Content → External Events → "EDIT TIME BASED EVENTS"
2. Configure schedule: Start/End dates, Every day, Time
3. Set action: Action type, Value origin, Page
4. Configure action settings as needed
5. Save

## The Action Flow Journey

### 1. Event Detection
The journey begins when the system detects an event:
- **User Interaction**: Touch, click, or gesture on a widget
- **Sensor Input**: External device signals (RFID, motion sensor, button press)
- **API Response**: Data received from external systems
- **Datasource Update**: Content data changes or refreshes
- **Time-based Event**: Scheduled triggers at specific times
- **System Event**: Page changes, content cycles, or widget state changes

### 2. Event Capture & Context Creation
Once detected, the system immediately:
1. **Captures Event Data**: Records all event details (type, value, timestamp, source)
2. **Creates Context**: Builds an execution context containing:
    - Current page and widget states
    - Available datasources
    - User session information
    - Device capabilities
    - Event-specific data
3. **Identifies Target Actions**: Finds all actions configured for this event type

### 3. PIN Code Security Gate
If PIN protection is enabled for the event:

#### PIN Validation Flow
1. **Interrupt Normal Flow**: Action execution pauses
2. **Display PIN Terminal**: Shows secure input interface
3. **User Authentication**:
    - User enters PIN code
    - System validates against authorized codes
    - Multiple attempts allowed with lockout protection
4. **Authorization Result**:
    - **Success**: Continues to action evaluation
    - **Failure**: Blocks action execution, may trigger failure actions
    - **Timeout**: Cancels operation after inactivity

### 4. Action Evaluation Phase
The system evaluates each action to determine if it should execute:

#### Conditional Evaluation
Each action undergoes a multistep evaluation:

1. **Basic Conditions**:
    - Is the action enabled?
    - Does the target (widget/page) exist?
    - Are required resources available?

2. **Advanced Conditions**:
    - **Value Comparisons**: Check if received values meet criteria
    - **State Checks**: Verify widget or system states
    - **Time Windows**: Ensure action is valid for current time
    - **Device Capabilities**: Confirm device supports the action

3. **Dynamic Conditions**:
    - JavaScript expressions evaluated in real-time
    - Access to event data and context variables
    - Complex logic with AND/OR operators

#### Evaluation Results
- **Pass**: Action proceeds to filtering phase
- **Fail**: Action is skipped entirely
- **Conditional Pass**: May trigger alternative actions

### 5. Action Filtering & Sequencing

#### The "Final" Action Concept
A **final action** is a special terminator that stops all subsequent actions:
- When encountered, it executes and prevents any actions after it
- Useful for error handling or exclusive conditions
- Example: "If error detected, show error message (final) and stop"

#### Filtering Process
1. **Sequential Evaluation**: Actions are evaluated in configured order
2. **Final Action Detection**:
    - System scans for any action marked as "final"
    - If found and its conditions pass, all actions after it are removed
3. **Batch Deduplication**: Removes duplicate actions targeting same element
    - **Navigation Actions**: Only the first navigation action (jumpTo, nextPage, prevPage) executes - subsequent ones are filtered out
    - **Widget Actions**: Generally only one action per widget is allowed, except for certain widget types (Shape, Stopper, Mapplic, Custom Apps) that can accept multiple actions
    - **Sensor Actions**: Only one action per sensor ID is allowed
    - **Language/Popup Actions**: Only one of each type executes

#### Action Batching
Some actions are intelligently grouped:
- **Same Target**: Multiple changes to one widget execute together
- **Same Type**: Similar operations batch for efficiency
- **Optimization**: Reduces flicker and improves performance

### 6. Execution Phase
Actions execute in the order they were configured by the user, with these modifications:

#### Execution Order
1. **Actions are evaluated for conditions** (pass/fail)
2. **If a "final" action is encountered** and passes evaluation, all subsequent actions are removed
3. **The batch filter removes duplicate actions** as described above
4. **Remaining actions execute in their original configured sequence**

#### Execution Modes
- **Sequential**: Default mode, one after another
- **Delayed**: Actions with configured delays

### 7. Result Propagation
After execution, results flow through the system:

1. **Update UI**: Visual changes appear on screen
2. **Trigger Cascades**: One action may trigger other events
3. **State Synchronization**: All system components update
4. **Logging**: Record execution for analytics/debugging
5. **Notifications**: Alert other systems or devices

## Common Configuration Patterns in Content Editor

### Interactive Menus
1. Add Text/Button widgets
2. Each widget: Touch Event → "Jump to" → Static value → Target page
3. Optional: Visual feedback with Interact widget actions

### Dynamic Content
1. Data Source Event monitoring specific fields
2. Conditional actions using different evaluation types
3. Multiple events for different data states
4. Execute action batch for complex logic

### Time-Scheduled Changes
1. Time Based Event with specific schedule
2. Content change actions (Jump to, Show/hide, Update values)
3. Reverse action for schedule end

## Special Scenarios

### Multi-Action Flows
When multiple actions are configured:
1. All actions evaluate independently
2. Failed conditions don't affect other actions
3. Execution order matters for dependent actions
4. State changes from early actions affect later ones

### Recursive Triggers
Actions can trigger new events:
- Widget state changes may fire state-change events
- Data updates can trigger datasource events

## Summary
The action flow system in Wallboard's Content Editor provides a powerful, flexible way to respond to events in your digital signage content. By understanding each phase—from trigger detection through evaluation, filtering, and execution—you can create sophisticated interactive experiences while maintaining security and performance. The combination of conditional logic, PIN protection, final actions, and intelligent batch processing enables complex interactive behaviors through the Content Editor's intuitive interface.

# Content Editor Actions - Complete Reference

> **Comprehensive reference for all action types available in Wallboard's Content Editor, including complete configuration details and field specifications.**

## Navigation Actions

### Next Page Action

**Purpose**: Advance content to the following page in sequence, providing essential sequential navigation control for presentations and guided experiences.

**Common Uses**:
- Interactive Presentations: Manual slide advancement
- Guided Tours: Step-by-step walkthroughs
- Form Wizards: Multi-step form progression
- Story Telling: Sequential narrative content
- Tutorial Systems: Progressive learning modules
- Menu Navigation: Browse through menu pages

**Configuration**: No additional fields required

**Example Configurations**:
```
Event: Sensor (next button click)
Action: Next Page
Result: Advances to next page in sequence

Event: Time-based (after 30 seconds)
Action: Next Page
Condition: Not on last page
Result: Auto-advance through content

Event: Sensor (swipe left gesture)
Action: Next Page
Result: Swipe to navigate forward
```

---

### Previous Page Action

**Purpose**: Navigate backward to the preceding page in content sequence, enabling content review and flexible multi-page navigation.

**Common Uses**:
- Form Correction: Go back to fix previous entries
- Content Review: Re-read previous information
- Navigation Freedom: Allow backward browsing
- Undo Navigation: Reverse accidental page advances
- Gallery Browsing: Navigate through image collections
- Help Systems: Return to previous help topics

**Configuration**: No additional fields required

**Example Configurations**:
```
Event: Sensor (back button click)
Action: Previous Page
Result: Returns to previous page

Event: Sensor (swipe right gesture)
Action: Previous Page
Result: Swipe back through content

Event: Sensor (left arrow key)
Action: Previous Page
Result: Keyboard-based backward navigation
```

---

### Popup Action

**Purpose**: Display overlay content on top of the current page for modal dialogs, detail views, notifications, and interactive overlays.

**Common Uses**:
- Detail Views: Show expanded information about items
- Image Galleries: Display full-size images in overlay
- Form Dialogs: Collect user input in modal windows
- Notifications: Display alerts or messages
- Help Content: Show contextual help overlays
- Video Players: Play videos without leaving current page

**Configuration Fields**:

#### Required Fields
- **Page**: Dropdown selection of available pages for popup content

#### Optional Fields
- **Special Action**: Dropdown (open, close, toggle)
- **Width (%)**: Number input (0-100, default: 100)
- **Height (%)**: Number input (0-100, default: 100)
- **Auto Close**: Toggle to enable automatic closing
    - **Duration (sec)**: Number input when auto close enabled
- **Interactive**: Toggle to allow user interaction with popup
- **Close Icon**: Toggle to show/hide close button
    - **Icon**: Icon picker when close icon enabled
- **Data Row**: Field picker to pass data to popup content
- **Spinner**: Toggle to show loading indicator
    - **Fade Delay (ms)**: Number input when spinner enabled

**Example Configurations**:
```
Event: Sensor (product image click)
Action: Popup
Target Page: Product Detail Page
Width: 80%
Height: 90%
Data Row: Selected product data

Event: API Response (alert received)
Action: Popup
Target Page: Alert Template
Auto Close: true
Duration: 10 seconds
Interactive: false

Event: Sensor (register button)
Action: Popup
Target Page: Registration Form
Width: 60%
Height: 70%
Interactive: true
```

---

## Widget Control Actions

### Interact Widget Action

**Purpose**: Directly control widget behavior and properties, enabling dynamic manipulation of media controls, gallery navigation, timers, and custom actions.

**Common Uses**:
- Media Control: Play, pause, stop video/audio widgets
- Gallery Navigation: Next, previous, go to specific slide
- Timer Control: Start, stop, reset countdown widgets
- Map Interactions: Zoom, pan, show locations on map widgets
- Form Actions: Submit, reset, validate form widgets
- Animation Control: Trigger animations, reset states

**Configuration Fields**:

#### Required Fields
- **Target Widget**: Dropdown selection of available widgets
- **Widget Action**: Dropdown of widget-specific actions (varies by widget type)
    - Media widgets: play, pause, stop, seek
    - Gallery widgets: next, previous, goTo
    - Timer widgets: start, stop, reset
    - Custom widgets: widget-specific actions

#### Optional Fields
- **Action Parameters**: Widget-specific parameter fields that appear based on selected action

**Example Configurations**:
```
Event: Sensor (play button click)
Action: Interact Widget
Target: VideoWidget_1
Widget Action: play
Parameters: startFrom: 0

Event: Time-based (every 5 seconds)
Action: Interact Widget
Target: ImageGallery_1
Widget Action: next
Parameters: loop: true

Event: API Response (game start)
Action: Interact Widget
Target: CountdownTimer_1
Widget Action: start
Parameters: duration: 60
```

---

### Widget Show/Hide Action

**Purpose**: Control widget visibility dynamically to create interactive interfaces, conditional content display, and responsive layouts.

**Common Uses**:
- Conditional Display: Show content based on user choices
- Progressive Disclosure: Reveal information gradually
- Tab Interfaces: Show/hide content panels
- Error Messages: Display validation feedback
- Loading States: Show/hide progress indicators
- Responsive Layouts: Adapt to screen sizes

**Configuration Fields**:

#### Required Fields
- **Target Widget**: Dropdown selection of available widgets
- **Action Mode**: Dropdown selection
    - Show: Make widget visible
    - Hide: Make widget invisible
    - Toggle: Switch current state

#### Optional Fields
- **Animation Type**: Dropdown selection (fade, slide, none, etc.)

---

### Widget Animate Action

**Purpose**: Trigger CSS animations and transitions on widgets for dynamic visual effects like sliding, fading, rotating, and custom animations.

**Common Uses**:
- Attention Grabbing: Pulse or shake important information
- Content Reveals: Slide in new content sections
- Transitions: Fade between widget states
- Celebrations: Bounce or spin for achievements
- Loading Effects: Rotate spinners or progress indicators
- Visual Feedback: Animate on user interactions

**Configuration Fields**:

#### Required Fields
- **Target Widget**: Dropdown selection of available widgets
- **Animation Type**: Dropdown selection
    - Predefined: fadeIn, fadeOut, slideIn, slideOut, etc.
    - Custom: User-defined CSS animations

#### Optional Fields
- **Duration**: Animation timing configuration
- **Easing**: Animation easing function selection

---

## Data and System Actions

### Change Datasource Action

**Purpose**: Dynamically switch data sources that widgets are bound to, enabling adaptive content and context-aware data display without changing widget configuration.

**Common Uses**:
- Department Displays: Switch between department data
- Multi-location Content: Show location-specific data
- Time-based Data: Morning vs evening datasets
- User Personalization: Display user-specific information
- Testing Scenarios: Switch between test and production data
- Failover Systems: Switch to backup data sources

**Configuration Fields**:

#### Required Fields
- **Target Datasource**: Dropdown selection of available datasources (grouped by type)

#### Optional Fields
- **Overwrite Behavior**: Configuration for how data merging occurs
- **Value Origin**: How values are mapped
- **Field Mapping**: Specify field correspondence between datasources

---

### Change Language Action

**Purpose**: Dynamically switch display language for multi-lingual support, enabling seamless language transitions for global audiences without page reload.

**Common Uses**:
- Multi-lingual Kiosks: Support international visitors
- Regional Displays: Adapt to local languages
- User Preference: Let users select preferred language
- Time-based Changes: Switch languages by schedule
- Emergency Messaging: Display alerts in multiple languages
- Tourism Information: Provide multi-language guides

**Configuration Fields**:

#### Required Fields
- **Target Language**: Dropdown selection of configured languages

---

### Call API Action

**Purpose**: Enable HTTP requests to external web services and APIs for data fetching, form submission, analytics tracking, and third-party system integration.

**Common Uses**:
- Data Fetching: Retrieve real-time information
- Form Submission: Send user input to servers
- Analytics Tracking: Log user interactions
- System Integration: Connect with CRM, ERP, or other systems
- Weather Updates: Fetch current weather data
- Social Media: Pull latest posts or updates

**Configuration Fields**:

#### Required Fields
- **Method**: Dropdown selection (GET, POST, PUT, DELETE)
- **API URL**: Text input for the target endpoint URL

#### Optional Fields
- **Sent Fields**: Field picker to select data to send
    - Will be included in request body
    - Can be used for URL replacement (e.g., {sentPropertyName} becomes the corresponding value)
- **Spinner**: Toggle to show/hide loading indicator
    - **Fade Delay (ms)**: Number input when spinner is enabled (minimum 0)
- **Timeout**: Toggle to enable timeout
    - **Milliseconds**: Number input when timeout is enabled (minimum 1)

#### Response Configuration
- **Success**: Button to configure actions for successful responses (2xx status codes)
- **Failure**: Button to configure actions for error responses (4xx, 5xx status codes)

**Example Configurations**:
```
Event: Form Submit
Action: Call API
Method: POST
URL: https://api.example.com/submit
Sent Fields: formData
Success: Show success message
Failure: Show error dialog

Event: Button Click
Action: Call API
Method: GET
URL: https://weather.api.com/current/{cityId}
Sent Fields: selectedCity
Timeout: 5000ms
Success: Update weather widget
```

---

## Communication Actions

### Static Sensor or Device Event Action

**Purpose**: Send predefined, structured event data to external sensors, devices, or systems for IoT integration and device control.

**Common Uses**:
- IoT Integration: Trigger smart devices or sensors
- System Monitoring: Send health status to monitoring platforms
- Event Broadcasting: Notify external systems of user interactions
- Device Control: Control external hardware (lights, doors, etc.)
- Analytics Events: Send custom analytics data
- Alert Systems: Trigger external alert mechanisms

**Configuration Fields**:

#### Required Fields
- **Type**: Dropdown selection of output sensor event type, grouped by:
    - **Sensor Group**: Relay, Socket, Dual Relay, Quad Relay, ExtendIO, Printer, RS485 AC Socket, People Counter, Dimmer, Generic
    - **Device Group**: Other Command, Custom Command, Screen On/Off, Exit Application, Start Application, Desktop Broadcaster, Trigger Sensor Event

#### Conditional Fields (based on sensor type)
- **Target sensor**: Text input for sensor port/ID or 'ALL' (when Type targets sensors)
- **Sensor ID**: Text input for device/sensor identifier (when Type targets devices)

#### Type-specific Configuration Fields

**Generic Type**:
- **Output format**: Dropdown (Text/Byte)
- **Value**: Textarea for custom text
- **Byte separator**: Single character input (when format is Byte)

**Relay/Socket/Dual Relay/Quad Relay**:
- **Value**: Dropdown with predefined options (Open/Close, On/Off, etc.)

**Custom Command Type**:
- **Command**: Text input for custom command
- **Options**: Textarea for command options
- **Data**: Textarea for command data

**Printer Type**:
- **Value**: Dropdown (Print/Reprint)
- **Value**: Textarea for print content (when Print is selected)

**Start Device Application Type**:
- **Value**: Text input for application path
- **Timeout**: Text input for timeout value
- **Sent fields**: Field picker for dynamic data

**People Counter Type**:
- **Value**: Dropdown (Decrease/Increase/Reset/Set to/getStatus)
- **Set to value**: Number input (when 'Set to' is selected)

**Trigger Sensor Event Type**:
- **Event**: Text input for event name
- **Value**: Text input for event value
- **ID**: Text input for event ID

**Desktop Broadcaster Type** (when value is 'settings'):
- Always on top, Can minimize, Can move, Can exit toggles
- Show in taskbar toggle
- Horizontal/Vertical alignment dropdowns
- Offset X/Y number inputs
- Width/Height number inputs
- Position dropdown (fix/docked)

---

### Dynamic Sensor or Device Event Action

**Purpose**: Forward received sensor or device data with runtime values, enabling adaptive communication with external devices based on real-time conditions.

**Common Uses**:
- Data Relay: Forward IoT sensor readings unchanged
- Event Propagation: Pass events between systems
- Audit Logging: Record raw sensor data
- System Bridge: Connect incompatible systems
- Debug Monitoring: Capture exact sensor output
- Compliance Recording: Store unmodified data for regulations

**Configuration Fields**:

#### Required Fields
- **Type**: Dropdown selection of output sensor event type, grouped by:
    - **Sensor Group**: Relay, Socket, Dual Relay, Quad Relay, ExtendIO, Printer, RS485 AC Socket, People Counter, Dimmer, Generic
    - **Device Group**: Other Command, Custom Command, Screen On/Off, Exit Application, Start Application, Desktop Broadcaster, Trigger Sensor Event

#### Conditional Fields (based on sensor type)
- **Target sensor**: Text input for sensor port/ID or 'ALL' (when Type targets sensors)
- **Sensor ID**: Text input for device/sensor identifier (when Type targets devices)

#### For Generic Type Only
- **Output format**: Dropdown selection (Text/Byte)

#### Automatic Event Forwarding
- **Value**: Automatically forwards the received value from the triggering event (no manual input required)
- For all non-Generic types, displays: "The received value will be sent forward"

---

### Send Static UDP Message Action

**Purpose**: Transmit predefined UDP packets to network devices for device control, lighting systems, and broadcast messaging with connectionless protocol.

**Common Uses**:
- Device Control: Send commands to network devices
- Status Broadcasting: Announce display status to network
- Lighting Control: Trigger DMX/Art-Net lighting systems
- Audio Systems: Control network audio devices
- Gaming/Simulation: Send position or state updates
- Industrial Control: Communicate with PLCs or SCADA systems

**Configuration Fields**:

#### Required Fields
- **Target address**: Text input for the UDP broadcast address to send the event to
- **Event ID**: Text input for the static event identifier
- **Event**: Text input for the static event name/type
- **Value**: Text input for the static event value/payload

#### Optional Fields
- **Target tags**: Text input for comma-separated tags (e.g., tag1,tag2,tag3)
    - Used for filtering/targeting specific devices or systems

---

### Send Dynamic UDP Message Action

**Purpose**: Transmit UDP packets with content that changes based on runtime data, perfect for real-time sensor data relay and telemetry broadcasting.

**Common Uses**:
- Sensor Data Relay: Forward real-time sensor readings
- Status Updates: Send current system state
- Variable Commands: Send commands with parameters
- Telemetry Broadcasting: Transmit performance metrics
- Dynamic Notifications: Alert with contextual data
- Adaptive Control: Adjust device settings based on conditions

**Configuration Fields**:

#### Required Fields
- **Target address**: Text input for the UDP broadcast address to send the event to

#### Optional Fields
- **Target tags**: Text input for comma-separated tags (e.g., tag1,tag2,tag3)
    - Used for filtering/targeting specific devices or systems

#### Automatic Event Forwarding
- **Event ID**: Automatically uses the received event ID (no manual input)
- **Event**: Automatically uses the received event name (no manual input)
- **Value**: Automatically uses the received event value (no manual input)

---

### Send Static MQTT Message Action

**Purpose**: Publish predefined messages to MQTT brokers for reliable IoT communication through lightweight publish/subscribe messaging protocol.

**Common Uses**:
- IoT Device Control: Send commands to smart devices
- Home Automation: Control lights, thermostats, locks
- Industrial Monitoring: Update SCADA systems
- Fleet Management: Send vehicle commands
- Building Management: Control HVAC, security systems
- Alert Distribution: Broadcast notifications to subscribers

**Configuration Fields**:

#### Required Fields
- **Message**: Text input for the static message payload to send

#### Optional Fields
- **Topic**: Text input for the MQTT topic path
    - Cannot contain wildcard characters (#, +)
    - Use "/" to send to root topic, omit "/#" suffix
- **Address**: Text input for the MQTT broker address/hostname
- **Path**: Text input for the broker path
- **Port**: Number input for the broker port
- **Username**: Text input for authentication username
- **Password**: Text input for authentication password

---

## Media and Audio Actions

### Play Audio Action

**Purpose**: Trigger audio file playback for notifications, alerts, background music, or interactive sound effects to enhance digital signage experiences.

**Common Uses**:
- Alert Sounds: Emergency notifications
- Background Music: Ambient audio for locations
- Interactive Feedback: Button click sounds
- Voice Announcements: Public address messages
- Notification Chimes: Attention-getting sounds
- Branded Audio: Company jingles or themes

**Configuration Fields**:

#### Primary Control
- **Stop All**: Toggle (slide box)
    - **Purpose**: When enabled, stops all currently playing audio instead of playing new audio
    - **Effect**: When enabled, hides all other configuration fields

#### Playback Configuration (visible when "Stop all" is disabled)

#### Required Fields
- **Audio File**: File picker component (audio only)
    - **Purpose**: Select the audio file to play from the media library

#### Optional Fields
- **Loop**: Toggle (slide box)
    - **Purpose**: When enabled, audio repeats continuously
    - **Default**: Disabled
- **Volume (%)**: Number input (0-100)
    - **Purpose**: Sets the playback volume as a percentage

---

## Analytics and Development Actions

### Store Custom Statistics Action

**Purpose**: Capture and store custom metrics, usage data, and engagement statistics for analytics, reporting, and ROI measurement purposes.

**Common Uses**:
- Advertising Proof-of-Play: Verify ad playback
- Content Analytics: Track asset engagement
- Compliance Reporting: Document required content display
- ROI Measurement: Prove content effectiveness
- Inventory Management: Track asset usage
- Billing Verification: Confirm billable impressions

**Configuration Fields**:

#### Required Fields
- **Asset Name**: Text input
    - **Purpose**: Unique identifier for the asset being tracked
    - **Usage**: Used to identify the asset in reports and analytics

#### Optional Fields
- **Duration (sec)**: Number input
    - **Purpose**: Records the duration of asset display/playback in seconds
    - **Format**: Integer or decimal seconds
- **Plays**: Number input
    - **Purpose**: Records the number of times the asset was played or displayed
    - **Note**: Despite the label "Plays", the binding uses "impression"
- **Interactions**: Number input
    - **Purpose**: Records the number of user interactions with the asset
    - **Usage**: Tracks clicks, touches, or other engagement events

---

### Log Received Data Action

**Purpose**: Capture and record incoming event data, API responses, and system information for debugging, monitoring, and audit purposes.

**Common Uses**:
- Debugging: Inspect event data structure
- Monitoring: Track system events
- Audit Trail: Record user actions
- Performance Analysis: Log timing data
- Error Tracking: Capture error details
- Integration Testing: Verify data exchange

**Configuration Fields**:

#### Required Fields
- **Log Level**: Dropdown selection of log severity levels

#### Optional Fields
- **Custom Message**: Text input for additional context information

**Example Configurations**:
```
Event: API Response
Action: Log Received Data
Log Level: 1 (info)
Custom Message: "Weather API Response"
Data: Full response object

Event: API Error
Action: Log Received Data
Log Level: 3 (error)
Custom Message: "Failed to fetch user data"

Event: Sensor (any interaction)
Action: Log Received Data
Log Level: 1 (info)
Custom Message: "User interaction: ${event.type}"
```

---

### Run Script Action

**Purpose**: Execute custom JavaScript code to enable advanced functionality, complex calculations, custom integrations, and dynamic behavior beyond standard actions.

**Common Uses**:
- Complex Calculations: Advanced data processing
- Custom Integrations: Connect to proprietary systems
- Data Transformation: Manipulate data structures
- Business Logic: Implement custom rules
- Dynamic Content: Generate content programmatically
- Advanced Animations: Create custom effects

**Configuration Fields**:

#### Required Fields
- **Script Source**: Text area or file reference for JavaScript code

#### Optional Fields
- **Parameters**: Configuration for passing data to script
- **Timeout**: Maximum execution time setting
- **Error Handling**: Fallback behavior configuration
- **Sandbox**: Security restrictions settings

**Example Configurations**:
```javascript
// Dynamic Calculation
Event: Sensor (calculate button)
Action: Run Script
Script: |
  const price = datasource.price;
  const quantity = datasource.quantity;
  const tax = price * quantity * 0.08;
  const total = price * quantity + tax;
  datasource.total = total;
  datasource.tax = tax;

// Custom Validation
Event: Form Submit
Action: Run Script
Script: |
  const email = form.email;
  const phone = form.phone;
  
  if (!email.match(/^[^\s@]+@[^\s@]+\.[^\s@]+$/)) {
    showError("Invalid email");
    return false;
  }
  
  if (!phone.match(/^\d{10}$/)) {
    showError("Phone must be 10 digits");
    return false;
  }
  
  return true;
```

---

### Ignore Action

**Purpose**: Explicitly do nothing when triggered, serving as a placeholder or intentional no-operation response for temporarily disabling event handlers.

**Common Uses**:
- Temporary Disabling: Disable actions without deletion
- Conditional Logic: Create "else" branches that do nothing
- Event Acknowledgment: Receive events without processing
- Development Placeholder: Mark future implementation points
- Testing: Isolate event chains
- Performance: Prevent unnecessary processing

**Configuration**: No fields required - this action intentionally does nothing when executed.

---

## Action Configuration Best Practices

### Value Origin Settings
Most actions support different value origins:
- **Static**: Fixed, predefined values
- **Dynamic**: Values from datasources, form fields, or event data
- **Interactive Widget**: Values from other widgets on the page

### Final Action Toggle
Many actions can be marked as "Final" which:
- Stops execution of subsequent actions in the batch
- Useful for error handling and exclusive conditions
- Creates conditional branching in action sequences

### Conditional Evaluation
Actions can include conditions that determine whether they execute:
- **Value Comparisons**: Check received values against criteria
- **State Checks**: Verify widget or system states
- **Time Windows**: Ensure action is valid for current time
- **Device Capabilities**: Confirm device supports the action

### Security Configuration
Actions can include PIN protection:
- **PIN Code Required**: Actions can require PIN authentication before execution
- **Multiple Attempts**: System allows multiple PIN attempts with lockout protection
- **Timeout Handling**: Automatic cancellation after inactivity period