Packages in the Timextender Data Platform¶

A package is one unit of work in an orchestration flow: refresh a Power BI dataset, run a notebook, execute a script, move a table, trigger a pipeline. You give a package a type, tell it what to act on, and then run it — on a schedule, as a step in a process map, or by hand.

All 21 package types are created and configured in TDP on cloud deployments.

The Packages overview¶

Orchestration → Packages lists every package in the current workspace with its type and status.

Create, Duplicate and Delete sit in the toolbar. Duplicate and Delete act on the rows you tick in the leftmost column, so they stay inactive until you select something. The filter bar above the grid narrows by keyword or by type.

Choosing a type¶

Create opens the type picker. All 21 types are grouped by area, with a count against each.

Selecting a type shows a panel on the right with what it does, a couple of bullets on how it behaves, and one line that matters more than the rest: either Requires, naming the connection you must have first, or Runs on, telling you where the work happens.

Filter by area when you know roughly what you want:

Or search, which matches across areas:

The 21 types¶

Timextender — 6¶

Azure — 11¶

Four more manage cloud spend by sizing resources to what is actually needed:

Data movement — 1¶

Scripts & commands — 3¶

What every package has in common¶

Whatever the type, the editor has the same four tabs and the same lifecycle.

Definition¶

The type-specific fields — the script, the pipeline, the connection. This is the only tab that differs between types.

The Save button shows a completion percentage until every required field is filled. Hovering it lists the fields that are still outstanding.

Properties¶

Two free-text fields, neither required:

• Description — what data is being processed and why
• Action — what someone should do if this package fails

Worth filling in. They are what a colleague reads at 3am when the package they have never seen before has failed.

Executions¶

Sets how and when the package runs:

• Schedule — assign one or more schedules to run this package automatically. The list offers every schedule in the workspace. See Create and assign a schedule.
• Disable — switch the package off, or disable it until a date
• Timeout — how long a single attempt may take before it is abandoned. The timeout applies to each attempt on its own; the wait between retries does not count against it. An attempt that exceeds it is reported as timed out and is not retried.
• Retry on failure — whether to retry, how many times, and how long to wait between

Past runs and their logs live in the Executions area of Orchestration.

Notifications¶

Who gets told on failure or completion. Recipients can be individual users or groups, and more than one of each.

Draft, In Edit, Published¶

The status badge in the overview tells you where a package stands:

The part worth understanding: saving only affects Development. Test and Production keep running the version you last published, so you can edit a package without disturbing anything that is scheduled. Publish promotes what you saved to Production and enables Run.

Drafts do not run on a schedule.

Packages and ODQ Desktop¶

ODQ Desktop does not create or edit these packages. It links to the package in TDP instead — from the object tree, the right-click menu and the Start Page.

Three behaviours to know:

• Duplicate creates a Draft copy you can edit independently.
• Delete removes the package from TDP and from ODQ Desktop.
• If the gateway a package points at has been deleted, saving and publishing are blocked with a warning rather than the package failing later at run time.

Where the work runs¶

Two separate mechanisms control this:

• Execution connection — chooses where a package runs: Timextender Cloud, or one of your on-premises gateways. Only some types offer it, and not all of them offer the cloud.
• Environment (Development / Test / Production) — chooses which configuration a run uses. Command Line can hold a separate command per environment.

Global parameters¶

Anywhere a value differs between environments — a URL, a tenant name, a secret — use a global parameter instead of typing it into the package. Fields that support them show an Insert Parameter control, and the reference takes the form {$ParameterName}.

Secret parameters show a padlock rather than a value, and stay masked in execution logs.

Administrators manage them under Settings → Global Parameters. See Global parameters.

Related¶

• Create and assign a schedule
• Global parameters
• Execution connections
• Installing an execution connection
• Desktop vs Turnkey comparison
• What's new in 26.3