---
title: "Read a workflow at its latest version."
method: GET
path: "/workflow-repository/workflows/{workflowId}"
tags: ["Workflow Repository"]
---

# Read a workflow at its latest version.

`GET /workflow-repository/workflows/{workflowId}`

## Path parameters

- `workflowId` string, required

## Response `200`

Ok

- WorkflowRepositoryReadWorkflowResponse — Workflow or workflow version reading response. Contains all properties available for the requested workflow or workflow version.
  - `breakpoints` WorkflowsBreakpoint[], nullable
    - `condition` WorkflowsValue — Value interface is the root of the value model type hierarchy. Value models store the computation model of values. The models are defined by the developer, for convenience through a DSL composed of receiver and extension functions and other Kotlin language constructs. When the build runs the definition of the value model, it gets serialized into a JSON representation and that is the artifact of the build. These JSONs are persisted into the database and loaded by the workflow engine for the evaluation of the values. Once values are computed they get stored as data and used by methods or clients to show data to the user. Value models and data models adhere to the same schema defined by the developer in DSSL, just they have a different implementation due to their different roles. Below we define the central repository of value models. These are all part of the framework, available to the workflow engine as well. They provide atomic types and composition mechanisms via containers and the compound value model class. These are in sync with the building blocks in DSSL. User defined types via DSSL schemas are based on the compound value model. The generated value models are available only at build time to the user to define the value computation logic in a type-safe way, meanwhile at runtime in the workflow engine only the compound value model is present. The single value resolution function of this interface is the one used by the workflow engine to execute the value computation. All value models implement this in their own way. The result is always a JSON node, which can be either a single node or an entire tree of nodes behind it. Value model types below are organized into groups based on their parent type, essentially following the hierarchy in a flattened way. The type names - which get into the serialized JSON representation - also follow this structure, where levels are separated with a colon (`:`). By convention names composed of multiple words are presented with snake-case and these rules are followed as a naming convention: * `operation` for operators (both unary and binary, e.g. plus, minus, not...), * `comparison` for comparators (equal, not equal, less than), * `function` for the general case.
      - `value_model_type` string, required
    - `doc` string
    - `message` string
    - `metadata` object
    - `multiLanguageDoc` object
    - `multiLanguageMessage` object
    - `name` string
    - `operation` string
  - `configuration` union
    - WorkflowsJsonNode
      - `array` boolean
      - `bigDecimal` boolean
      - `bigInteger` boolean
      - `binary` boolean
      - `boolean` boolean
      - `container` boolean
      - `double` boolean
      - `embeddedValue` boolean
      - `empty` boolean
      - `float` boolean
      - `floatingPointNumber` boolean
      - `int` boolean
      - `integralNumber` boolean
      - `long` boolean
      - `missingNode` boolean
      - `nodeType` 'ARRAY' | 'BINARY' | 'BOOLEAN' | 'MISSING' | 'NULL' | 'NUMBER' | 'OBJECT' | 'POJO' | 'STRING'
      - `null` boolean
      - `number` boolean
      - `object` boolean
      - `pojo` boolean
      - `short` boolean
      - `string` boolean
      - `textual` boolean
      - `valueNode` boolean
    - unknown
  - `createdBy` integer, nullable
  - `description` string, nullable
  - `inputDataMap` union
    - WorkflowsSerializableDataMap — Data map provides the mapping of each data - according to the data interface of a method or a workflow - and each parameter value combination to the data identifiers.
      - `dataByNameAndParameterValueCombinationId` object
      - `parameterValueCombinationsById` object
    - unknown
  - `name` string
  - `origin` 'CREATED' | 'UPDATED' | 'MIGRATED' | 'COPIED', nullable — The operation through which the workflow version came into existence.
  - `parentWorkflowVersionId` string, nullable — Workflow version identifier. It is a string composed of the type identifier and a UUID: `workflow.version:[UUID]`.
  - `projectId` string
  - `timestamp` string, date-time
  - `workflowId` string — Workflow identifier. It is a string composed of the type identifier and a UUID: `workflow:[UUID]`.
  - `workflowTypeReference` string — Reference to a component version. Components are organized into a group hierarchy which serves as a qualification mechanism to avoid collisions and also to group components semantically. Component versions follow the convention of semantic versioning. The fully qualified reference of a component version follows the following syntax: `[component_group]:[component]:[component_version]`.
  - `workflowVersionId` string — Workflow version identifier. It is a string composed of the type identifier and a UUID: `workflow.version:[UUID]`.

---

[API](https://skmtc.net/simscale/apis/simscale-api.md) · [All operations](https://skmtc.net/simscale/apis/simscale-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/simscale/simscale-api/revisions/53223abaceb7/schema)