This guide explains the log types available for webhook triggers and scheduled triggers (system triggers) and how to use them to debug issues across each plugin’s lifecycle — from the moment an event is received or a schedule fires to the execution of your actions.

Webhook Trigger Plugin Lifecycle

When a webhook event is sent from an external app (e.g., Salesforce, ServiceNow, Workday), it passes through these main stages before your plugin runs:

1. [New] listener.webhook.trigger – Raw HTTP request received by Moveworks
2. [New] listener.webhook.processor.update – Event validated, transformed, and published (or rejected/debounced)
3. [New] listener.webhook.plugin.trigger – Plugins evaluated and triggered based on the event
4. [Existing] compound_action.trigger → compound_action.step.execute → action.* – Execution of the plugin’s actions.

New Log Types

listener.webhook.trigger

Purpose

Indicates that Moveworks has received a raw webhook request at your configured listener URL.

Log Body Example

1
"root": {
2
  "error_message": "",
3
  "headers": {
4
    "map": {
5
      "X-Github-Event": "issues",
6
      "X-Github-Delivery": "abc123",
7
      "Content-Type": "application/json",
8
      "User-Agent": "GitHub-Hookshot/12345"
9
    }
10
  },
11
  "http_method": "POST",
12
  "listener_metadata": {
13
    "request_id": "aaaaa-bbbbb-cccc",
14
    "listener_id": "xxxxx-yyyyy-zzzzz",
15
    "listener_name": "My_GitHub_Issue_Listener"
16
  },
17
  "parsed_body": {
18
    "action": "opened",
19
    "issue": {
20
      "id": 3290072009,
21
      "number": 11,
22
      "title": "New issue created",
23
      "state": "open",
24
      "html_url": "https://github.com/example-org/example-repo/issues/11"
25
    },
26
    "repository": {
27
      "id": 914634154,
28
      "name": "example-repo",
29
      "full_name": "example-org/example-repo",
30
      "html_url": "https://github.com/example-org/example-repo"
31
    },
32
    "sender": {
33
      "login": "octocat",
34
      "id": 3278918,
35
      "html_url": "https://github.com/octocat"
36
    }
37
  },
38
  "query_params": {},
39
  "raw_body": "<RAW_WEBHOOK_PAYLOAD>",
40
  "received_at": "2025-08-04T16:25:23Z"
41
}

Attribute Descriptions

• listener_metadata – Metadata about the listener that received the request, including:
  • listener_id – Unique ID of the listener.
  • listener_name – Name of the listener as configured in Moveworks.
  • request_id – Unique ID for this specific incoming request.
• received_at – Timestamp when Moveworks received the event.
• http_method – HTTP method used by the webhook request (e.g., POST).
• headers – Key-value pairs sent in the webhook request headers by the provider (e.g., X-Github-Event, Content-Type).
• query_params – Any query parameters included in the listener URL when the event was sent.
• raw_body – The exact payload as received from the webhook provider, before parsing.
• parsed_body – The parsed JSON object representing the webhook event payload.
• error_message – Any error message if Moveworks could not read or validate the request. Empty string if successful.

What issues does this help debug?

• Confirms whether Moveworks received the webhook at all.
• Validates whether the request body was received and parsed correctly.
• Shows the HTTP method, headers, and key payload fields for troubleshooting source system configuration.

If this log is missing, possible causes

1. Listener URL not correctly configured in your source system.
2. Payload could not be parsed (invalid JSON or unsupported format).
3. CRC challenge or handshake failure (if required by the provider).
4. Authentication failure or rate limiting (unsecured listeners are limited to 1 req / 10 sec; secure listeners have higher limits).
5. Signature verification failure (if signature validation is enabled).

listener.webhook.processor.update

Purpose

Indicates how Moveworks processed the raw webhook event after it was received, including whether it was published, rejected, or debounced.

Log Body Example

