The task object provides access to task-level runtime information in expressions. These properties are available within pipelines executed by tasks and provide timing information about task execution.

Supported Task Types:

• Scheduled Task
• Triggered Task
• Ultra Pipeline Task

task.start

Description:

The start time for a Scheduled Task, Triggered Task, and Ultra Pipeline Task. You enter this expression in the Expression field of a Snap. If you manually initiate the Task in Designer, then the task.start result is the starting time of the Pipeline, and the task.end result is an arbitrary date far in the future (for example, 2999-12-31:11:59).

Syntax:

task.start

Returns: DateTime object representing the task start time

Example:

task.start
// Returns: "2019-11-09T11:00:00"

task.end

Description:

The end time and date for a Scheduled Task. You enter this expression in the Expression field of a Snap, and the result is displayed on the Extra Details tab of the Pipeline Execution Statistics window.

Syntax:

task.end

Returns: DateTime object representing the task end time

Example:

task.end
// Returns: "2019-11-09T12:00:00"

Task Properties with Scheduled Tasks

For Scheduled Tasks, the task.start property should indicate when the Scheduled Task previously started. If the Scheduled Task has never been executed before, then the task.start is equivalent to the date and time when it currently starts.

Example: Task Running Every Minute

If a Task runs every minute and starts today at noon, then expect the following values:

Task Properties with Ultra Pipeline and Triggered Tasks

For Triggered Tasks and Tasks created from Ultra Pipelines, this expression generates a result, but the end date is always some future date, since with both of these Task types the end date is undefinable. The start time is the same as that of the pipe.startTime function.

Common Use Cases

Processing Data Since Last Execution:

// Query data modified since last task execution
{
  "query": "SELECT * FROM data WHERE modified_date >= ?",
  "parameters": [task.start]
}

Time Window for Data Processing:

// Process data within the task execution window
{
  "startDate": task.start,
  "endDate": task.end,
  "duration": task.end.getTime() - task.start.getTime()
}

Incremental Data Loading:

// Load data incrementally based on task schedule
{
  "filter": {
    "created_at": {
      "$gte": task.start,
      "$lt": task.end
    }
  }
}

Audit Logging:

// Log task execution details
{
  "taskExecution": {
    "startTime": task.start,
    "endTime": task.end,
    "recordsProcessed": snap.out.totalCount,
    "status": "completed"
  }
}

File Naming with Task Time:

// Generate filename with task execution time
"data_export_" +
task.start.toLocaleDateString({"format":"yyyyMMdd_HHmmss"}) +
".csv"

Calculating Processing Duration:

// Calculate expected processing window
{
  "window": {
    "start": task.start.toString(),
    "end": task.end.toString(),
    "durationMinutes": (task.end.getTime() - task.start.getTime()) / 60000
  }
}

Handling Manual Execution:

// Check if this is a scheduled or manual execution
{
  "isScheduled": task.end.getFullYear() < 2900,
  "startTime": task.start,
  "endTime": task.end
}

Best Practices

• Scheduled Tasks: Use task.start and task.end to define time windows for data processing.
• Incremental Processing: Leverage task.start to track the last processed timestamp for incremental data loads.
• Ultra/Triggered Tasks: Be aware that task.end is a far future date; use pipe.startTime instead.
• Manual Execution: Check if task.end is a future date (year > 2900) to detect manual vs scheduled execution.
• Time Zones: Consider time zone handling when using task timestamps with external systems.
• Date Formatting: Use date formatting functions to convert timestamps to required formats.
• Error Handling: Handle cases where task properties might not be available (e.g., pipeline executed directly).

Property Reference

Behavior by Task Type

Integration with Date Functions

Task properties return DateTime objects that can be used with date functions:

// Format task start time
task.start.toLocaleDateString({"format":"yyyy-MM-dd"})

// Get hour of execution
task.start.getHours()

// Calculate minutes since start
(Date.now().getTime() - task.start.getTime()) / 60000

// Add duration to start time
task.start.plusHours(1)

// Compare with current time
Date.now() > task.end

Practical Scheduling Examples

Daily Batch Processing:

// Process yesterday's data
{
  "startDate": task.start.toLocaleDateString({"format":"yyyy-MM-dd"}),
  "endDate": task.end.toLocaleDateString({"format":"yyyy-MM-dd"}),
  "source": "daily_batch"
}

Hourly Data Sync:

// Sync data from last hour
{
  "syncWindow": {
    "from": task.start.toISOString(),
    "to": task.end.toISOString()
  },
  "frequency": "hourly"
}

Weekly Report Generation:

// Generate weekly report
{
  "reportPeriod": {
    "weekStart": task.start,
    "weekEnd": task.end,
    "weekNumber": task.start.getWeekOfWeekyear()
  }
}

Change Data Capture (CDC):

// Capture changes since last execution
{
  "query": "SELECT * FROM audit_log WHERE change_time >= @start AND change_time < @end",
  "params": {
    "@start": task.start,
    "@end": task.end
  }
}

The task.name property exposes the Task name at runtime. It is especially useful when a single pipeline is reused across multiple Tasks that differ by schedule, parameters, or organizational context. Rather than passing the Task name redundantly as a pipeline parameter, use task.name to reliably identify the invoking Task in logs, alerts, and downstream systems.

Supported Task Types:

• Scheduled Task
• Triggered Task
• Ultra Pipeline Task

task.name

Description:

Returns the display name of the Scheduled, Triggered, or Ultra Pipeline Task that invoked the pipeline. You can use this property in any expression-enabled field to identify which Task configuration triggered the current pipeline execution.

Syntax:

task.name

Returns: String — the name of the Task that invoked the pipeline.

Example:

task.name
      // Returns: "Nightly_CDC_Load"

Behavior and Availability

Within any pipeline execution started by a Task, task.name evaluates to the source Task's display name. If a pipeline is executed directly from Designer (not via a Task), task.name is not populated. Your expression should guard against direct execution when needed.

Renaming a Task updates the value returned by task.name on subsequent executions — no pipeline changes are required.

(typeof task != "undefined" && task.name) ? task.name : "NoTask"

Examples

Structured audit logging:

{
      "audit": {
      "taskName": task.name,
      "startTime": task.start,
      "endTime": task.end,
      "recordsProcessed": snap.out.totalCount
      }
      }

Parameterizing notifications:

"Subject: " + task.name + " — Execution complete"

Route by Task:

task.name == "Nightly_CDC_Load"    ? "cdc"     :
      task.name == "Full_Refresh_Weekly" ? "full"    :
      "default"

Combine with task.start/task.end for windowed processing:

{
      "job": {
      "task": task.name,
      "window": {
      "from": task.start,
      "to":   task.end
      }
      }
      }

Best Practices

• Shared pipelines: Prefer task.name over duplicating Task names in pipeline parameters.
• Manual execution: Add a null/undefined guard when pipelines can also run directly from Designer.
• Observability: Use task.name in log messages, file names, and metrics to distinguish executions of shared pipelines across multiple Tasks.
• Ultra and Triggered Tasks: Continue to use pipe.startTime for precise start timestamps; use task.name for Task identification.

Troubleshooting

Property Reference