All versions since 2.4.0

All versions

2.4.0

Oct 9, 2026

API version: 10.2.0

Added

Action templates and cron triggers can be filed in folders, like Jobs, WorkData and ProcessingSteps. Both have a MoveToFolder action (omit the folder to move back to the root), a FolderPath property and a ParentFolder link. CreateActionTemplate and CreateCronTrigger take an optional Folder to create the item directly in a folder. Filing only organizes the item: a template’s own folder does not decide where its jobs go, and a trigger’s schedule and linked templates are unchanged. A trigger and the templates it runs are filed independently.
Action templates have a job folder: SetJobFolder sets the folder that jobs created from the template (by a trigger or ExecuteNow) are filed into, shown as JobFolder. It is a path, like an output slot target: the folder, and any missing folders above it, are created when a job is created, under the job’s owner, and renaming or moving the folder does not update the setting. Their outputs then follow the job’s folder. An empty path or / clears it, and jobs are created at the root as before; unlike an output slot, an unset job folder does not fall back to the template’s own folder.
The template and trigger queries take the Folder/FolderRecursive filter of the other foldable queries.
Folder contents list templates and triggers next to Jobs, WorkData and ProcessingSteps, as ActionTemplate and CronJobTrigger entities. Clients that only know the earlier types can skip them; the total count includes them.
The folder children Contains filter accepts actiontemplate and actiontrigger.

Changed

DeleteFolder also refuses a folder that holds templates or triggers.
The folder Clear action also deletes the templates and triggers in the folder and its descendant folders. It deletes triggers first, then templates, then Jobs, ProcessingSteps and WorkData. Deleting a template unlinks it from every trigger, including triggers outside the folder. The report lists them with the item types ActionTrigger and ActionTemplate.

2.5.0

Oct 13, 2026

API version: 10.3.0

Added

GET api/Statistics, linked from the entry point as Statistics: the caller’s Owner’s numbers, aggregated by the database instead of paged through item by item. WorkDataCount, UsedStorageInBytes and DeployedProcessingStepCount (the Owner’s own steps deployed on the platform and not deprecated) are totals. JobsCreatedPerUser counts the Jobs created after CreatedAfter (default: 24 hours ago) per creating user. CompletionDays has an entry for every UTC day from CompletedFrom (default: today) on which a Job ended: its Completed and Failed (Error) Jobs, the p50 and p90 run time of the Completed ones in milliseconds, and their count per ProcessingStep function. Hidden Jobs and sub-jobs count. Either window may start at most 366 days back. The resource’s CreateStatisticsQuery action, prefilled with its own windows, answers 201 with the statistics of other windows as Location.

2.6.0

Oct 14, 2026

API version: 10.4.0

Added

An action template’s job folder can contain date placeholders, filled in each time a job is created from the template (by a trigger or ExecuteNow): {{date}}, {{date+N}} or {{date-N}} (N days, at most 365), each optionally followed by @ and a time zone, the IDs cron triggers accept. SetJobFolder with /reports/{{date+1@Europe/Berlin}}/ files a job created at 00:30 on 2026-10-14 in Berlin into /reports/2026-10-15/. Without a time zone the date is UTC. Dates are always written as yyyy-MM-dd. A placeholder may stand alone as a folder name or inside one, and a path may hold several. JobFolder shows the path as written. SetJobFolder refuses an unknown placeholder, an offset beyond 365 days, an unknown time zone, or a path that would not be valid once filled in. Job folders set before keep their meaning: braces were never allowed in folder names.

2.7.0

Oct 14, 2026

API version: 10.5.0

Added

Jobs show when they were scheduled for execution as ScheduledAt, next to CreatedAt, StartedAt and CompletedAt: the UTC time the Job moved from ReadyForProcessing to Pending. It is recorded once and does not change afterwards. StartedAt minus ScheduledAt is the time a Job waited for a worker, while StartedAt minus CreatedAt also counts the time it spent being configured before it was scheduled. Jobs that started before this release get their CreatedAt as ScheduledAt (their StartedAt if that is earlier), so their wait reads as before. Other Jobs scheduled before this release, and Jobs not scheduled yet, have no ScheduledAt; the property is then absent.

2.8.0

Oct 14, 2026

API version: 11.0.0

Added