1
"root": {
2
  "error_message": "",
3
  "event_metadata": {
4
    "listener_metadata": {
5
      "request_id": "6adf6f8c-c076-4cba-8df6-bb25fb00a00d",
6
      "listener_id": "349c1220-aef5-43b1-9318-ebe53537c0fb",
7
      "listener_name": "My_GitHub_Issue_Listener"
8
    },
9
    "event_uuid": "d8vpkoKRVliC",
10
    "created_at": "2025-08-04T16:25:23.056654Z"
11
  },
12
  "event_payload": {
13
    "raw_body": "<RAW_WEBHOOK_PAYLOAD>",
14
    "parsed_body": {
15
      "action": "opened",
16
      "issue": {
17
        "id": 3290072009,
18
        "number": 11,
19
        "title": "New issue created",
20
        "state": "open",
21
        "html_url": "https://github.com/example-org/example-repo/issues/11"
22
      },
23
      "repository": {
24
        "id": 914634154,
25
        "name": "example-repo",
26
        "full_name": "example-org/example-repo",
27
        "html_url": "https://github.com/example-org/example-repo"
28
      },
29
      "sender": {
30
        "login": "octocat",
31
        "id": 3278918,
32
        "html_url": "https://github.com/octocat"
33
      }
34
    },
35
    "headers": {
36
      "X-Github-Event": "issues",
37
      "X-Github-Delivery": "abc123",
38
      "Content-Type": "application/json"
39
    }
40
  },
41
  "process_update": {
42
    "published_update": {
43
      "published_at": "2025-08-04T16:25:23.072620Z"
44
    }
45
  }
46
}

Attribute Descriptions

• event_metadata – Metadata about the processed event:
  • listener_metadata – The listener that received the original request.
  • event_uuid – Unique ID assigned to this event.
  • created_at – Time the event was first recorded by Moveworks.
• event_payload – The event data after initial processing:
  • raw_body – Exact webhook payload as received.
  • parsed_body – JSON-parsed version of the webhook payload.
  • headers – Request headers from the webhook provider.
• error_message – Any processing error message (empty if processing succeeded).
• process_update – Indicates the processing outcome:
  • published_update – Event was published for further evaluation.
  • failure_update – Event failed processing (includes failure_reason).
  • debounced_update – Event dropped because a newer duplicate event was processed first.

What issues does this help debug?

• Confirms that a webhook was successfully processed and published.
• Identifies if the event failed processing and why.
• Shows whether the event was dropped due to debounce rules.

If this log is missing, possible causes

1. Event was never received (listener.webhook.trigger missing).
2. Event failed at the listener stage due to auth, format, or CRC issues.
3. Internal processing failure before log emission (rare).

listener.webhook.plugin.trigger

Purpose

Indicates which plugins were evaluated for a processed webhook event, and whether they were successfully triggered, skipped, failed, or expired.

Log Body Example

1
"root": {
2
  "error_message": "",
3
  "event_metadata": {
4
    "listener_metadata": {
5
      "request_id": "12345678-abcd-1234-abcd-1234567890ab",
6
      "listener_id": "abcd1234-5678-90ab-cdef-1234567890ab",
7
      "listener_name": "My_Webhook_Listener"
8
    },
9
    "event_uuid": "evt-abc123xyz",
10
    "created_at": "2025-08-04T16:25:23.056654Z"
11
  },
12
  "expired": [],
13
  "failed_to_trigger": [],
14
  "skipped": [],
15
  "successfully_triggered": [
16
    "plugin-uuid-1234abcd5678efgh"
17
  ]
18
}

Attribute Descriptions

• event_metadata – Metadata about the event:
  • listener_metadata – Details of the listener that received the original webhook request.
  • event_uuid – Unique ID assigned to the processed event.
  • created_at – Timestamp when the event was first recorded.
• successfully_triggered – List of plugin UUIDs that were triggered successfully.
• failed_to_trigger – List of plugin UUIDs that matched conditions but failed to run.
• skipped – List of plugin UUIDs skipped due to skip conditions.
• expired – List of plugin UUIDs skipped because the event’s time-to-live (TTL) expired.
• error_message – Any error message encountered during plugin evaluation (empty if successful).

What issues does this help debug?

• Confirms which plugins were triggered for a given webhook event.
• Identifies plugins that were skipped, failed, or expired before execution.
• Helps trace why a particular plugin did not run.

If this log is missing, possible causes

1. The event did not pass the processing stage (listener.webhook.processor.update missing or failed).
2. No plugins matched the event’s trigger conditions.
3. Internal error prevented plugin evaluation (rare).

