outputs.datasets in its workflow.yml). Request forms read them for dropdown options (options_from) and other jobs read them as inputs. Each successful run that changes a dataset adds a version; the current version is what readers see.
Who can read a job’s data: workflows in its data scope (this workspace, selected workspaces, or all workspaces of the organization) that hold a read grant. Never across organizations.
Changes need
workflow.manage_data_sharing on the job. Endpoints other than data-access/ and form-options/ are for job workflows only.
Datasets and versions
GET workflows/{id}/datasets/{name}/ returns the dataset with its versions and which one is current.
POST workflows/{id}/datasets/{name}/promote/
{"version": "<version id>"} makes an earlier version current again (roll back the data).
POST workflows/{id}/datasets/{name}/freeze/
{"frozen": true} keeps the current version in place: new runs still record versions but don’t replace it. {"frozen": false} resumes.
Data scope and grants
PUT workflows/{id}/data-sharing/
visibility is this_workspace, selected_workspaces or all_workspaces. Grants outside the new scope are suspended, not deleted, and come back if the scope widens; the response’s suspended lists the workflows that lost access. With dry_run nothing changes.
POST workflows/{id}/data-grants/
{"consumer_id": "<workflow id>"} lets a workflow in the scope read this job’s datasets. 400 if it’s outside the scope; 404 if it isn’t in this organization.