| **Workflow Type** | **Description** |
|---|---|
| Build | The first step in the Build/Deploy model. The Build Workflow most commonly does the following tasks:
|
| Deploy | The Deploy Workflow is most commonly the next workflow run. Its duties consist of reading or **consuming **Artifacts published during the Build Workflow and uploading or deploying those Artifacts to your Deploy Target.An example of this could be taking html/css/javascript bundled during build and uploading to Azure to be served. |
| PreDeploy | Prior to running the aforementioned Deploy Workflow, you can optionally run a PreDeploy Workflow. The PreDeploy Workflow can use the Build Artifacts and running any checks prior to the Deploy Workflow executing. Some examples of this could be:
|
| Test Definition | The last Workflow run is a Workflow testing the previous deployment on the Deploy Target. A common example being running some form REST tests, using something like Postman, to validate the Deployment. |
| Utility | Utility Workflows fall outside of the typical Build and Deploy process outlined above. Utility Workflows don’t consume or produce any artifacts and are most commonly used to run adhoc on demand logic on a Target Server.A few examples would be:
|
| Other | Lastly, the black sheep of the family, Other Workflows cannot be used by any Project directly. Their only usage is to have common Workflow logic that can be called from the Workflow types listed before. |
| **Field** | **Description** |
|---|---|
| Variable | The variable or property that we are assigning to. |
| Expression | The expression (groovy) value that should be assigned. |
| **Field** | **Description** |
|---|---|
| Propagate Error | Determines what action should occur after executing the Steps defined in the On Error Scope
|
| Error Variable | Once an error occurs it can be useful to get access to the error object in your On Error Scope. Specifying a variable in this input will assign that error object into that variable so it can be accessed.**Error Variable Scope**Note that both Error Variable and Error Message Variable are scoped to the Error Handler On Error block. Both variables will not be accessible outside of this Scope. |
| Error Message Variable | Identical to Error Variable except it only contains the text of the error instead of the full object. |
| **Field** | **Description** |
|---|---|
| Target Group Override | As mentioned above the Target Group and Target are decided when the Workflow Request form is submitted, should you wish to use a different Target Group, that can be specified here. **This will result in a different set of Endpoints being used for Plugin Execution.** |
| Endpoint Selection | A Target can have multiple Endpoints associated to it. This input allows you to specify which of those Endpoints are considered “candidates” for Plugin Execution.Available options are:
|
| Endpoint Execution | Once the list of Endpoint candidates is chosen based on Selection criteria above, we can then decide which of those Endpoints should actually perform Plugin Executions. Available options are:
|
| **Field** | **Description** |
|---|---|
| Test Name | Test Name allows further refinement of the tests considered for execution. Test Name and Test Tag will union the results should both be specified.Allows multiple entries separated by comma. *This input is a Groovy Script so be sure to enclose any literal text in quotes.* |
| Tags | Run specific tests with specific tags in the Test Automation yaml configuration. Test Name and Test Tag will union the results should both be specified.Allows multiple entries separated by comma. *This input is a Groovy Script so be sure to enclose any literal text in quotes.* |
| Test Qualifier | We can configure the Step itself to fail should the test results not meet expectation. The Test Qualifier input determines what those expectations should be.Depending upon the value chosen, Test Qualifier Value may be presented to be filled in. Set to **No Qualifier **to pass the Step regardless of the results. |
| Output Variable | You can optionally assign the result of the Step to an output variable that can be used later in the Workflow. |
| **Field** | **Description** |
|---|---|
| Workflow | This is the Workflow that should be called. While the field allows calling ANY other active Workflow, it doesn’t necessarily mean that you should. Generally its good practice to have your common Workflow logic created with the Workflow type [Other](#Workflow-Types). |
| Version Override | By Default, the active version of the invoked Workflow will be used when running this Step. You can however choose a specific version with this input. |
| Inputs (if any) | If the invoked Workflow has any defined Workflow Inputs, those will show up in this section. |
| **Field** | **Description** |
|---|---|
| Fault Name | Fault Name should be a shorthand identifier for the particular fault that was thrown. For example CUSTOMERPREFIX\_VALIDATION\_FAULT |
| Fault Details | Fault Details is a longer form description or message of the failure. |
| **Field** | **Description** |
|---|---|
| Retry Count | This is the number retries to attempt (excluding the initial execution attempt) the workflow will make before failing the execution. |
| Should Retry | An optional custom script that will determine if the error should be retried. For example, if the error message contains `FD_RETRY_ERROR_MSG.contains("Unable to reach Url")`, we can retry the steps. |
| Retry Delay | The number of milliseconds to wait before retrying the step. If left blank, will execute immediately. |
| Exponential Retry Backoff | This will double the delay between consecutive retries. Only applicable if Retry Delay is specified. |
| Retry All Steps | This will Retry all the steps in the “Scope” when a failure occurs. By default, it will only retry failed steps. |