Troubleshooting by Scenario

Scenario A – My plugin never runs

1. Checklistener.webhook.trigger
   • Missing? → Verify listener URL, auth, and payload format.
2. Checklistener.webhook.processor.update
   • Was it published? If not, see failure_reason.
3. Checklistener.webhook.plugin.trigger
   • Was your plugin in successfully_triggered?
   • If skipped/failed: adjust trigger conditions or fix mapping.

Scenario B – My plugin starts but fails mid-run

1. From listener.webhook.plugin.trigger, find root_uuid or event_metadata.
2. Look at compound_action.trigger and compound_action.step.execute.
3. Identify which step failed (e.g., action.http 401 → fix credentials).

Scenario C – Events triggering inconsistently

1. Compare listener.webhook.trigger timestamps with any debounced_update entries.
2. If many events are debounced → reduce redundant sends from source or adjust debounce configuration.

Tips for Working with Webhook Logs

• Use log_context in all logs to filter for a single event across stages.
• Inconsistent UUIDs: Sometimes an event’s UUID is inconsistent across the webhook trigger plugin lifecycle. (Known issue: at plugin.trigger the UUID may switch). This is a known issue and a fix is in progress.
• Secure your listener to increase rate limits and prevent throttling.

Reference: Full Lifecycle Flow (Webhook)

listener.webhook.trigger
   ↓
listener.webhook.processor.update
   ↓
listener.webhook.plugin.trigger
   ↓
compound_action.trigger
   ↓
compound_action.step.execute
   ↓
action.http / action.script / action.builtin

Scheduled Trigger Plugin Lifecycle

The Scheduled Trigger Lifecycle

A typical scheduled run produces the following logs in order:

1. New: scheduled.plugin.trigger ← new for schedules
2. Existing: compound_action.trigger
3. Existing: action.* (e.g., action.builtin.trigger, action.http.trigger, etc.)
4. Existing: compound_action.step.execute (one or more as steps progress)

New Log Type

scheduled.plugin.trigger

Purpose Emitted by the scheduler when a schedule fires and your plugin is enqueued to run.

Log Body Example

1
"root": {
2
  "created_at": "2025-10-01T17:10:00Z",
3
  "error_message": "",
4
  "event_uuid": "IFzfagizKmyq",
5
  "schedule_id": "e3164c63-2035-4f68-b7c1-b49da27204f5"
6
}

Attribute descriptions

• created_at – UTC timestamp when the schedule fired.
• event_uuid – Unique ID for this scheduled firing.
• schedule_id – The schedule configuration that produced this run.
• error_message – Non-empty if the scheduler encountered an error before handoff.

What this helps debug

• Confirms the schedule actually fired at the expected time.
• Disambiguates which schedule (if you have multiple) produced a run.
• Gives you a handle (event_uuid) to correlate with adjacent logs by time and plugin name.

If this log is missing, possible causes

1. The schedule is disabled or expired.
2. The Start at time is in the future or outside the recurrence window.
3. The run was skipped due to concurrency/backfill policy (e.g., a prior run still in-flight).
4. Transient platform issue before the scheduler emitted a log (rare).

Existing Logs You’ll See During a Scheduled Run

compound_action.trigger

Indicates the compound action (your workflow) started.

Example (trimmed)

1
"root": {
2
  "created_at": "2025-10-01T17:10:00Z",
3
  "status": "WORKFLOW_STATUS_PENDING",
4
  "root_uuid": "2d7d383f-9db1-4e94-8395-3ef17d57ed8e",
5
  "workflow_id": "-FL5gBipYh1N",
6
  "step_statuses": {
7
    "dhorvath_test_scheduled_triggers_cron": "WORKFLOW_STATUS_PENDING",
8
    "dhorvath_test_scheduled_triggers_cron.1-get_user_by_email": "WORKFLOW_STATUS_PENDING"
9
  }
10
}

Tips

• Use root_uuid to follow the rest of the run end-to-end.
• status and step_statuses show initial orchestration state.

action.builtin.trigger (and other action.*)

Emitted for each action call (built-in, HTTP, script, etc.).

Example – get_user_by_email