The statistics, now at GET api/Statistics/Query (see Changed), answer more numbers; every earlier field and parameter keeps its meaning. WorkDataPerUser and WorkDataPerKind split all WorkData of the Owner by creating user and by kind, each with Count and UsedStorageInBytes. Each CompletionDays entry also has ComputeMs, the summed run time of the day’s Completed and failed Jobs that have a start time; TimeToStartP50Ms and TimeToStartP90Ms, how long those Jobs waited from ScheduledAt to their start (absent without a Job that has both); and ProducedBytes, the size of the WorkData they produced through their output slots. UploadDays has an entry for every UTC day from UploadedFrom (default: today) with an upload: the UploadedBytes of the WorkData uploaded that day. ProcessingSteps counts the Jobs that ended from ProcessingStepsFrom (default: today) per ProcessingStep function across its versions: Title (of the step the latest of them ran), Completed, Failed, and the p50 and p90 run time of the Completed ones in milliseconds. Hidden items and sub-jobs count. Both new days may start at most 366 days back, and the CreateStatisticsQuery action takes them too.

Changed

GET api/Statistics is now the Statistics Root, linked from the entry point as StatisticsRoot in place of Statistics: it computes nothing and carries the CreateStatisticsQuery action, which rejects a window that starts more than 366 days back with 400 when it is submitted, not when its Location is followed. The statistics moved to GET api/Statistics/Query, with the same query parameters; the action’s Location points there. They no longer carry the action, and they name the windows they cover, defaults filled in: CreatedAfter, CompletedFrom, UploadedFrom and ProcessingStepsFrom. Clients that read the statistics by URL move to GET api/Statistics/Query.

2.8.1

Oct 15, 2026

API version: 11.0.1

Fixed

The CreateStatisticsQuery action of the Statistics Root is prefilled with the current default windows, so a form generated from it shows them instead of empty fields. Submitting the prefilled values fixes them in the query; omit a window to keep it rolling.
Renaming or moving a folder onto the name of an existing sibling answers 423 instead of 500 (#196): the foundation library now maps a unique violation from raw SQL like one from SaveChanges. A database that refuses connections or is in recovery is likewise reported as temporarily unavailable instead of as an internal error.

2.8.2

Oct 17, 2026

API version: 11.0.1

Fixed

A tag value is a timestamp only in ISO 8601 form, as documented: it must start with a yyyy-MM-dd date. Other text that .NET reads as a date is a string now. A version like Version=1.7.0 was taken for 2000-01-07 and rejected with 400 “Detected timestamp without defining time zone”, as were values like 2.8.1, 10/16/2026, Jan 2026 or 4/3. With a Z or an offset, such a value was stored as a timestamp instead. Versions starting with 0. were not affected. A typed query value {timestamp:...} follows the same rule and rejects any other value as an invalid timestamp. Tag value types also no longer depend on the server’s culture. Tags already stored keep their type. Present since 20260130.205.

2.9.0 Latest

Oct 19, 2026

API version: 11.1.0

Added

A deployment can state its resources explicitly (#229). The ConfigureDeployment action of a ProcessingStep takes Resources with CpuMillicores, MemoryMiB and DiskGiB, as an alternative to ResourcePreset. A request passes exactly one of the two, otherwise it gets 400. A preset stands for the resources the operator applied for it so far, from XSmall (250 millicores, 512 MiB, 3 GiB) to XXLarge (14000 millicores, 60416 MiB, 300 GiB), so clients that send only ResourcePreset keep working unchanged. The deployment shows CpuMillicores, MemoryMiB and DiskGiB, and ResourcePreset when the values are exactly those of a preset, otherwise null. The action’s prefilled values carry only one of the two: the preset when the resources match one, otherwise the resources.
Resources above the resource ceiling are rejected with 400, whether stated explicitly or through a preset; the operator would silently cut them down. The ceiling is set in Deployment:MaxResources (CpuMillicores, MemoryMiB, DiskGiB) and defaults to one ccx43 peak node: 15400 millicores, 60416 MiB and 325 GiB. Set it to the operator’s job.maxResources.* of the namespace when they differ.

Changed

The deployment message to the operator carries spec.resources (cpu, memory, disk as Kubernetes quantities, e.g. "500m", "1024Mi", "10Gi") and no longer spec.resourcePreset. This needs operator 0.3.0 or later; deploy that first. After this release, re-apply every existing deployment so its StepFunction gets explicit resources.
Existing deployments are migrated to the resources of their preset; the stored preset is dropped.