1
"root": {
2
  "action_name": "get_user_by_email",
3
  "created_at": "2025-10-01T17:10:01Z",
4
  "input_args": { "user_email": "dhorvath@moveworks.ai" },
5
  "response": { "user": { "record_id": "4402919472709613755", "full_name": "David Horvath" } },
6
  "error_message": ""
7
}

Example – send_plaintext_chat_notification

1
"root": {
2
  "action_name": "send_plaintext_chat_notification",
3
  "created_at": "2025-10-01T17:10:01Z",
4
  "input_args": {
5
    "message": "I'm testing scheduled triggers. This is super duper fun.",
6
    "user_record_id": 4402919472709613600
7
  },
8
  "response": { "notification_tracker_uuid": "49tDkl6J0RlOX96S" },
9
  "error_message": ""
10
}

Tips

• input_args confirm what was actually sent to the action.
• response surfaces downstream IDs (e.g., notification_tracker_uuid) for follow-up.

compound_action.step.execute

Status updates as steps complete.

Example – step 1 completes

1
"root": {
2
  "created_at": "2025-10-01T17:10:02Z",
3
  "from_status": "WORKFLOW_STATUS_PENDING",
4
  "to_status": "WORKFLOW_STATUS_PENDING",
5
  "root_uuid": "2d7d383f-9db1-4e94-8395-3ef17d57ed8e",
6
  "payload_data": { "status": "ACTION_STATUS_DONE" },
7
  "step_statuses": {
8
    "dhorvath_test_scheduled_triggers_cron.1-get_user_by_email": "WORKFLOW_STATUS_COMPLETE",
9
    "dhorvath_test_scheduled_triggers_cron.2-send_plaintext_chat_notification": "WORKFLOW_STATUS_PENDING"
10
  }
11
}

Example – workflow completes

1
"root": {
2
  "created_at": "2025-10-01T17:10:02Z",
3
  "from_status": "WORKFLOW_STATUS_PENDING",
4
  "to_status": "WORKFLOW_STATUS_COMPLETE",
5
  "root_uuid": "2d7d383f-9db1-4e94-8395-3ef17d57ed8e",
6
  "payload_data": { "status": "ACTION_STATUS_DONE" },
7
  "step_statuses": {
8
    "dhorvath_test_scheduled_triggers_cron": "WORKFLOW_STATUS_COMPLETE",
9
    "dhorvath_test_scheduled_triggers_cron.1-get_user_by_email": "WORKFLOW_STATUS_COMPLETE",
10
    "dhorvath_test_scheduled_triggers_cron.2-send_plaintext_chat_notification": "WORKFLOW_STATUS_COMPLETE"
11
  }
12
}

Tips

• Track progress via step_statuses and final to_status.
• If a failure occurs, the error_message or payload_data.error section will contain details.

Troubleshooting by Scenario (Schedules)

A) “My schedule didn’t fire”

1. Look for scheduled.plugin.trigger at the expected time.

   • Missing? Check that the schedule is enabled, not expired, and its time zone is correct.
   • Confirm Start immediately/Start at behavior and that the first run time has passed.

2. If you expect catch-up of missed runs, verify your org’s backfill/concurrency policy and whether a prior run was still in progress.

B) “The schedule fired, but nothing ran”

1. Find scheduled.plugin.trigger, then look within ±5 seconds for compound_action.trigger for the same plugin.
2. If compound_action.trigger is missing, check platform health or org limits; also verify the plugin wasn’t unpublished or disabled between scheduling and execution.

C) “A step/action failed”

1. Open compound_action.step.execute entries for error_message / payload_data.error.
2. For external calls, inspect the corresponding action.* log for request/response details (e.g., 401/403/404 equivalents, validation messages).
3. Re-run manually with the same inputs to confirm if the failure is transient or due to configuration.

D) “Runs are overlapping or being skipped”

• If your run duration exceeds the interval, the platform may queue or skip subsequent runs based on concurrency/backfill policy. Reduce frequency or optimize the workflow to avoid overlap.

Reference: Full Lifecycle Flow (Schedules)

scheduled.plugin.trigger
   ↓
compound_action.trigger
   ↓
action.builtin / action.http / action.script (zero or more)
   ↓
compound_action.step.execute (one or more)

Notify Logs

Coming soon